cc :: somkiat

คำถามที่น่าสนใจสำหรับการใช้งาน git คือ มี branch เยอะไหม ? มีปัญหาเกี่ยวกับการใช้ branch ไหม ? code ปัจจุบันที่ branch ไหน ? มีปัญหาในการ merge code ไหม ? หลายคนพยายามหาเครื่องมือช่วยเหลือ แต่ต้นเหตุของปัญหาคือ branch ที่สร้างขึ้นมามากมายนั่นเอง ที่สำคัญมักจะมี branch จำนวนมากที่ไม่ถูกใช้งาน ดังนั้นควรหัดลบ branch ที่ไม่ใช้งานกันหน่อยไหม ? เช่นลบ remote branch [code] $git remote prune origin [/code] เช่นลบ local branch ที่ merge เข้าไปยัง master หรือ develop branch [code] $git branch --merged | grep -E -v "master|develop" | xargs git branch -d [/code] เพื่อความสะดวกก็สร้าง alias ซะ [code] [alias] po = !git remote prune origin dm = !git branch --merged | grep -E -v \"master|develop\" | xargs git branch -d [/code] เพียงเท่านั้น น่าจะทำให้ชีวิตดีขึ้นมาบ้าง อะไรที่ไม่ได้ใช้งาน ก็ลบไปเถอะนะ ไม่ต้องเสียดายหรอก

วันนี้ทำการ review code ภาษา Java ได้เห็นรูปแบบการเขียน code แปลก ๆ หลายอย่าง แน่นอนว่า สิ่งเหล่านั้นสามารถเขียนได้หลายแบบ บางรูปแบบมันน่าสนใจมาก ๆ ลองมาดูกันหน่อย

เริ่มด้วยการ initial ค่าต่าง ๆ ของ Collection Framework

บ่อยครั้งถ้าต้องการกำหนดค่าเริ่มต้นของ Map มักจะทำแบบนี้ [gist id="16b3f0cb623c5e6719c8fd342ece85e3" file="1.java"] แต่รู้ไหมว่า ทำแบบนี้ได้นะ เขาเรียกว่า double-brace ดังนี้ [gist id="16b3f0cb623c5e6719c8fd342ece85e3" file="2.java"] ยิ่งใน Java 9 ยิ่งง่ายขึ้นอีก เนื่องจากมี Static Factory Method ให้ใช้ [gist id="16b3f0cb623c5e6719c8fd342ece85e3" file="3.java"]

อีกเรื่องที่น่าสนใจกว่าคือ Executable comment ใน Java

ไปเจอในบทความเรื่อง Secret in Java ปกติเราทำการ comment code เพื่อไม่ให้ compiler ทำการ execute code .ในส่วนนั้น ๆ หรือทำการเขียน comment นั่นเอง แต่ใน Java นั้นเราสามารถให้ code ใน comment ทำงานได้นะ ตามจริงมันคือ Unicode นั่นเอง มาดูตัวอย่างกัน [gist id="16b3f0cb623c5e6719c8fd342ece85e3" file="4.java"] คำถามคือค่าของตัวแปร message คืออะไร ? ลองดูกันนะ ขอให้สนุกกับการเขียน code นะ

วันนี้เห็นว่าทีมพัฒนา Jupyter ซึ่งเป็น notebook แบบ interactive ของภาษาโปรแกรมกว่า 100 ภาษา ยิ่งชาว Data Science ด้วยแล้วไม่พลาดด้วยประการทั้งปวง

ทีมพัฒนาได้ปล่อย JupyterLab beta version ออกมา

บอกว่าเป็น next-generation สำหรับ Jupyter แน่นอนว่าต้องสนับสนุน Jupyter อยู่แล้ว เพิ่มเติมคือความสามารถใหม่ ๆ ทั้ง Text editor, Terminal, Data file viewer รวมไปถึง workspace ในรูปแบบของ tab และ extension ต่าง ๆ มากมาย ซึ่งน่าจะทำให้ใช้งานได้ง่ายขึ้น สะดวกขึ้น แสดงดังรูป

มาลองใช้งานกันดูหน่อยสิ ด้วยการติดตั้ง

[gist id="60e564a699790dbee7f6dd4fb56b2961" file="1.txt"] ได้ผลการทำงานดังนี้

มาลองใช้งานกันครับ น่าใช้มาก ๆ อีกไม่นานจะออก version 1.0 ซึ่งน่าจะค่อย ๆ เข้ามาแทนที่ Jupyter เดิม อีกอย่างเราสามารถพัฒนา extension เข้าไปได้อีกด้วย ไปดู Guideline เพิ่มได้ ซึ่งสามารถพัฒนาได้ทั้ง TypeScript และ JavaScript

สิ่งที่น่าสนใจอย่างหนึ่งของนักพัฒนา software คือ มักจะพัฒนาให้มันเสร็จตามเวลา ส่วนเรื่องของความถูกต้องและคุณภาพก็ให้ความสำคัญนะ แต่ไม่ค่อยเน้นมากเท่าไร !! บ่อยครั้งกลับพบว่า จำนวนข้อผิดพลาดจำนวนมากจากการพัฒนา จากสิ่งที่บอกว่าเสร็จแล้ว เป็นประเด็นที่น่าสนใจคือ สิ่งที่นักพัฒนาบอกว่า เสร็จมันคืออะไรกันแน่ ? บางครั้งสิ่งที่มีปัญหากลับไม่ใช่สิ่งที่นักพัฒนาสร้าง แต่กว่าจะหาจุดหรือต้นเหตุของปัญเจอ ต้องใช้เวลานานมาก ๆ (Debugging) ส่วนเวลาในการแก้ไขก็เยอะตามเวลาที่กว่าจะหาเจอ (Mean Time To Recover/Detection)

พอไปพูดคุยกับนักพัฒนาว่า

ไม่ทดสอบกันหรือไง ? นักพัฒนาก็บอกว่า เราทดสอบนะ ทดสอบแบบบ้าน ๆ แต่ถามว่าทดสอบใหม่ทั้งหมดไหม ก็ตอบว่าไม่ รู้หรือไม่ว่า แต่ละ function/method ทำงานถูกต้องหรือไม่ ? คำตอบที่ได้คือ ก็น่าจะทำงานถูกนะ แต่ขอลองไป run หรือ deploy ระบบก่อน เพื่อจะดูว่ามีการทำงานถูกต้องหรือไม่ !!

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

นักพัฒนาหลาย ๆ คนก็บอกว่า เขียน test หรือทดสอบสิครับ !! แต่ก็มีหลากหลายเหตุผลว่าทำไมไม่เขียน มาดูเหตุผลเหล่านั้นกัน

1. หัวหน้าและฝ่าย management ไม่ให้ทำ

ปัญหาหลักคือ ส่วนใหญ่คนที่บอกไม่ให้ทำนั้น มักจะมาจาก non-technical ซึ่งมักมีความเข้าใจว่า การทดสอบนั้นคือหน้าที่ของ QA/Tester สิ ถ้านักพัฒนาจะมาทำ น่าจะเป็นงานที่ซ้ำซ้อน ดังนั้นไม่ต้องทำ แต่ ... เป้าหมายของนักพัฒนาคือ การส่งมอบ software ที่มีคุณค่าและคุณภาพสูงไปยังลูกค้า ดังนั้นไม่ว่าจะอย่างไร เรื่องการทดสอบมันคือสิ่งที่ต้องทำเสมอ ประเด็นหลัก ๆ คือ เขาไม่ให้ทำ หรือคุณต่างหากที่ไม่เคารพในงานของตัวเอง หรือคุณต่างหากที่ทำไม่เป็น หรือคุณต่างหากที่ไม่ทำเอง

2. เวลาไม่พอที่จะเขียนชุดการทดสอบนะ

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

3. ทีมตกลงกันแล้วว่าจะไม่เขียนการทดสอบ

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

4. ทำไปแล้ว ROI (Return On Investment) ดีขึ้นไหม

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

5. นักพัฒนาลองพยายามทำแล้ว แต่ไม่สำเร็จ

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

6. เขียนชุดการทดสอบแล้ว ทำให้ช้าลง

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

สุดท้ายคือ ไม่รู้จะเขียนอะไร ?

วันนี้นักพัฒนาเขียนชุดการทดสอบแล้วหรือยัง ?

เห็นมีการพูดถึง Java หรือ JDK 10 กันบ้างพอสมควร (เงียบ ๆ นะ) เนื่องจากตามแผนแล้วจะถูกปล่อยตัวเต็มมาในมีนาคมนี้แล้ว โดยมี feature ต่าง ๆ แยกไปตาม JEPS ดังนี้

286: Local-Variable Type Inference
296: Consolidate the JDK Forest into a Single Repository
304: Garbage-Collector Interface
307: Parallel Full GC for G1
310: Application Class-Data Sharing
312: Thread-Local Handshakes
313: Remove the Native-Header Generation Tool (javah)
314: Additional Unicode Language-Tag Extensions
316: Heap Allocation on Alternative Memory Devices
317: Experimental Java-Based JIT Compiler
319: Root Certificates
322: Time-Based Release Versioning

ดูแล้วไม่ค่อยมี feature สำหรับคนใช้งานทั่วไปสักเท่าไรนัก น่าจะมีที่อ่านรู็เรื่องหน่อยก็คือ Local-Variable Type Inference ซึ่งเป็นการปรับปรุงรูปแบบของภาษา Java ที่ดูนะง่ายขึ้น สั้นขึ้นมั้ง

โดยรูปแบบของภาษานั้น จะมี keyword ใหม่ชื่อว่า var ขึ้นมา

จากที่อ่านมาพบว่า มีทางเลือกของ keyword นี้เยอะเลย เช่น

var x = expr only (like C#)
var, plus val for immutable locals (like Scala, Kotlin)
var, plus let for immutable locals (like Swift)
auto x = expr (like C++)
const x = expr (already a reserved word)
final x = expr (already a reserved word)
let x = expr
def x = expr (like Groovy)
x := expr (like Go)

โดยเหตุผลของการเลือก var นั้นอ่านเพิ่มเติ่มได้ที่นี่

ว่าด้วยเรื่องของ readability, mutability และ syntax น่าจะไม่ถูกใจของนักพัฒนาหลาย ๆ คน

ดังนั้นลองใช้งานหน่อยสิ จะติดตั้งก็เกรงใจ เลยใช้ Docker ดีกว่า ซึ่งใช้ image จาก OpenJDK 10

เริ่มด้วยการเขียน Hello แบบง่าย ๆ ด้วยการใช้ keyword var ในการประกาศตัวแปร นักพัฒนาไม่ต้องระบุ data type นะ ตัวอย่างเป็นการกำหนดค่าลง ArrayList และวน loop ดึงข้อมูลมาแสดงผลแบบง่าย ๆ ปกติภาษา Java มันเขียนได้หลายแบบอีกดังนี้ [gist id="f34bb7b2844f188d037fe0859351a3cb" file="1.java"] ทำการ compile และ run ได้ผลดังนี้ [gist id="f34bb7b2844f188d037fe0859351a3cb" file="1.txt"]

เพิ่มเติมสำหรับการใช้ var ก็มีข้อกำหนดเช่นกัน

ยกตัวอย่างเช่น ถ้าประกาศตัวแปรโดยไม่กำหนดค่าเริ่มต้นให้ ก็จะ compile time error ถ้าประกาศตัวแปรโดยกำหนดค่า NULL ไป ก็จะ compile time error [gist id="f34bb7b2844f188d037fe0859351a3cb" file="2.txt"] ลองเล่นกันดูครับสำหรับ Java 10 เมื่อถึงเวลาที่ออกมาจะได้ไม่ตกใจกัน ขอให้สนุกกับการ coding นะครับ Reference Websites https://medium.com/@afinlay/java-10-sneak-peek-local-variable-type-inference-var-3022016e1a2b https://www.infoq.com/news/2018/02/first-look-jdk10-rc1

ปัญหาอย่างหนึ่งของการพัฒนา Android app คือ การทดสอบ แต่เมื่อเขียนชุดการทดสอบแล้ว มักจะมีการเปิดให้ทำ Code coverage เสมอ ซึ่งเครื่องมือที่ใช้คือ Jacoco แต่ปัญหาที่ตามมาจากการเปิดให้ทำ Code coverage คือ ความช้าของการ build ดังนั้นเรามาเปิดหรือปิดความสามารถนี้กันหน่อย

เริ่มต้นด้วยการเปิดใช้งาน Code coverage แบบปกติ

ทำการแก้ไขไฟล์ build.gradle ดังนี้ [gist id="47ed25ff8f55f29b709665b9ca5fc0a2" file="build1.gradle"] จากนั้นลองทดสอบ run หน่อย โดยในตัวอย่างนี้จะเป็นการ run ผ่าน command line ทั้งหมด ซึ่งเพิ่ม --profile เพื่อดูรายละเอียดของการทำงานทั้งหมด [code] $./gradlew clean assembleDebug --profile [/code] ผลที่ได้คือ จะพบว่ามี task ชื่อว่า :app:transformClassesWithJacocoForDebug ใน debug build เสมอ ลองดูกันเอาว่า ใช้เวลาการทำงานเท่าไร ? แน่นอนว่า เยอะพอได้เลย

ประเด็นที่น่าสนใจคือ ถ้าบางครั้งไม่ต้องการให้ run Code coverage ละ จะทำอย่างไร ?

ต้อง comment ในไฟล์ build.gradle ตลอดไหม ? ไม่น่าจะดีนะ ดังนั้นเลยใช้วิธีการส่งค่าจาก command line ไปเลยสิ ดังนั้นแก้ไขไฟล์ build.gradle กันหน่อย [gist id="47ed25ff8f55f29b709665b9ca5fc0a2" file="build2.gradle"] จากนั้นทำการ run อีกครั้ง ซึ่งทำงานเหมือนเดิม เพิ่มเติมคือส่งค่า coverage เข้ามา เพื่อให้ทำการ run Code coverage ด้วย ด้วยคำสั่ง [code] $./gradlew -Pcoverage clean assembleDebug --profile [/code] แต่ถ้าไม่ต้องการใก้ run Code coverage ก็ไม่ต้องส่งมา [code] $./gradlew clean assembleDebug --profile [/code] เพียงเท่านี้ เราก็สามารถควบคุมการทำงานของ Code coverage ได้แล้ว แถมเวลาการ build ก็เร็วขึ้นอีกด้วย

ใน Spring Boot 2.0.0.RELEASE นั้น ได้เปลี่ยนรูปแบบของ Metric ของ service จาก Actuator ไปยัง Micrometer ซึ่งแน่นอนว่า การใช้งานก็เปลี่ยนไปพอควร ดังนั้นมาลองใช้งาน Micrometer แบบง่ายกัน รวมไปถึงการใช้งานร่วมกับ Prometheus ซึ่งง่ายกว่าเดิมเยอะ

ปล. ผมเคยเขียนอธิบายการ monitoring service ที่พัฒนาด้วย Spring Boot 1.x ไว้ ซึ่งยังใช้งาน Actuator โดยในตอนนี้เรียกว่า Legacy ไปแล้วนะ

เหตุผลที่เปลี่ยนมาใช้ Micrometer ?

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

Prometheus
Netflix Atlas
CloudWatch
Datadog
Graphite
Ganglia
JMX
Influx/Telegraf
New Relic
StatsD
SignalFx
Wavefront

ก่อนใช้งานต้องเพิ่ม dependency หรือ library เข้ามาใน project

ซึ่งยังคงใช้ actuator แต่ว่าความสามารถเดิม ๆ หายไปเยอะมาก ๆ รวมทั้งเพิ่มการทำงานร่วมกับ prometheus เพื่อทำการสร้าง metric ต่าง ๆ ในรูปแบบของ prometheus [gist id="d6adae2bdb8111932a4fe19499d1aee7" file="pom.xml"] ใน Micrometer นั้นก็มี metric ให้สร้างหลายชนิด ซึ่งปกติที่ใช้ก็ประกอบไปด้วย

Dimension/Tag
Counter
Gauge
Timer
Long task timer
Distribution summary
Summary statistic
Quantile
Histogram
Binder

มาดูตัวอย่างการใช้งานง่าย ๆ ของ Counter กันนิดหน่อย

[gist id="d6adae2bdb8111932a4fe19499d1aee7" file="2.java"] คำอธิบาย การใช้งานจะต้องผ่าน class MeterRegistry เสมอ จากนั้นทำการสร้าง counter metric ซึ่งเราสามารถระบุชื่อไปได้เลย จากนั้นก็เพิ่มค่าไปเรื่อย ๆ สามารถกำหนดค่าได้ด้วย ซึ่งใช้งานง่ายพอสมควร แต่ถ้าไม่ต้องการเขียน code ในรูปแบบนี้ ก็สามารถใช้ AOP มาใช้ได้ ซึ่งทำไม่ต้องไปแก้ไข code เลยดังนี้ [gist id="d6adae2bdb8111932a4fe19499d1aee7" file="3.java"] เพียงเท่านี้ก็สามารถสร้าง metric ของ service เราได้แบบง่าย ๆ ดังนั้นลองใช้งานกันดูนะ ขอให้สนุกกับการ coding นะ

ตอนเช้าได้อ่านเอกสารเกี่ยวกับแนวโน้มและการเปลี่ยนแปลงต่าง ๆ ของการพัฒนา software ในอนาคตอันใกล้ ซึ่งประกอบไปด้วย

ปรับกระบวนการจาก Manual ไป Automation
จาก Automation ไปสู่ AI
ปรับการทำงานจาก Reactive ไป Proactive
Innovation
Reliability เป็นสิ่งสำคัญมาก ๆ

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

ปรับกระบวนการจาก Manual ไป Automation

จากผลการสำรวจเรื่อง FORRESTER REVEALS TOP 10 TECH TRENDS FOR 2018 TO 2020 พบว่า มีข้อหนึ่งสรุปไว้อย่างน่าสนใจคือ

Software robots will replace routine tasks that humans do poorly. By 2020, robots will engage in work that drives customer outcomes.

บอกไว้ว่า Robot จะเข้ามาทำงานในส่วนงานที่คนต้องทำงานซ้ำ ๆ เพราะว่า คนเรามักจะทำงานผิดพลาดอยู่บ่อย ๆ ถึงจะปรับให้ดีขึ้นก็ผิดพลาดได้ ที่สำคัญงานเหล่านั้นต้องการเวลาทำงานเยอะ (เวลาคือค่าใช้จ่าย) ดังนั้นกระบวนการทำงานจะเริ่มถูกปรับให้เป็นแบบอัตโนมัติมากขึ้น เพื่อปรับปรุงกระบวนการให้ดี และ มีคุณภาพมากขึ้น ช่วยลดปัญหา หรือ ทำให้เห็นปัญหาเร็วขึ้น เพื่อแก้ไขและปรับปรุงได้เร็วขึ้น ซึ่งเราจะเห็นได้ว่า หลาย ๆ บริษัทและทีมพัฒนา เริ่มนำแนวคิดและแนวทางของ CI/CD รวมถึง DevOps/Cloud มาใช้งาน เพื่อช่วยทำให้กระบวนการพัฒนา software รวดเร็วและมีคุณภาพ ประเด็นคือ ถ้านำมาใช้แล้วกระบวนการช้าลง คุณภาพแย่ลง คิดว่า น่าจะนำมาใช้ผิดที่ผิดทางนะ !!

จาก Automation ไปสู่ AI

นั่นหมายความว่า ถ้าการทำงานยังคงเป็นแบบ manual อยู่ คุณก็ไม่สามารถไป AI ได้ง่าย ดังนั้นปรับปรุงกระบวนการเป็น automation ก่อน จากนั้นจึงนำ AI เข้ามาช่วย ทั้ง Machine Learning, Data Mining และ Neural network ซึ่งจะช่วยให้บริษัทและทีม สร้าง product ที่ดีขึ้นสำหรับลูกค้าและผู้ใช้งาน รวมทั้งปรับเปลี่ยนและปรับปรุง product ตามความต้องการของผู้ใช้งานที่เปลี่ยนไปได้ แต่ก่อนจะเริ่มต้นนั้น แนะนำให้ไปดูระบบหรือ product ก่อน จากนั้นเริ่มที่ปัญหาว่า มีจุดใดบ้างที่น่าจะนำไปใช้ได้ จากนั้นจึงเริ่มทดลองเล็ก ๆ แล้วดูผล

ปรับการทำงานจาก Reactive ไป Proactive

ระบบงานมักเกิดสิ่งที่ไม่คาดหวังอยู่อย่างเสมอ คำถามคือ เรารู้ปัญหาก่อนหรือหลังผู้ใช้งาน กว่าจะรู้ปัญหา โดนผู้ใช้งานบ่นด่าไปมากเท่าไรแล้ว บริษัทเสียหายไปเท่าไร ไม่พอนะเมื่อเรารู้ปัญหาแล้ว นานไหมกว่าจะหาสาเหตุเจอ ต้องมานั่งอ่าน log file เอง ต้องมานั่ง debug code เอง นานไหมกว่าจะแก้ไขเสร็จ นานไหมหว่าจะ deploy เสร็จ สิ่งที่ต้องการคือ การทำงานแบบ proactive ไม่ใช่ reactive ดังนั้น ถ้ามีระบบ monitoring แล้วต้องบอกสถานการณ์ต่าง ๆ ของระบบได้ ว่าส่วนไหนเริ่มจะมีปัญหา ว่าส่วนไหนทำให้เกิดปัญหา ถ้ามีระบบ logging แล้ว ไม่ใช่เพียงแค่เก็บ !! แต่ต้องสามารถวิเคราะห์และบอกสิ่งต่าง ๆ ที่ต้องการได้

สุดท้ายแล้ว

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

เนื่องจากทีมสอนมีแนวความคิดว่า น่าจะลองเปลี่ยนโจทย์ของการทำ workshop กันหน่อย ซึ่งจัดที่ CAMT (College of Arts , Media and Technology) หนึ่งในนั้นคือ ถ้านำ IoT เข้ามาทำใน workshop จะเป็นอย่างไรกันบ้าง ? เมื่อตกลงกันได้แบบคร่าว ๆ ก็เลยลงมือทำกันเลย จึงสรุปการเตรียมการไว้นิดหน่อย

เริ่มด้วยการมาเรียนการเขียนโปรแกรมและติดต่อกับพวก IoT board กัน

ซึ่งก่อนเริ่มงานประมาณ 1 สัปดาห์ ได้มาเรียนกับ Nat จาก CMMC (Chiang Mai Maker Club) และได้ board ตัวใหม่ที่ทาง CMMC ทำขึ้นมาเอง ชื่อว่า CMMC Latte เพื่อให้ง่ายต่อการเรียนรู้ สำหรับคนเริ่มต้นใหม่ ๆ แบบพวกผม ประกอบไปด้วยสิ่งที่ต้องการเลย เช่น

เป็น WIFI board ที่ใช้ชิบ ESP8266
USB เพื่อให้ง่ายต่อการ flash program
มี Sensor สำหรับวัดค่าอุณภูมิ ความชื้น และความดันอากาศให้ (Bosch BME280)

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

เมื่อมี board หรือ hardware แล้ว ก็มาเขียนโปรแกรมเพื่อติดต่อกับ board กัน

ในส่วนนี้ถือว่ายากและซับซ้อนหน่อย ทั้งการติดตั้ง IDE สำหรับเขียนโปรแกรมนั่นก็คือ Arduino IDE ยังไม่พอนะ ต้องลง library อีกเพียบ แนะนำให้ลงอ่านเพิ่มเติมได้ที่ ติดตั้ง Arduino IDE กับ ESP8266 และ โปรแกรมตัวอย่าง Library

โดยในขั้นตอนนี้เองที่ต้องเดินทางมายังเชียงใหม่ เพื่อให้ทาง Nat ช่วยสอน และ แนะนำการใช้งานและพัฒนาสำหรับการใช้งานเบื้องต้น เป็นการเปิดหูเปิดตาทางด้าน hardware และ IoT มากมาย ภาษาที่ใช้งานก็เป็นภาษา C นั่นเอง

แต่งานก็ง่ายขึ้นมาอีก เนื่องจากทาง Nat ได้เขียนโปรแกรมตัวอย่าง สำหรับการใช้งาน board ให้ไว้แล้ว ทั้งการดึงข้อมูลจาก sessor ทั้งการติดต่อผ่าน WIFI เพื่อให้สามารถส่งข้อมูลเข้าหรือออกจาก board ได้ง่ายขึ้น ตัวอย่างของ source code [gist id="59450956c0afc1037c4a4a11142276ca" file="hello.c"]

ปัญหาต่อมาคือ จะส่งข้อมูลจาก board ออกไปที่ไหนละ ?

จากการสอนของ Nat นั้น ก็ได้อธิบายว่า ใช้แนวคิด Publish/Subscribe model แสดงดังรูป

คำอธิบายง่าย ๆ

Publisher คือ ผู้สร้างข้อมูลนั่นคือ Sensor จาก board นั่นเอง
Subscriber คือ ผู้รับข้อมูลนั่นคือ client หรือผู้ใช้งาน หรือระบบงานที่เราจะพัฒนานั่นเอง
ทั้ง Publisher และ Subscriber จะไม่ผูกมัดกัน (Loose Coupling) ดังนั้นจึงต้องผ่านระบบตรงกลาง เราจะเรียกว่า Broker

การทำงานมีขั้นตอนดังนี้

Publisher จะทำการส่งข้อมูลมายัง Broker โดยใน code ที่เขียนไว้คือ จะส่งข้อมูลในรูปแบบ JSON ไปยัง Broker ทุก ๆ วินาที
Subscriber จะทำการลงทะเบียนไปยัง Broker ดังนั้นเมื่อ Broker มีข้อมูลเปลี่ยนแปลง ทาง subscriber ก็จะได้รับข้อมูลนั้นทันที

โดยใน workshop นั้นจะใช้ Broker ชื่อว่า Eclipse Mosquito ทำการติดตั้งแบบง่าย ๆ ด้วย Docker ไปเลย โดยผมเลือกใช้ Docker Image นี้ เนื่องจากเปิดการใช้งาน Broker ได้ทั้ง TCP (port 1883) และ WebSocket (port 9001) [gist id="59450956c0afc1037c4a4a11142276ca" file="start.txt"] เพียงเท่านี้ก็ได้ Broker แบบง่าย ๆ แล้ว มาถึงตรงนี้คือ Infarstructure และทุกสิ่งอย่างที่เตรียมไว้ให้

ยังไม่จบ เนื่องจากมี 10 board จึงต้อง burn หรือ flash โปรแกรมกันหน่อย

แน่นอนว่า ก็นั่งทำกันสนุกเลย แสดงดังรูป

เมื่อทุกอย่างพร้อม ก็เริ่มทำ Workshop กันสิครับ

เนื่องจาก workshop มีเวลาจำนวน 3 วัน ดังนั้นขอบเขตของงานต้องไม่มากหรือน้อยไป ประกอบไปด้วย

การดึงข้อมูลจาก Broker นั่นคือ การสร้าง subscriber นั่นเอง
สามารถดึงข้อมูลผ่าน TCP หรือ WebSocker
ทำการจัดเก็บข้อมูล
ทำการ Visualize ข้อมูลในรูปแบบต่าง (Creative Visualization)

ไว้ครั้งต่อไป จะให้มาเขียนโปรแกรมและ flash ลง board ด้วยดีกว่า แต่ขอไปฝึกก่อนนะ [fb_embed_post href="https://www.facebook.com/somkiatspns/videos/10156247463553588/" width="550"/] ขอให้สนุกกับการ coding นะครับ

มีโอกาสไปแบ่งปันเรื่องการทดสอบแบบอัตโนมัติสำหรับ Mobile app ทั้ง iOS และ Android คำถามที่น่าสนใจคือ ทุกวันนี้ Mobile app ที่พัฒนากันนั้น ทดสอบกันอย่างไร ? ทดสอบด้วยคนหรือแบบอัตโนมัติเป็นหลัก ? ถ้าทดสอบด้วยคน คำถามต่อมาคือ ทดสอบทุก ๆ feature ไหม ?

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

ถ้าปัจจุบัน Mobile app มี feature อยู่ 50 features แล้วทำการเพิ่ม feature ที่ 51 เข้ามา คำถามคือ สิ่งที่ทีมพัฒนาบอกว่าเสร็จคือะไร ? ระหว่าง หนึ่งทดสอบ feature ที่ 51 แล้ว สองทดสอบทั้ง 51 features แล้ว ลองตอบดูนะครับ คำตอบส่วนใหญ่คือ ทดสอบ feature ที่ 51 นะ แต่ที่เหลือก็ทดสอบเท่าที่มีเวลา หรือที่เกี่ยวข้อง หรือที่คิดว่าน่าจะกระทบ หรือ สำคัญ ผลที่ออกมาคือ ?

ดังนั้นคำถามต่อมาคือ

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

คำถามที่ตามมาคือ แล้วมันยากไหม ?

ตอบเลยว่า ไม่ง่าย แต่ถ้าไม่เริ่ม ก็จะอยู่ในวงจรแย่ ๆ เหมือนเดิม ดังนั้นมาเริ่มกันเถอะ

คำถามต่อมาคือ เริ่มอย่างไรละ ตรงไหนดี ?

ตอบง่าย ๆ เลย คือ เริ่มที่หน้าแรกของ app นั่นแหละ แค่เปิด app ขึ้นมา เมื่อเจอหน้าแรก ก็ตรวจสอบว่า แสดงผลถูกต้องหรือไม่ ? จากนั้นก็ทดสอบด้วย action ต่าง ๆ ตามที่มีให้ใช้งาน เช่นถ้ามีปุ่ม ก็ตรวจสอบว่า กดได้หรือไม่ กดแล้วต้องแสดงอะไร เมื่อทดสอบแบบ manual ได้แล้ว ให้ทำการบันทึกการทดสอบเป็น code หรือชุดการทดสอบแบบอัตโนมัติ โดยชุดการทดสอบนี้ ต้องสามารถทดสอบผ่านบนเครื่องของนักพัฒนา (Development) และ เครื่อง Continuous Integration จากนั้นให้ทำการทดสอบชุดการทดสอบแบบอัตโนมัติ เมื่อมีการเปลี่ยน code และชุดการทดสอบบน Version Control เท่านี้ก็เริ่มต้นได้แล้ว !! และสามารถทดสอบได้ในทุก ๆ environment ด้วยนะ

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

คำถามต่อมาคือ ทำเพียงเท่านี้มันจะไปช่วยอะไร ?

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

เมื่อ app ของคุณเริ่มมีชุดการทดสอบแบบอัตโนมัติ ที่น่าเชื่อถือ เน้นว่าน่าเชื่อถือ (ไม่ใช่ทดสอบผ่านบ้าง ไม่ผ่านบ้าง) ประโยชน์ที่ได้รับกลับมาคือ ความมั่นใจในการเพิ่มและแก้ไขนั่นเอง

ที่สำคัญสุด ๆ คือ มันส่งผลต่อประสบการณ์การใช้งานของลูกค้านั่นเอง

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

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

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

เราจำได้ทุกอย่างที่ทำ ดังนั้นไม่จำเป็นต้องเขียนเอกสารนะ

เอกสารเป็นสิ่งที่นักพัฒนาหลาย ๆ คนไม่ชอบ บอกว่า code ดีกว่า แต่เหล่าหัวหน้าและ manager กลับชอบและมองว่ามันดี แต่นักพัฒนาที่ดีนั้น มักจะเขียนเอกสารเป็นประจำทุกวันอยู่แล้ว เนื่องจากนักพัฒนานั้น มักจะมีงานให้ทำเยอะ มักจะเปลี่ยนการทำงานบ่อย ๆ มักจะลืมง่าย ขี้ลืม แม้แต่ code ที่เขียนยังจำไม่ได้ ดังนั้นก็ควรทำการเขียนเอกสารไว้ด้วย ทั้งเขียน code ให้อ่านได้ง่าย ทั้งการเขียน comment ทั้งการเขียน API document ทั้งการเขียน Flow การทำงานของระบบ ทั้งการเขียน Wiki อธิบายระบบงาน แน่นอนว่า ถ้ามีการเปลี่ยนแปลงการทำงาน เอกสารที่เกี่ยวข้องก็ต้องแก้ไข

แต่เอกสารที่ทำนั้น ต้องดูด้วยว่ามีความสำคัญหรือไม่ ทำไปทำไม เพื่ออะไร เพื่อใคร อย่างไร

เมื่อระบบมีปัญหา เราจะบอกว่า ไม่ใช่ความผิดของเรานะ

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

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

สุดท้ายแล้ว ทั้งหมดมันคือ ทัศนคติ ล้วน ๆ เพียงแค่ตั้งใจยังไม่พอ เพียงแค่ความสามารถยังไม่พอ ต้องมีทัศนคติและวิธีคิดที่ดีและถูกต้องด้วย Reference Websites https://hackernoon.com/you-need-to-stop-these-bad-developer-habits-now-468ae877700f

จากบทความเรื่อง SHIFT Commerce's Journey: Deconstructing Monolithic Applications into Services ทำการอธิบายขั้นตอนการเปลี่ยนสถาปัตยกรรมระบบจาก Monolith ไปเป็น Microservices เป็นกรณีศึกษาที่น่าสนใจ จึงทำการสรุปไว้นิดหน่อย

เหตุผลสำหรับการนำ Microservices มาใช้

1. เรื่องของการพูดคุยที่เยอะเกินไป ในการพัฒนาระบบนั้น พบว่า เมื่อต้องเริ่มต้นพัฒนา เมื่อต้องเพิ่ม feature เข้าไปยังระบบ เมื่อต้องแก้ไขระบบ สิ่งที่เกิดขึ้นคือ ต้องพูดคุย ประชุมกับหลายทีมมากมาย ดังนั้นกว่าจะได้เริ่มพัฒนา ต้องใช้เวลาสูงมาก ยิ่งเมื่อพัฒนาปัญหาก็เยอะมาก ปรับเปลี่ยนสิ่งใด จะยากมาก ๆ 2. การ deploy ระบบงานทุกครั้ง ใช้เวลา และ มีความเสี่ยงสูงทุกครั้ง เมื่อเกิดความกลัวแล้ว สิ่งที่ตามมาคือ ความระมัดระวัง ทั้งการเพิ่มขั้นตอนที่มากมาย ทั้งเวลาที่ใช้เยอะมาก ๆ ผลที่ตามมาคือ ระบบไม่สามารถใช้งานได้ นั่นคือผลกระทบต่อผู้ใช้และธุรกิจอีกด้วย 3. เจอข้อจำกัดของ infrastructure และภาษาโปรแกรม ยิ่งระบบมีขนาดใหญ่ขึ้น ปัญหาที่ตามมาคือ infrastructure ที่มีอยู่ไม่สามารถรองรับได้หรือถึงขีดจำกัด สิ่งที่ต้องทำคือ ขยายนั่นเอง ทำให้ต้องใช้ค่าใช้จ่ายที่สูงมาก ๆ รวมไปถึงภาษาโปรแกรมหรือเทคโนโลยีที่ใช้งานอีกด้วย เช่น ถ้าระบบเดิมคือภาษา Ruby นั้น เริ่มรองรับจำนวนผู้ใช้งานได้ช้าลง การจะเปลี่ยนไปใช้ภาษา Go หรือ NodeJS น่าจะดีกว่า แต่ก็ทำไม่ได้ หรือ ยากมาก ๆ

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

ปล. ถ้ายังไม่มีปัญหาเหล่านี้ ก็ให้พิจารณากันหน่อยนะ

มาดูวิธีการแก้ไขปัญหากันดูว่าเป็นอย่างไรบ้าง ?

แน่นอนว่า เริ่มด้วยการแยก service บางตัวออกมาก่อน แต่การแยกเป็น service ย่อย ๆ ทั้งระบบเลยก็ไม่ได้ เพราะว่า จะมีปัญหาต่าง ๆ มากมายให้แก้ไข ซึ่งนรกมาก ๆ ยังไม่พอนะ ปัญหาที่ตามมาคือ เมื่อแยก service ออกมาแล้ว การติดต่อสื่อสารระหว่างระบบเดิมกับ service เล็ก ๆ ต้องทำอย่างไร ? ในระบบนี้มีความต้องการดังนี้ ทำงานแบบ real time ดังนั้นถ้ามีข้อมูลเปลี่ยนแปลง ส่วนต่าง ๆ ที่เกี่ยวข้องต้องทำงานด้วย แต่ไม่ต้องการให้แต่ละส่วนงานต่าง ๆ ยึดติดกันเกินไป (Decouple หรือ Loose coupling) จึงเลือกใช้งานการติดต่อกันแบบ Asynchronous แน่นอนว่าต้องมีคนกลางสำหรับการติดต่อกัน (Messaging) คำถามคือ ต้องใช้อะไรเป็นตัวกลางในการติดต่อกัน เช่น ActiveMQ, RabbitMQ และ Apache Kafka ทางทีมพัฒนานั้นเลือกใช้ Apache Kafka (ในบทความเป็น service บน Heruku นะ เพื่อลดปัญหาในการดูแลรักษาระบบเอง)

มาดูขั้นตอนการย้ายระบบกันบ้าง

ทำการย้ายแบบค่อยเป็นค่อยไป ไม่ทำแบบ big bang เนื่องจากมีความเสี่ยงสูงมาก ๆ โดยประกอบไปด้วย 8 ขั้นตอนดังนี้ ขั้นตอนที่ 1 สร้าง Producer logic ในฝั่งของระบบเดิม เริ่มด้วยการเพิ่ม code ในระบบเดิม ทำหน้าที่ส่ง event หรือการเปลี่ยนแปลงต่าง ๆ ไปยังตัวกลางคือ Apache Kafka

ขั้นตอนที่ 2 สร้าง Consumer ในส่วนของ service ใหม่ ทำการดึงข้อมูลหรือ event จาก Apache Kafka มาจะเก็บใน Database ของ service ก่อน เพื่อจะนำมาใช้งานใน service นี้ต่อไป เป็นขั้นตอนแรกของการแยก service ออกมา แสดงดังรูป

ขั้นตอนที่ 3 ทดสอบว่า Consumer ทำงานได้ดีและถูกต้องหรือไม่ ต้องทำให้แน่ใจและมั่นใจว่า Consumer ทำงานได้อย่างถูกต้อง ทั้ง event ต่าง ๆ และการบันทึกข้อมูลลง Database รวมทั้งทำความเข้าใจกับการทำงานในรูปแบบต่าง ๆ ของ Apache Kafka อีกด้วย เมื่อทุกอย่างเข้าที่เข้าทาง ก็ไปต่อกัน ขั้นตอนที่ 4 เริ่มสร้าง logic ในส่วนของ service ใหม่ นั่นคือการ copy หรือ duplicate logic การทำงานมาจากระบบเดิมนั่นเอง จากนั้นทำการทดสอบว่า ระบบยังคงทำงานได้เช่นเดิมหรือไม่ แสดงดังรูป

ขั้นตอนที่ 5 เพิ่ม Logic เพื่อส่ง action event หรือการทำงานต่าง ๆ มายัง service จากสิ่งที่ผ่านมา เพียงแค่ส่งข้อมูลที่เปลี่ยนแปลงมาเท่านั้น สิ่งต่อมาคือ action event ของการทำงานนั่นเอง และความสามารถที่ต้องเพิ่มมาคือ Feature Toggle ในฝั่งระบบเดิม เพื่อให้เปิดปิดการส่งข้อมูลการทำงานส่วนต่าง ๆ มายัง service ใหม่ได้ แสดงดังรูป

ขั้นตอนที่ 6 เมื่อ Service ใหม่ทำงานตาม action event แล้ว ก็ต้องผลการทำงานกับไปยังระบบเดิม สิ่งที่ต้องสร้างคือ Producer ในฝั่ง service ใหม่ Consumer ในฝั่งระบบเดิม แสดงดังรูป

ขั้นตอนที่ 7 ทดสอบ ทดสอบ ทดสอบ ทั้งการเปิดปิดจาก Feature Toggle เพื่อทำให้มั่นใจว่า ระบบยังคงทำงานได้เช่นเดิม (ยากมาก ๆ) ขั้นตอนที่ 8 เมื่อมั่นใจก็ลบ logic หรือส่วนการทำงานออกจากระบบเดิม แน่นอนว่าต้องเปิด Feature Toggle ให้ไปใช้ logic ที่ service ใหม่ทั้งหมด ต่อไปในอนาคตอันใกล้ ก็ให้ลบ Feature Toggle ออกไป เนื่องจากการทำงานหลักจะย้ายไปที่ service ใหม่แล้ว นี่คือขั้นตอนการลบสิ่งที่ซ้ำซ้อนนั่นเอง

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

โดยสิ่งที่ทางทีมพัฒนาได้รับจากการเปลี่ยนแปลงประกอบไปด้วย

Deploy และ Release ได้บ่อยขึ้น
ลดปัญหาเรื่อง I/O Latency จากการเรียกผ่าน API
ความพึงพอใจของผู้ใช้งานเพิ่มขึ้น

คำถามที่น่าสนใจ ทำไมเราถึงนำแนวคิดของ Microservices มาใช้งาน ?

เห็นผลการสำรวจในปี 2018 จาก StackOverflow ผู้ตอบแบบสำรวจคือ นักพัฒนามากกว่า 100,000 คน โดยเป็นสมาชิกใน StackOverflow นั่นเอง ซึ่งมีผลการสำรวจที่น่าสนใจมากมาย จึงทำการสรุปแบบสั้น ๆ ไว้นิดหน่อย

ว่าด้วยเรื่องของนักพัฒนา

นักพัฒนากว่า 50% มีประสบการณ์การทำงานต่ำกว่า 8 ปี ที่สำคัญมีนักพัฒนาประมาณ 30% มีประสบการณ์การทำงานต่ำกว่า 5 ปี ยังไม่พอนะ เมื่อดูรายละเอียดเพิ่มเติม จากคำถามว่ามีประสบการณ์ในการ coding มานานเท่าไร สิ่งที่ได้คือ มากกว่า 57% นั้นต่ำกว่า 5 ปี ยังไม่พอนะ มากกว่า 50% ของนักพัฒนาทำการ contribute กับ open source project อีกด้วย เห็นชัดได้ว่า โลกของการพัฒนา software นั้น ขับเคลื่อนด้วยคนรุ่นใหม่

สิ่งที่น่าสนใจคือ 20% ของนักพัฒนาไม่ได้จบปริญญาใด ๆ เลย แต่ถ้าจบปริญามา ก็มีมากกว่า 30% ที่ไม่ได้มาจากสายที่เกี่ยวข้องกับการพัฒนา software

ในส่วนของการเรียนรู้สิ่งใหม่ ๆ นั้น นักพัฒนาส่วนใหญ่ 87% จะศึกษาด้วยตนเอง และศึกษาจาก online course อีก 48% ทำให้เห็นว่า โลกของการพัฒนา software มันเปิดกว้างอย่างมาก ใคร ๆ ก็สามารถเรียนรู้ ฝึกฝนได้ ถ้ามีความพยายามและตั้งใจ สิ่งที่น่าสนใจมาก ๆ สำหรับเจ้าของบริษัทคือ นักพัฒนาเพียง 20% เท่านั้นที่บอกว่า ในอีก 5 ปีข้างหน้ายังทำงานเดิมอยู่ ส่วนที่เหลือนั้น ก็ไปเปิดบริษัทเองบ้าง ก็ไปเป็นหัวหน้าและ manager บ้าง รู้ไว้ใช่ว่า !! ส่วนใหญ่ของนักพัฒนาเป็นผู้ชายถึง 93% กันเลย นักพัฒนาส่วนใหญ่ไม่ได้ตื่นสายนะ มากกว่า 80% ตื่นก่อน 9 โมงเช้า แต่ใช้เวลาเกือบครึ่งวันอยู่กับ computer (รักมากจริง ๆ) ที่น่าสนใจคือประมาณ 70% ก็ออกกำลังกายด้วยนะ

มาถึงเครื่องมือกันบ้าง

ภาษา JavaScript ยังคงได้รับความนิยมอย่างต่อเนื่องมา 6 ปีแล้ว พวก library และ framework ก็ไปในทิศทางเดียวกัน คือ NodeJS, Angular และ React ส่วนภาษาที่รองลงมาก็เป็นพวก Java, Python และ C# เรื่องของ Database ยังคงเป็นเหล่า RDBMS เช่นเดิม ทั้ง MySQL, SQL Server, PostgreSQL, MariaDB และ SQLite ส่วนพวก NoSQL ก็มีตัว top ก็เช่น Document based คือ MongoDB Key-value คือ Redis Search engine คือ Elasticsearch ส่วนพวก Cloud service ก็มีมาให้เห็นนะ ทั้ง Google Cloud, Microsoft Azure และ Amazon

ปิดท้ายด้วยภาษาโปรแกรมที่นักพัฒนาควรศึกษาไว้

Python
JavaScript
Go
Kotlin
TypeScript
Java
C++
Rust
C#
Swift
R

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

วันนี้อ่านเจอเอกสารที่น่าสนใจว่าด้วยเรื่อง Big Data Technology with 8V ซึ่งทำการอธิบายคุณสมบัติของ Big Data เพื่อกำหนดว่าในแต่ละส่วนต้องทำอะไร นำพาไปสู่การเลือก process และ technology ที่เหมาะสม โดยแบ่งออกเป็น 8 กลุ่มดังนี้

Volume
Value
Veracity
Visualization
Variety
Velocity
Viscosity
Virality

แสดงดังรูป

มีตัวที่เพิ่มเข้ามาและน่าสนใจคือ

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

ยังไม่พอนะ เจอข้อมูลว่ามีถึง 42V อีกด้วยนะ

มันจะเยอะไปไหน !!

อ่านเพิ่มเติมในเรื่อง Big Data ด้วย 5V + 1C

ในการพัฒนา software นั้น การทดสอบเป็นสิ่งที่สำคัญมาก ๆ เพื่อทำให้นักพัฒนามีความมั่นใจต่อการพัฒนา แน่นอนว่า การทดสอบเหล่านั้นจำเป็นต้องทำงานแบบอัตโนมัติอีกด้วย

เมื่อมาพัฒนาระบบ web application ด้วย React แล้ว

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

แต่พอเขียนไปแล้วพบว่ามันมีหลายเรื่องมาก ๆ

ทั้งชนิดของการทดสอบ เช่น

Unit testing
React testing
React UI testing
Snapshot testing
End-to-End testing

ตลอดจนเครื่องมือและ library ต่าง ๆ ยกตัวอย่างเช่น Enzyme, Jest, Jasmine, Sinon, Mocha, Chai และ Storybook เป็นต้น คำถามแรกเลยคือ มันจะเยอะไปไหน ? จะเริ่มจากอะไร ? แต่ละอย่างมันคืออะไร ? วุ่นวายไปหมด ดังนั้นไม่ทำดีกว่า !!

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

ใน blog นี้จะเริ่มด้วย React testing ด้วย Enzyme

ซึ่งเป็น library สำหรับทดสอบ React component โดยเฉพาะ ทำการจำลองการทำงานของ React component ขึ้นมา จากนั้นสามารถส่ง action หรือค่าต่างเข้าไปในแต่ละ component ได้เลย ผมคิดว่า React developer ต้องไม่พลาดกับตัวนี้ หรือถ้ายังไม่รู้ ให้เริ่มศึกษาและลองใช้งานตอนนี้ได้เลย ก่อนอื่นต้องสร้าง project ด้วย create-react-app โดย project ที่สร้างขึ้นมาก็ง่าย ๆ คือ เครื่องคิดเลขก็แล้วกัน ผมเขียนยาก ๆ ไม่ค่อยเป็นนะ [code] $npx create-react-app calculator [/code] รอสักนิด เพราะว่าต้องใช้ dependency ถึง 970 ตัว !!

โดย code ตัวอย่างจะเริ่มจากที่นี่ Github::Up1::Workshop React Testing

ไฟล์การทำงานหลักคือ Calculator.js เป็น component หลักของ workshop นี้ ดังนี้ [gist id="dfc076956687a6d6ce1cb9d2acd5c7f5" file="0.js"] จากนั้นลองทำการ run ด้วยคำสั่ง [code] $yarn start [/code] จะแสดงผลการทำงานดังนี้

มาเริ่มเขียนชุดการทดสอบด้วย Enzyme กันดีกว่า

ขั้นตอนที่ 1 ทำการติดตั้ง library/dependency เข้าไปยัง project [code] $yarn add -D enzyme react-test-renderer enzyme-adapter-react-16 [/code] ขั้นตอนที่ 2 ทำการ setup Enzyme ใน project ของเรา ด้วยการสร้างไฟล์ชื่อว่า setupTests.js ใน directory src เพื่อกำหนด adapter ให้ตรงกับ version ของ React ซึ่งในตัวอย่างคือ 16 สามารถอ่านเพิ่มเติ่มได้จาก Enzyme Installation ดังนี้ [gist id="dfc076956687a6d6ce1cb9d2acd5c7f5" file="1.js"] ขั้นตอนที่ 3 ทำการสร้างไฟล์การทดสอบขึ้นมาสิ ปัญหาคือ จะทดสอบอะไรดีละ ? เมื่อเรากลับไปดูผลการทำงานของระบบจะพบว่า เรามีเพียง component เดียวคือ Calculator component จะแสดงข้อความว่า TODO NEXT ใน tag div ดังนั้นมาแก้ไขในไฟล์ Calculator.test.js กัน [gist id="dfc076956687a6d6ce1cb9d2acd5c7f5" file="2.js"] คำอธิบาย

ทำการ import library ของ enzyme เข้ามา
ทำการจำลองการทำงานของ Calculator component
ทำการตรวจสอบว่า tag div มีค่าเป็น TODO NEXT หรือไม่

จากนั้นทำการ run ชุดการทดสอบด้วยคำสั่ง [code] $yarn test [/code] แสดงผลการทดสอบดังนี้

มาถึงตรงนี้เราก็สามารถเริ่มสร้างชุดการทดสอบด้วย Enzyme ได้แล้ว มันง่ายมาก ๆ ใช่ไหม ?

ต่อไปจากจุดนี้

เราจะเริ่มพัฒนาระบบงานด้วย Test หรือ ชุดการทดสอบ (คิดก่อนว่าจะทำอะไร) จากนั้นจึงลงมือเขียนชุดการทดสอบด้วย Enzyme แน่นอนต้องไม่ผ่านแน่ ๆ เพราะว่า ยังไม่มี code หรือความสามารถนั้น ๆ เลย ดังนั้น เราก็ไปเขียน code ง่าย ๆ เพื่อให้ชุดการทดสอบมันผ่าน มาเริ่มกันเถอะ ... ในตอนหน้านะ ขอให้สนุกกับการ coding ครับ

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

ดังนั้นในฐานะนักพัฒนา software มาฝึกการแบ่งปัญหากันบ้าง

มาเริ่มกันเลย

ปล. สิ่งต่าง ๆ ที่จะแนะนำนี้ ต้องฝึกและลงมือทำอย่างเป็นประจำนะครับ

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

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

เมื่อแต่ละปัญหาถูกแก้ไขแล้ว ผลรวมที่ได้จะแก้ไขปัญหาใหญ่เอง วิธีการแบบนี้มันคุ้น ๆ เหมือน Divide and Conquer หรือไม่นะ แสดงดังรูป

เมื่อลงมือแก้ไขปัญหานั้น สิ่งที่ต้องทำประกอบไปด้วย

เขียนปัญหาหรือคำถาม พร้อมทั้งคำตอบที่คาดหวัง
สร้างสมมุติฐานขึ้นมา ว่าจะแก้ไขอย่างไรได้บ้าง (Creative Thinking)
คาดการผลจากสมมุติฐานสิว่าจะได้อะไรออกมาบ้าง
ลงมือการทำและทดสอบตามสมมุติฐาน จากนั้นบันทึกผลจากการลงมือทำ (Test and Coding)
ทำซ้ำไปจนกว่าปัญหาหรือคำถามจะได้คำตอบที่ถูกต้อง

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

ทั้ง OS ที่ใช้ ทั้ง Keyboard ที่ใช้ ทั้ง Editor/IDE ที่ใช้ ทั้ง command line ที่ใช้ ทั้งภาษาโปรแกรมที่ใช้ ทั้ง framework และ library ที่ใช้ และอื่น ๆ ที่เกี่ยวข้องอีกมากมาย ต้องใช้เครื่องมือเหล่านี้ให้เกิดประโยชน์สูงสุด นั่นคือการเลือกเครื่องมือให้เหมาะสมกับงานนั่นเอง แต่จะรู้ได้อย่างไร ? ก็ต้องฝึกใช้หลาย ๆ ตัวไงละ เพื่อทำให้รู้และเข้าใจความสามารถ ข้อจำกัดนั่นเอง ขอให้สนุกกับการ coding ครับ

จาก Part ที่ 1 นั้นเริ่มด้วยการทดสอบระบบ web ด้วย library ชื่อว่า Enzyme ซึ่งจะจำลองการทำงานของ React component ขึ้นมาให้ เราได้ทำการติดตั้ง configuration ตลอดจนเริ่มเขียนชุดการทดสอบแรกไปแล้ว ใน Part 2 นี้จะเริ่มพัฒนาระบบเครื่องคิดเลขกัน โดยจะพยายามเริ่มด้วยชุดการทดสอบ หรือคิดก่อนว่าเราจะทำอะไร และ ต้องได้อะไรออกมา แน่นอนว่ายังคงใช้ Enzyme นั่นเอง มาเริ่มกันดีกว่า

สิ่งที่ต้องคิดและออกแบบก่อนคือ เครื่องคิดเลขของเราเป็นอย่างไร ?

ทั้ง feature และหน้าตาของระบบ เพื่อความง่ายของระบบเลยให้มีความสามารถดังนี้

มีช่อง input ให้ใส่ 2 ตัว
สามารถเลือกบวก ลบ คูณและหารได้
แสดงผลของการทำงาน

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

ขั้นตอนที่ 1 ในหน้าจอการทำงานของเครื่องคิดเลข ต้องมีอะไรบ้าง ?

ต้องมี form 1 form
ต้องมีช่องให้กรอกตัวเลข 2 ช่อง
ต้องมีปุ่มให้กดคือ บวก ลบ คูณหาร นั่นคือ 4 ปุ่ม
ต้องมีที่ว่างสำหรับการแสดงผลลัพธ์

คิดอะไรไม่ออกเขียนชุดการทดสอบก่อนเลย [gist id="14c1928deed2f1adb94bcad4a834d7f2" file="test_01.js"] แน่นอนว่าผลการทดสอบต้องไม่ผ่านอย่างแน่นอน ดังนั้นเริ่มเขียน code เพื่อให้ชุดการทดสอบผ่าน ตรงนี้ก็เอาที่สบายใจนะครับ ว่าจะสวยงามกันอย่างไร สำหรับผมก็เขียนง่าย ๆ แบบนี้เพื่อให้ผ่านก็พอ [gist id="14c1928deed2f1adb94bcad4a834d7f2" file="1.js"] หลังจากที่ชุดการทดสอบแรกผ่านไปแล้ว คำถามที่ใครหลาย ๆ คนน่าจะคิดคือ ชุดการทดสอบนี้มันไม่น่าเชื่อถือเลยนะ ? เนื่องจากทำการตรวจสอบแบบหลวม ๆ มาก คำตอบคือ ใช่แล้ว นั่นคือสิ่งที่นักพัฒนาต้องเพิ่มชุดการทดสอบ เพื่อทำให้เรามีความมั่นใจขึ้น ดังนั้นนักพัฒนาทั้งหลายลองหยุดคิดหน่อยสิว่า ต้องเพิ่มชุดการทดสอบอะไรบ้าง เน้นว่า เพื่อทำให้มั่นใจหน้าแรกของเครื่องคิดเลขนะ ยังไม่ต้องมี action หรือ event อะไรเลย จากนั้นก็ลงมือทำกันเลยนะ ผมมั่นใจว่า ทุก ๆ คนจะมีชุดการทดสอบที่แตกต่างกัน ดังนั้นอย่าลืมเอามา share กันนะ

ขั้นตอนที่ 2 เมื่อการแสดงผลเรามั่นใจแล้ว มาถึงการทำงานหลักกัน

ซึ่งมีเรื่องหลัก ๆ ให้คิดคือจะทดสอบอะไรดี ในตอนนี้มี 2 ส่วนงานคือ ส่วนที่ 1 การคำนวณบวก ลบ คูณและหาร นั่นคือ Unit test ปกติ ส่วนที่ 2 การทดสอบกรอกข้อมูลผ่าน form จากนั้นเลือกการคำนวณและแสดงผลด้วย Enzyme

ในตอนนี้เรากำลังฝึกเชียนชุดการทดสอบ ดังนั้นเขียนมันไปทั้งคู่เลยดีกว่า

เริ่มจากการเขียน Unit test ของการบวก ลบ คูณและหารกันก่อน จะเขียนบวกให้ดูกันก่อน [gist id="14c1928deed2f1adb94bcad4a834d7f2" file="test_02.js"] ผลที่ได้จากการทดสอบคือ พังสิครับ !! เพราะว่า function plus() มันยังไม่มี ดังนั้นก็ทำการสร้างมันขึ้นมาและเขียน logic การทำงานดังนี้ [gist id="14c1928deed2f1adb94bcad4a834d7f2" file="2.js"] ในตอนนี้เราก็จะมีชุดการทดสอบ 2 ตัวแล้วนะ

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

เมื่อเรียบร้อยแล้ว เรามาทดสอบการทำงานของ Calculator component ด้วย Enzyme กัน

เป็นการทดสอบมุมมองของคนใช้งานนั่นคือ

ทำการกรอกข้อมูลตัวเลข 2 ตัว
ทำการเลือกว่าจะทำอะไรระหว่าง บวก ลบ คูณ หาร นั่นคือการกดปุ่ม
แสดงผลการทำงาน

มาเริ่มเขียนชุดการทดสอบดีกว่า ทำสักตัวให้ดูคือ การบวกเลข 1 กับ 2 แน่นอนว่าต้องแสดงผลเป็น 3 ดังนี้ [gist id="14c1928deed2f1adb94bcad4a834d7f2" file="test_03.js"]

สำหรับชุดการทดสอบนี้ บอกให้เราเริ่มพัฒนา React app แบบจริงจังแล้วนะ

ทั้งการจัดการข้อมูลของ input ทั้งสองตัว ทั้งการดักจับ action ของการกดปุ่มบวก ทั้งการใช้งาน state เพื่อจัดเก็บข้อมูลผลการบวก ซึ่งถือว่ามีหลายสิ่งอย่างมาก ๆ มาดูในแต่ละส่วนกัน ส่วนที่ 1 คือ constructor สำหรับกำหนดค่าต่าง ๆ ทั้ง state เริ่มต้น ทั้ง element ต่าง ๆ ทั้ง function สำหรับการดักจับ event ของการกดปุ่ม [gist id="14c1928deed2f1adb94bcad4a834d7f2" file="3_1.js"] ส่วนที่ 2 คือส่วนของ function เมื่อทำการกดปุ่มบวก คือ onPlus() จะทำการแปลง input มาอยู่ในตัวเลขฐานสิบ จากนั้นทำการเรียกใช้งานการบวกเลขที่เขียนไว้ก่อนหน้าแล้ว เมื่อได้ผลลัพธ์จะทำการ update ค่าใน state ดังนี้ [gist id="14c1928deed2f1adb94bcad4a834d7f2" file="3_2.js"] ส่วนที่ 3 คือส่วนการแสดงผลนั่นเอง [gist id="14c1928deed2f1adb94bcad4a834d7f2" file="3_3.js"] ในส่วนนี้ต้องค่อย ๆ ทำไปทีละขั้นตอนนะ แล้วจะได้ผลการทดสอบดังนี้

เมื่อผ่านแล้ว ลองเพิ่มชุดการทดสอบของ ลบ คูณและหารดูนะครับ

ผลการทำงานของระบบที่สร้าง หน้าตาง่าย ๆ แบบนี้

จะเห็นได้ว่า ชุดการทดสอบจะช่วยสร้างความมั่นใจในการพัฒนาระบบให้เรา

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

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

ใน Part ต่อไปเราจะมาลองทดสอบรูปแบบอื่น ๆ กันบ้างนะ ค่อย ๆ ทำ ค่อย ๆ เรียนรู้กันไปครับ Code ตัวอย่างอยู่ที่ Github::Up1::Workshop React Testing ขอให้สนุกกับการ coding ครับ

อ่านเอกสารของ Angular ก็พบสิ่งที่น่าสนใจคือ สามารถทำการ run code ที่อยู่ใน Github repository ผ่าน browser ได้เลย ซึ่งมันทำให้ชีวิตนักพัฒนา Frontend ง่ายขึ้นมาก เพราะว่า ไม่ต้องทำการติดตั้งสิ่งใดเลย เพราะว่า การติดตั้ง dependency ต่าง ๆ บนเครื่องเราใช้เวลาสูงมาก ๆ เพราะว่า การแบ่งปันหรือทำงานร่วมกับคนอื่น ๆ มันยากขึ้นไปอีก ดังนั้นมาลองใช้งาน Stackblitz กันนะ https://video.twimg.com/tweet_video/DUWCW5WU8AAyhpl.mp4

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

เพียงแค่เปลี่ยน url จาก github.com/username/repo_name มาเป็น stackblitz.com/github/username/repo_name หรือต้องการไปยัง branch/tag/commit ก็ใช้ stackblitz.com/github/username/repo_name/tree/{branch|tag|commit} เท่านี้ก็ได้แล้ว สิ่งที่ Stackblitz ทำคือ ทำการ sync project ไป จากนั้นก็เริ่มใช้งานได้เลย ทั้งการจัดการ dependency ต่าง ๆ ทั้งแก้ไข code ทั้งการ reload code ทั้งการ run ระบบ ทั้ง URL ของระบบที่มีให้เลย ให้ง่ายต่อการ share ลองใช้งานกันดูนะดังรูป

Reference Website https://medium.com/@ericsimons/stackblitz-online-vs-code-ide-for-angular-react-7d09348497f4 https://blog.angular.io/run-angular-cli-repos-directly-in-your-browser-41332fd80901

เห็นในกลุ่มภาษา Go Thailand ที่ Facebook นั้นมีการใช้งาน Benchmark สำหรับวัดประสิทธิภาพการทำงานของ code ที่เขียนด้วยภาษา Go จึงทำการสรุปวิธีการใช้งานไว้นิดหน่อย ซึ่งมันง่ายมาก ๆ เพราะว่า เป็น package ที่มีมาในภาษา Go อยู่แล้ว มาเริ่มกัน

อย่างแรกเลย Benchmark จะอยู่ใน package testing นั่นเอง

ช่วยวัดประสิทธิภาพการทำงาน code ที่เขียนด้วยภาษา Go ทั้งความเร็ว ทั้งการใช้งาน resource ต่าง ๆ การใช้งานเป็นดังนี้ เราจะเขียนไว้ในไฟล์ test นั่นเอง ชื่อ function สำหรับการทดสอบ Benchmark นั้น จะขึ้นต้นด้วยคำว่า Benchmark ตามด้วยตัวอักษรใหญ่ของชื่อ testcase ตัวอย่างเช่น [gist id="70220b7c2ac78ef16ca80b74b3ce0b28" file="sample_test.go"] คำอธิบาย เขียนเหมือนกับชุดการทดสอบปกติเลย แต่มีข้อแตกต่างนิดหน่อยดังนี้

ชื่อขึ้นต้นด้วยคำว่า Benchmark
parameter ของ function จะเป็น testing.B
ทำการ run หลาย ๆ ครั้ง โดยที่ค่า b.N จะเพิ่มขึ้นเรื่อย ๆ จนกว่าผลการทำงานจะมีค่าที่เสถียร
function ที่ต้องทำการทดสอบต้องอยู่ใน loop ลักษณะนี้เท่านั้น

การ run ก็ไม่ยากเลย ดังนี้ ซึ่งต้องส่ง flag -bench เข้ามาในการทดสอบ สำหรับ run ทุก test case นั่นหมายความสามารถสามารถใส่ชื่อ test case ที่ต้องการ run ได้อีกนะ [code] $go test -bench=. [/code] หรือใส่ flag -run สำหรับชุดการทดสอบที่ต้องการเท่านั้น เช่น [code] $go test -run=XXXXXXX -bench=. [/code]

ยกตัวอย่างจากโจทย์ของกลุ่มภาษา Go ดังนี้

เลยนำมาทำ benchmark ตามที่พี่อูทำไว้บ้าง ได้ผลการทำงานดังนี้ [gist id="70220b7c2ac78ef16ca80b74b3ce0b28" file="run.text"] คำอธิบายจากผลการทดสอบ พบว่าแต่ละ test case ที่วัดผลมีเวลาการทำงานที่ต่างกัน คือ 1,297 และ 168 nanosecond ยิ่งตัวเลขต่ำยิ่งเร็ว ส่วนเลข 1,000,000 และ 10,000,000 จำนวนสูงสุดที่ run ใน 1 วินาที (ค่า duration ซึ่งเปลี่ยนได้ผ่าน flag -benchtime)

ถ้าอยากรู้ว่าแต่ละ function ใช้ memory ไปเท่าไร ?

ทำได้ดังนี้ เพิ่ม flag -benchmem เข้าไป ดังนี้ [gist id="70220b7c2ac78ef16ca80b74b3ce0b28" file="run2.text"] จะเห็นว่า BenchmarkChonlasith ในแต่ละรอบนั้นใช้ memory เฉลี่ยไป 208 byte มีการ allocate หรือจองไป 8 เป็นค่าที่มีประโยชน์สำหรับการปรับปรุง code ต่อไป เพื่อให้ลดการใช้งาน memory ลง ดังชุด code ที่ 2 นั่นเอง โดยที่ source code เอาไว้ที่ Github::Benchmark with Go อย่า optimize code เยอะจนอ่านกันไม่รู้เรื่องนะ Make it work Make it right Make it fast

แล้วยังสามารถนำไปวิเคราะห์การใช้งาน CPU/RAM หรือทำพวก profiling ได้อีกนะ

ขอให้สนุกกับการเขียน code

Android Studio 3.1 ปล่อย version stable ออกมาให้ใช้แล้ว (ใครใช้ Canary มาก็จะเฉย ๆ) ซึ่งมีความสามารถหลายสิ่งอย่าง ทั้งช่วยให้การพัฒนา app ง่ายขึ้น ทั้งการช่วยหาปัญหาของ app ได้ดีขึ้น มาดูกันหน่อย

ตัวที่ชอบมาก ๆ ครับ Lint สำหรับภาษา Kotlin นั่นเอง

สามารถใช้ผ่านคำสั่ง gradlew lint ได้เลย ช่วยตรวจสอบคุณภาพของ code ได้ง่าย ๆ ไม่ต้องไปใช้เครื่องมือตัวอื่นแล้ว [gist id="bbddcd626563a98ab61de6034de23d8f" file="1.txt"]

ส่วนใครที่ใช้พวก SQLite และ Room น่าจะชอบคือ SQL completion ให้

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

สำหรับการ build ที่น่าสนใจคือ D8 Dex Compiler นั่นเอง

ซึ่ง D8 เข้ามาเป็น default เลย ส่งให้ไฟล์ APK เล็กลง ส่งผลให้การ debug ดีขึ้น รวมทั้งช่วยทำให้การ build เร็วขึ้นด้วยนิดหน่อย รูปเปรียบเทียบขนาดของไฟล์ Dex

รูปเปรียบเทียบเวลาการ compile ของ Dex

ในส่วนของ Android Emulator ก็มี Quick Boot ให้ใช้งาน

ทำให้เราสามารถเปิด Android Emulator อีกครั้งเร็วขึ้น ในเอกสารบอกว่าใช้เวลาน้อยกว่า 6 วินาทีเลยนะ แต่หลังจากที่เปิดครั้งแรกต้องบันทึก session ไว้ดังนี้ ไปที่ Settings ของ Android Emulator จากนั้นเลือกให้เลือก Ask สำหรับการบันทึก quick-boot state ดังรูป

จากนั้นทำการปิด Emulator จะถามว่าต้องการบันทึกหรือไม่

ถ้าตอบ Yes จะทำการบันทึก state ดังรูป

จากนั้นลองเปิด Emulator ขึ้นมาใหม่จะเร็วมาก แต่เปลือง disk น่าดูเช่นเดิม ส่วนการใช้ Memory ก็สูงกว่า Android Studio ไปแล้วนะ !!

สิ่งที่ชอบอีกอย่างคือ Network Profiling

ช่วยทำการวิเคราะห์การใช้งาน network ของ app ที่สะดวกมากขึ้น ซึ่งทำการแยกออกเป็น Thread ชัดเจนมาก ๆ

ดู VDO เพิ่มเติมได้ที่นี่ https://www.youtube.com/watch?v=nnnW0nehPEA รออะไรไป Download หรือ Update กันเลย