cc :: somkiat

วันนี้มีโอกาสแบ่งปันเรื่อง React in the RIGHT way ที่งาน ReactBKK 2.0.0 น่าจะเป็นเรื่องพื้นฐานที่สุดในงานแล้ว มีเป้าหมายเพื่อให้คำแนะนำสำหรับขั้นตอนการเรียนรู้เกี่ยวกับ React เป็นการเรียนรู้แบบมีขั้นตอนดังนี้ เนื่องจากเอกสารและบทความเกี่ยวกับ React และ Ecosystem มันเยอะมาก แน่นอนว่า มันยากสำหรับผู้เริ่มต้นอย่างมาก ดังนั้นจึงขอนำเอาขั้นตอนการเรียนรู้จาก React Howto มาแบ่งปัน

เริ่มจากการทำความเข้าใจก่อนว่า React สร้างมาเพื่ออะไร ?

สร้างมาเพื่อแก้ไขปัญหาของระบบขนาดใหญ่ ที่มีการเปลี่ยนแปลงข้อมูลจำนวนมาก ปัญหาที่ตามมาคือ ระบบทำงานช้า การ render ช้า เมื่อข้อมูลมีการเปลี่ยนแปลง !!! โดย React นั้นส่งผลต่อแนวคิดในการพัฒนาอย่างมาก ทั้ง Virtual DOM และ Component-Driven Development ยังไม่พอ React ถูกสร้างมาสำหรับ นักพัฒนาที่ชอบลองของใหม่ ๆ และ ผู้เชี่ยวชาญ ดังนั้นจึงไม่ใช่เรื่องแปลกที่มันจะยากสำหรับผู้เริ่มต้น !!

จากนั้นมาเริ่มต้นกับ React กัน

พื้นฐานที่จำเป็นอย่างมากสำหรับการเริ่มต้นคือ JavaScript เนื่องจากเป็นการพัฒนาในส่วนของ Frontend ต่อมาทำการอ่านและทำตาม Getting start React จาก Official website ซะ แนะนำให้ทำตามจนจบ จะสังเกตุได้ว่า ตัวอย่างนั้นไม่ต้องติดตั้งอะไรให้เสียเวลา รวมทั้งไม่ต้องมาตั้ง project structure อะไรให้วุ่นวายอีกด้วย เขียนเพียง HTML + CSS + JavaScript เท่านั้น พร้อมด้วยภาษาใหม่ที่เรียกว่า JSX (JavaScript eXpression) ที่ต้องทำการศึกษาเพิ่ม ในส่วนนี้ทำให้เราเข้าใจการใช้งาน React ได้ไม่ยาก ตัวอย่าง code ของ Hello World React [gist id="ad1eb29408829d3ed688c5b54a218e83" file="hello.html"] ถ้าไม่ต้องการ download อะไรมากก็เขียน code ผ่าน CodePen ก็ได้ ปล. เอกสารต่าง ๆ เยอะมาก ดังนั้นแนะนำให้ลองศึกษาและทำตามไปเรื่อย ๆ ผลที่ได้รับกลับมามันคุ้มค่ามาก ๆ ที่สำคัญยังไม่ต้องติดตั้งอะไรให้มากมาย

ต่อมาเรื่องที่สำคัญมาก ๆ คือ การออกแบบ Component

เป็นเรื่องที่ผมให้ความสำคัญอย่างมาก ถ้าออกแบบไม่ดีแล้ว จะส่งผลเสียต่อระบบอย่างมาก โดยแต่ละ component จะทำงานอย่างใดอย่างหนึ่ง แต่ละ component ต้องเป็น dumb component หรือ component ที่ไม่รู้อะไรเลย ส่วนพวก business logic อย่างนำมาใส่ใน component เด็ดขาด !!

ส่งข้อมูลต่าง ๆ เข้ามายัง component ผ่านสิ่งที่เรียกว่า props ส่วนสถานะต่าง ๆ จะผ่าน state

จะเห็นได้ว่า ถ้า component มีจำนวนมาก ๆ

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

มีคำถามจากผู้ฟังว่า เรียนรู้เพิ่มเติมจากที่ได้ดี ? ผมแนะนำให้ดู VDO เพิ่มเติ่มที่ EggHead.io :: Getting Start With Redux

การเรียนรู้ต่อจาก JSX คือ ES6 และ TypeScript

เนื่องจากเป็นมาตรฐานใหม่สำหรับภาษา JavaScript แน่นอนว่า browser ยังไม่สนับสนุน ดังนั้นจำเป็นต้องนำ JavaScript compiler มาใช้งานด้วย เช่น Babel สำหรับการแปลง code ที่เขียนด้วย ES6 ไปเป็น code JavaScript เพื่อให้สามารถทำงานได้บน browser นั่นเอง มาถึงตรงนี้ จะเห็นได้ว่า มีหลายอย่างให้ศึกษากันเลยนะ !!

ยังไม่พอเรื่องของ Dependency Manager ก็สำคัญ

ซึ่งปัจจุบันมีทางเลือกให้ลองทางคือ NPM และ Yarn

ต่อมาเรื่องของ JavaScript Bundler

เมื่อมีการใช้งาน NPM/Yarn ในการพัฒนาแล้ว นักพัฒนาจะเขียน component/module ต่าง ๆ ด้วย CommonJS แน่นอนว่า code ต่าง ๆ เหล่านี้ไม่สามารถทำงานได้บน browser ดังนั้นจึงต้องทำการแปลงและรวมไปอยู่ในไฟล์ JavaScript รวมไปถึงพวก CSS อีกด้วย โดยเครื่องมือที่ได้รับความนิยมสูงได้แก่ WebPack

ส่วนตัวอื่น ๆ ที่มีการนำมาใช้งานเช่น RollUp และ Browserify เป็นต้น

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

เมื่อเข้าใจแล้ว ก็สามารถใช้เครื่องมือทุ่นแรงอื่น ๆ ได้แล้ว

Create React App และ Next.js สำหรับการสร้าง project และส่วนการ build ต่าง ๆ

สุดท้ายลงมือทำเถอะนะ

ผมทำการแปลเป็นภาษาไทยไว้ที่ Up1 :: React Howto Slide อยู่ที่นี่ https://www.slideshare.net/up1/react-in-the-right-way

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

ในวันพุธที่ 7 มิถุนายนนี้ทางกลุ่ม Robotframework66 จะจัดงาน meetup ขึ้นมาครั้งแรกที่บริษัท ThinkNET โดยงานนี้ไม่มีหัวข้ออะไรมาก ซึ่งเปิดให้ส่งหัวข้อที่อยากจะมาแบ่งปันกันในกลุ่มดังนี้

ซึ่งแน่นอนว่า ได้พูดทุกหัวข้ออย่างแน่นอน (ถ้าคนเสนอมานะ)

ส่วนคนอื่น ๆ ที่เข้ามาร่วมงาน meetup ครั้งนี้ แนะนำให้ลองเตรียมเรื่องที่อยากจะแบ่งปัน และเรื่องที่อยากสอบถาม หรือ ข้อสงสัย หรือ ปัญหาต่าง ๆ ที่พบเจอ ในการนำ Robotframework ไปใช้งาน

โดยเรื่องต่าง ๆ ไม่จำเป็นต้องเกี่ยวกับ Robotframework ก็ได้ แต่ขอให้เป็นเรื่องเกี่ยวกับ Automation testing เท่านั้นเอง เนื่องจากไม่อยากให้ยึดติดในเครื่องมือมากนัก

คำถามที่ถามมาบ่อย ๆ คือ บัตรเต็มแล้ว มาได้ไหม ?

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

เรื่องพื้นฐานสำหรับ Robotframework ซึ่งจะแนะนำในงาน

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

การติดตั้ง
การทดสอบบน browser ต่าง ๆ
การเขียน Robotframework ที่ดี
การอ่านเอกสาร
การใช้งาน Library ต่าง ๆ ของ Robotframework
Tips การใช้ command line

ปิดท้าย ถ้าใครมีเครื่อง Notebook ให้นำติดตัวมาด้วยนะครับ

ช่วงท้ายอาจจะมีการทำ Kata ของ Robotframework กันนิดหน่อย เพื่อให้ได้อะไรติดไม้ติดมือกลับไปด้วย

และอย่าลืมเตรียมเรื่องที่จะแบ่งปันมาด้วยนะครับ (Give and Take) ไม่ต้องกลัวว่าจะเป็นเรื่องที่ง่ายหรือยาก ไม่ต้องกลัวว่าใครจะรู้แล้วหรือไม่ แค่มาแบ่งปันก็แจ่มแล้วครับ

ขอให้สนุกกับ Robotframework ครับ เจอกันครั้งที่ 2 ครับ !!!

จาก blog เรื่อง [Android] ลองใช้ ViewModel class จาก Architecture Component กันหน่อย มีคำถามว่า ถ้าอยากให้การสร้าง ViewModel ส่วนงามมากขึ้น แนะนำให้ใช้งาน Factory pattern มาช่วย !!! มันทำอย่างไร ? ดังนั้นจึงมาตอบคำถามไว้นิดหน่อย

ก่อนอื่นให้สร้าง class BookViewModelFactory ขึ้นมา

เพื่อทำหน้าที่สำหรับสร้าง BookViewModel ซึ่งใน class เราสามารถกำหนดค่าต่าง ๆ ที่จำเป็นต้องใช้ไปได้ ต่างจากเดิมที่ทำอะไรไม่ได้เลย ที่สำคัญแยกการทำงานออกมาจาก Activity อีกด้วย ตามแนวคิด SRP (Single Responsibility Principle) ทำให้การสร้าง ViewModel มีความยืดหยุ่นขึ้น [gist id="3b41e1ee6f1b4cdb5f9a2af08974938e" file="BookViewModelFactory.java"]

จากนั้นในส่วนของ Activity ให้เรียกใช้งาน

สังเกตุว่าในส่วนของ ViewModelProviders นั้นเราจะส่ง object ของ ModelViewFactory เข้าไปแทน เพื่อสร้าง object ของ ViewModel ที่ต้องการ [gist id="3b41e1ee6f1b4cdb5f9a2af08974938e" file="MainActivity.java"] ปล. ถ้านำ Dagger 2 มาใช้ด้วยจะแจ่มมากยิ่งขึ้น Reference Websites https://medium.com/@dpreussler/add-the-new-viewmodel-to-your-mvvm-36bfea86b159

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

เริ่มด้วยการดู VDO ที่น่าสนเกี่ยวกับ Angular ซึ่งมีเพียบบน Youtube

ทำให้เราเข้าใจมากขึ้น เพราะว่า บางทีการอ่านมันเข้าใจยาก ตัวอย่างเช่น https://www.youtube.com/watch?v=LS3aewTkfHI https://www.youtube.com/watch?v=wZ_5des_6_c

หลังจากนั้นลองทำตาม VDO นั่นคือลงมือสร้างระบบและเขียน code (Heros App)

ซึ่งสามารถดู code ตัวอย่างจาก Official website ของ Angular ได้เลย จากตัวอย่างต่าง ๆ จะพบว่า มีสิ่งที่ต้องเรียนรู้เพียบเลย เช่น

วิธีการสร้าง Angular project ?
Webpack ?
TypeScript ?
ES6 ?

ให้ทำเองตาม VDO และเอกสารน่าจะยากพอควร ดังนั้นมาทำแบบ step-by-step กัน

ขั้นตอนที่ 1 สร้าง Angular project ด้วย Angular CLI

ถ้าสร้างเองน่าจะรอดยาก ดังนั้นทางทีมพัฒนาจึงทำการสร้าง Angular CLI มาให้ เพื่อให้ง่ายต่อการสร้าง project เพื่อให้ง่ายต่อการสร้างส่วนต่าง ๆ เช่น component, router, service และ pipe เพื่อ start server เพื่อทดสอบ และ ตรวจสอบ code ด้วย lint ทั้งหมดนี้ทำงานบน command line ทำการติดตั้ง Angular CLI ด้วยคำสั่ง (ต้องติดตั้ง NPM ก่อนนะ) [code] $npm install -g @angular/cli [/code] จากนั้นทำการสร้าง project ด้วยคำสั่ง [code] $ng new ชื่อ project [/code]

ใช้เวลาการสร้างและติดตั้ง library ต่าง ๆ นานพอสมควร !!

[gist id="ba9f24823e9d3821acc5fe4b3838307b" file="1.txt"] ผลที่ได้คือ สร้าง folder ใหม่ขึ้นมาเป็นชื่อ project นั่นเอง เมื่อเข้าไปดูใน folder จะมีโครงสร้างดังนี้ [gist id="ba9f24823e9d3821acc5fe4b3838307b" file="2.txt"] คำอธิบาย มันเยอะมาก ๆ !! โดย folder ที่สำคัญมาก ๆ คือ src เป็นที่จัดเก็บ code ทั้งหมดของ project จากนั้นทำการ start server ด้วยคำสั่ง [code] $ng serve [/code] จะทำการ start server ที่ port 4200 ดังนั้นเข้าไปดูผลการทำงานได้ใน browser ดังนี้

ขั้นตอนที่ 2 มาศึกษาโครงสร้าง project ที่สร้างกันหน่อย

เริ่มอ่านจากไฟล์ index.html ซึ่งจะมี tag ที่งงมาก ๆ คือ app-root !! มันคืออะไร มาจากไหน คำถามเต็มไปหมด [gist id="ba9f24823e9d3821acc5fe4b3838307b" file="index.html"] มาหาคำตอบกัน โดยเริ่มจากเข้าไปดูไฟล์ชื่อว่า app.module.ts ใน folder app [gist id="ba9f24823e9d3821acc5fe4b3838307b" file="app.module.ts"] ให้สังเกตุว่าในส่วนของ bootstrap จะมีค่าคือ AppComponent bootstrap ใช้กำหนดว่า component ที่เป็นตัวหลักในการทำงาน โดยจะอ้างอิงไปยังไฟล์ app.component.ts ส่วนพวกไฟล์ css และ html หรือ template ก็จะชื่อเดียวกัน (เป็น convention พื้นฐาน แต่เปลี่ยนได้นะ) เมื่อเปิดไฟล์ app.component.ts จะเห็น selector ชื่อว่า app-root เห็นการกำหนด templateUrl และ styleUrls ไปยังไฟล์ต่าง ๆ น่าจะทำให้เข้าใจมากยิ่งขึ้น แน่นอนว่า ถ้าไม่ชอบก็แก้ไขกันได้เลย [gist id="ba9f24823e9d3821acc5fe4b3838307b" file="app.component.ts"]

ปล. เมื่อแก้ไขและบันทึกแล้ว จะทำการ compile และ reload หน้าให้แบบอัตโนมัติด้วยนะ มันสะดวกสบายมาก ๆ

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

มีเป้าหมายเพื่อสร้าง component และการใช้งาน routing เพื่อจัดการ URI สวย ๆ ของ project

สิ่งที่ต้องการคือ ในหน้าหลักของระบบจะมี menu ไปสองหน้าคือ Welcome และ Ippo

แสดงดังนี้

ดังนั้นสิ่งที่ต้องทำก่อนเลยคือ สร้าง component ทั้งสองขึ้นมาก่อนผ่าน Angular CLI ซึ่งจะทำการสร้าง folder ย่อยขึ้นมาใน folder app ตามชื่อของ component ดังนี้ [gist id="ba9f24823e9d3821acc5fe4b3838307b" file="create_component.txt"] ต่อจากนี้ก็ไปเขียน code ในแต่ละ component ตามที่เราต้องการ ดูเพิ่มเติมได้จาก Github :: Up1 :: Angular Ippo สิ่งที่ angular CLI ทำให้อีกคือ การเพิ่ม import component ในไฟล์ app.module.ts ให้ด้วย [gist id="ba9f24823e9d3821acc5fe4b3838307b" file="app.module_v2.ts"] เมื่อทุกอย่างเรียบร้อยมาทำการสร้าง Routing สำหรับ URI ไปยัง component ต่าง ๆ กันดีกว่า เพื่อสร้าง link ของแต่ละ menu จากหน้าหลัก โดยสิ่งที่ต้องการคือ

/welcome สำหรับหน้า link Welcome และ ให้เป็น default page ของระบบ ถ้าไม่เจอ URI ใด ๆ ก็มาหน้านี้
/ippo สำหรับแสดงหน้า link Ippo

ให้ทำการเพิ่ม code ในไฟล์ app.module.ts ประกอบไปด้วย การ import RouterModule ทำการกำหนด routing ในส่วนของ NgModule ดังนี้ [gist id="ba9f24823e9d3821acc5fe4b3838307b" file="app.module_v3.ts"] เพียงเท่านี้ก็สามารถสร้าง component และ routing ของระบบแบบง่าย ๆ ได้แล้วครับ Demo ของระบบผมเอาขึ้นไว้ที่นี่ Demo Hello with Ippo

มาถึงตรงจะนี้แล้วจะอ่านกันไปทำไม ลงมือทำเถอะนะ ยังมีเรื่องต่าง ๆ ให้ศึกษาอีกมากมาย

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

ปัญหาที่มักพบเจอเกี่ยวกับการสร้าง Container สำหรับ JVM คือ การกำหนดขนาดของ memory ให้นั่นเอง ซึ่งพบว่า ถึงแม้จะกำหนดขนาดของ memory ตอนสร้าง container ไปแล้ว แต่ตัว JVM มันก็ยังมีค่าของ Max Heap Size (Estimated) เป็นค่าที่สูงกว่า ตัวอย่างเช่น [gist id="df4d754001b4c2a5b5db33d9c164a43d" file="1.txt"] คำอธิบาย กำหนดขนาด memory ของ container ให้ที่ 100 M แต่ Heap Size ดันไปที่ 444.50M ?? ลองคิดดูสิว่า ถ้าเราดันไป run ระบบงานของเราด้วย java ปกติ แน่นอนว่าเดี๋ยว JVM ใน container นี้โดน terminate แน่นอน ++

ปล. ปกติแล้วค่า default ของ Max Heap Size จะอยู่ที่ 1 ใน 4 ส่วนของหน่วยความจำหลัก !!

วิธีการแก้ไขปัญหานี้ คือ ทำการเพิ่ม option สำหรับ JVM ไปนิดหน่อย เพื่อกำหนดขอบเขตของการจอง memory ของ Heap นั่นเอง ดังนี้ [gist id="df4d754001b4c2a5b5db33d9c164a43d" file="2.txt"] จะเห็นได้ว่า Max Heap ไม่เกินหน่วยความจำที่กำหนดให้แต่ละ container แล้ว แต่มันใช้ไปประมาณ 2 ใน 4 เลยนะ ดังนั้นลองกำหนดขนาดของ memory สำหรับ container สัก 1 GB สิ [gist id="df4d754001b4c2a5b5db33d9c164a43d" file="3.txt"] ผลที่ได้คือ จองหน่วยความจำไป 1 ใน 4 จริง ๆ นะ ถ้าต้องการให้ JVM จอง memory ทั้งหมด สามารถใส่ -XX:MaxRAMFraction=1 เขาไปเพิ่มได้ [gist id="df4d754001b4c2a5b5db33d9c164a43d" file="4.txt"] ดังนั้นการ configuration ค่าต่าง ๆ ของ JVM จึงมีความสำคัญมาก ๆ ปล. ใช้ memory เยอะจริง ๆ นะ Reference Websites https://dzone.com/articles/running-a-jvm-in-a-container-without-getting-kille

อ่านเจอบทความเรื่อง Stack Overflow: Helping One Million Developers Exit Vim เป็นเรื่องที่ไม่เชื่อก็ต้องเชื่อ เพราะว่าข้อมูลมันบอกอย่างนั้น นั่นคือมีคนเข้ามาดูคำถาม How to exit the Vim editor ? มากกว่า 1 ล้านครั้ง แสดงว่า Vim มันใช้ยากจริง ๆ นะ !! แสดงดังรูป

จากบทความนั้นผู้เขียนให้เหตุผลไว้อย่างน่าสนใจ

ว่าทำไมถึงต้องหาวิธีออกจาก Vim นั่นคือผู้ใช้งานเหล่านั้นไม่ได้ใช้งาน Vim แต่มีเหตุต้องเข้ามายัง Vim เช่น

การ commit ผ่าน git โดยไม่ใส่ -m
การเข้ามาโดยบังเอิญ

มาดูข้อมูลกันเพิ่มเติมจาก Stack Overflow กันหน่อย

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

มาดูกันว่า traffic มาจากประเทศไหนบ้าง ?

มีอีกมุมมองที่น่าสนใจคือ ภาษาโปรแกรมของผู้ที่เข้ามาดู

ซึ่งส่วนใหญ่จะเป็นกลุ่มของภาษาโปรแกรมที่ไม่จำเป็นต้องใช้ Vim เลย !! น่าสนใจมาก ๆ

ส่วนคำถามอื่น ๆ ที่มีจำนวนการเข้ามาดูสูง ๆ เช่น

วันนี้คุณออกจาก Vim ได้หรือยัง ?

วันนี้ลองใช้งาน Junit 5 ในงานนิดหน่อย พบว่าหลาย ๆ อย่างจาก JUnit 4 มันหายไป หลายอย่างเพิ่มมา ทั้งทำให้ยากและง่ายขึ้น มีสิ่งหนึ่งที่น่าสนใจคือ การทดสอบกับ Exception เนื่องจากของเดิมจาก JUnit 4 นั้นมีทางเลือกให้เยอะ ทั้ง try-catch (ไม่ควรทำนะ) ทั้ง @Rule ทั้ง expected ใน @Test ใน JUnit 5 นั้นไม่มี แต่ได้เพิ่ม assertion มาให้เลย ดังนั้นลองมาใช้งานกันดูหน่อย [gist id="3ac0f783261716088c9a8f8b288ad170" file="ExceptionTest.java"] คำอธิบาย ใน JUnit 5 นั้นจะมี org.junit.jupiter.api.Assertions#assertThrows มาให้เลย ใช้สำหรับการตรวจสอบ exception parameter ตัวที่ 1 คือ Exception ที่คาดหวัง parameter ตัวที่ 2 คือ Executable ใช้เรียก class ที่ต้องการทดสอบ

ชีวิตดูลำบากขึ้นหรือเปล่านะ ?

Source code ตัวอย่างอยู่ที่นี่ Github::Up1::Junit 5 with exception

หลังจากที่ทำการ review หลาย ๆ ระบบ พบปัญหาคล้าย ๆ กันคือ ไม่ยอมระบุ version ของ library ที่ใช้งาน หรือทำการระบุ version แบบเป็นช่วง ปัญหาที่พบประกอบไปด้วย

ใช้ library version ไหนกันแน่
เมื่อ library ที่ใช้มีการ upgrade ก็พังกันหมด
build ผ่านบ้างไม่ผ่านบ้าง
test ผ่านบ้างไม่ผ่านบ้าง
เจอ bug แปลก ๆ อีก

สาเหตุหลัก ๆ มาจากคนใช้งาน หรือตัว package manager ที่ใช้งานกัน ?

เมื่อไปดู package manager ของภาษาต่าง ๆ พบว่า

มีความสามารถให้ระบุ version แบบ เป็นช่วงได้ เช่น มากกว่า หรือ น้อยกว่า ที่น่ากลัวไปกว่านั้น คนใช้งานก็ดันใช้งานมันอีก ผลที่เกิดขึ้นคือ พากันเข้าป่ากันใหญ่เลย !! ตัวอย่างการใช้งานที่ผิด ๆ [gist id="6d86832cfe7c6512d97b5824df0c12c3" file="problem.txt"] ปล. Dependency Hell คือปัญหาใหญ่ของหลาย ๆ ภาษาโปรแกรมเลยนะ !! ปล. บางตัวแนะนำให้ใช้ semantic versioning ก็ไม่ค่อยรอด !! ปล. บางตัวไปดึง library มาจาก Version Control เช่น Git และ Bitbucket ก็ไม่รอดอีก เพราะว่าอ้างไปที่ HEAD หรือ branch !! (แนะนำให้ใช้ tag หรือ commit hash นะ)

ปัญหาต่าง ๆ เยอะมาก ทั้งจากคนใช้งาน ทั้งจาก package manager

ดังนั้น ถ้าต้องการแก้ไขหรือลดปัญหาลงไป ขอแนะนำดังนี้

ให้ระบุ version ของ library ที่ใช้ไปเลย
ให้ทำการ copy source code ของ library ใน version ที่ใช้งานลงมาที่ระบบเราด้วย เช่น go vendor เป็นต้น จากนั้นทำการจัดเก็บไว้ใน version control
ให้ทำการจัดเก็บไฟล์ binary ของ library ไว้ใน version control ด้วยเสมอ
ใช้ไฟล์version lock ด้วยเสมอ
- Gemfile.lock สำหรับ bundlr
- Shrinkwrap สำหรับ npm
- Glock สำหรับ go

วิธีการต่าง ๆ เหล่านี้ จะช่วยเหลือให้การ update library ง่ายขึ้น จะช่วยเหลือให้การ update library ปลอดภัยมากขึ้น รวมทั้งทุกสิ่งอย่าง จะอยู่ภายใต้ version control โดยสิ่งเหล่านี้เป็นพื้นฐานที่สำคัญของระบบ Continuous Integration และ Continuous Delivery ต่อไป ถ้าพบว่า package manager มีปัญหาก็ให้ทำการแก้ไขเถอะนะ เพราะว่า การพัฒนา software มันก็ยากอยู่แล้ว อย่ามาทำส่วนอื่น ๆ ให้ยากตามไปอีกเลยนะ

ปล. หรือว่าปัจจุบันยังไม่รู้เลยว่าใช้ library อะไรและ version อะไรกันบ้าง ?

Reference Websites https://dzone.com/articles/package-management-stop-using-version-ranges

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

พบว่าระบบกว่า 80% ในปัจจุบัน

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

คำถาม แล้ว source code ที่มีคุณภาพมันคืออะไร เป็นแบบไหนกัน ?

คำตอบในมุมมองของผมประกอบไปด้วย

1. Source code ที่ดีนั้น ผู้อื่นต้องสามารถอ่านได้และเข้าใจได้ง่าย

บ่อยครั้งที่ code เหล่านี้ต้องถูกดูแลรักษาจากคนอื่น ๆ ที่ไม่ใช่คนเขียน ลองคิดดูถ้าเป็นเราไปรับ source code เหล่านั้นมาดูแลต่อ เราจะชื่นชม หรือ ด่า ? ดังนั้นแค่เพียงทำงานได้อย่างถูกต้องคงยังไม่พอ Make it work จากนั้นต้อง Make it right

2. Source code ที่ดีนั้น ต้องง่ายต่อการขยับขยาย

บ่อยครั้งที่ระบบงานที่เราพัฒนาเสร็จไปแล้ว ต้องทำการเพิ่มและแก้ไขความสามารถต่าง ๆ ดังนั้นลองดู source code ที่เขียนขึ้นมาสิว่า มันง่ายต่อการเพิ่มความสามารถใหม่ ๆ เข้าไปไหม รวมทั้งง่ายต่อการรองรับผู้ใช้งานที่สูงขึ้นไหม ดังนั้นแค่เพียงทำงานได้อย่างถูกต้องคงยังไม่พอ Make it work จากนั้นต้อง Make it right และ Make it fast

3. Source code ที่มีการจัดการเรื่อง Technical Debt

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

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

ดังนั้นสิ่งที่ดีกว่าคือ เมื่อเจอปัญหาก็ให้หาทางแก้ไขมันซะ เพื่อทำให้มันดีขึ้นกว่าเดิมอยู่เสมอ อย่าเสียน้อยเสียยาก เสียมากเสียง่าย !!

สุดท้ายแล้ว source code ที่ดี

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

วันนี้คุณใส่ใจกับ source code กันบ้างไหม ?

วันนี้ไปดู release note ของ Docker edge version (v17.05.0 ce) พบว่า มีความสามารถที่กำลังต้องการคือ Multi-stage build ซึ่งช่วยทำให้การสร้าง image ของระบบงานได้ง่าย และสะดวกขึ้น ที่สำคัญยังช่วยลดขนาดของ image อีกด้วย มาลองใช้งานกันดู

ก่อนอื่นมาดูขั้นตอนการสร้าง image แบบปกติกันก่อน

ระบบตัวอย่างเป็นการสร้าง image ของระบบที่พัฒนาด้วยภาษา Go ซึ่งส่วนใหญ่มักจะสร้าง image ขึ้นมาสองตัวคือ

สำหรับทำการ build เพื่อ compile และสร้างไฟล์ binary ของระบบ
สำหรับการ deploy นั่นคือทำการทำเอาไฟล์ binary จาก image ตัวที่ 1

ปล. บางคนก็ทำเพียง image เดียวเท่านั้น แต่ผลที่ได้คือ ขนาดของ image ที่ใหญ่มาก ๆ เพราะว่ามีทั้ง OS + Golang (257MB), Library และ source code ทั้ง ๆ ที่เราต้องการเพียง OS และไฟล์ binary เท่านั้นเอง !! ดังนั้นขอแนะนำให้ทำเป็น 2 image น่าจะดีกว่า ซึ่งวิธีการนี้เราเรียกว่า Builder pattern ดังนั้นต้องสร้าง Dockerfile ขึ้นมา 2 ไฟล์ (ชีวิตดูลำบาก) การนำไฟล์ binary จาก container หนึ่งไปอีก container หนึ่งทำอย่างไร ? เช่นการ map volume หรือ copy ข้าม container กันเลย ตัวอย่าง script ของการใช้งาน [gist id="c6c98aae33c7d43126147b914e052a12" file="build.sh"] ผลที่ได้คือ image 2 ตัวดังนี้ [gist id="c6c98aae33c7d43126147b914e052a12" file="build.txt"] จากนั้นทำการสร้าง container จาก image ที่ได้คือ my_image:latest เช่น [code] $docker container run --rm -p 8080:8080 my_image:latest [/code] ปกติก็ใช้วิธีนี้กัน ซึ่งก็ใช้งานได้ดีนะ

มาดูกันต่อสิว่าแล้ว Multi-stage build มันเป็นอย่างไร ?

จากวิธีการข้างต้น ต้องจัดการ Dockerfile 2 ไฟล์ ซึ่งดูลำบากน่าดู ดังนั้นจะดีไหม ถ้ายุบให้เหลือเพียงไฟล์เดียว น่าจะสบายขึ้นไหม ? จากวิธีการข้างต้น จะสร้าง image ขึ้นมา 2 ตัว ซึ่งต้องลบ image ตัวแรกออกไปตลอด ดังนั้นจะดีไหม ถ้าเราสร้างไฟล์ image เดียวไปเลย เราสามารถเขียน Dockerfile แบบใหม่ได้ดังนี้ [gist id="c6c98aae33c7d43126147b914e052a12" file="Dockerfile_multi"] คำอธิบาย

COPY --from=0 คือการบอกว่าให้ copy ข้อมูลจาก image แรก โดยเริ่มจากตำแหน่งที่ 0
หรืออาจจะใช้ COPY --from=build ก็ได้นะครับ ทำให้อ่านเข้าใจง่ายขึ้นอีก
จากตัวอย่างทำการ copy ไฟล์ app ซึ่งเป็นไฟล์ binary มายัง image ที่สอง

ทำการสร้าง image ด้วยคำสั่ง [code] $docker image build -t my_demo . -f Dockerfile_multi [/code] จากนั้นก็ทำการสร้าง container จาก image ชื่อว่า my_demo เพียงเท่านี้ก็เป็นอันเรียบร้อย สำหรับการเริ่มใช้งาน Multi-stage build ง่ายขึ้นไหมนะ ? ตัวอย่าง source code และ configuration ต่าง ๆ อยู่ที่ Github::Up1::Docker with Multi-stage build

มีโอกาสไปพูดในงาน Code mania 101 ในช่วง Flash talk 5 นาที ซึ่งเรื่องที่เสนอไปคือ มาเขียน BAD code กัน มีเป้าหมายเพื่อ ชี้ให้เห็นความสวยงาม หรือ ประโยชน์จาก BAD code นั่นเอง

the beauty and horror of code is you get to see how other people think

BAD code คืออะไร

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

ความสวยงามและประโยชน์ของ BAD code มีอะไรบ้าง ?

มันช่วยทำให้เรารู้ว่าปัญหาคืออะไร นั่นคือ code smell นั่นเอง มันเป็นโอกาสในการเรียนรู้สิ่งใหม่ ๆ มันเป็นโอกาสในการปรับปรุงและพัฒนา code เหล่านั้นให้ดียิ่งขึ้น นั่นคือการ refactoring code นั่นเอง วันนี้นักพัฒนาเขียน BAD code แล้วหรือยัง โดย slide อยู่ที่นี่ [slideshare id=77031206&doc=sck-beauty-bad-code-170617144237&w=640&h=480]

จากบทความเรื่อง The evolution of scalable microservices นั้น ทำการอธิบายเกี่ยวกับ microservice ได้อย่างน่าสนใจ โดยเฉพาะในเรื่อง Microlith หรือ Micro Monolith ดังนั้นจึงทำการสรุปไว้นิดหน่อยดังนี้

ในปัจจุบันนั้นหลาย ๆ ทีม หลาย ๆ องค์กร

ต้องการที่จะปรับเปลี่ยนสถาปัตยกรรมของระบบ จาก Monolith ไปยัง Microservice กันมากขึ้น แต่ส่วนใหญ่ผลที่ได้ มักจะมีรูปแบบดังรูป

เป็นระบบที่ไม่สามารถ scale ได้ เป็นระบบที่ไม่มีความยืดหยุ่น เป็นระบบที่ recovery ได้ยากมาก เนื่องจากในแต่ละ service นั้นยังติดต่อสื่อสารผ่าน HTTP แบบ Synchronous นั่นคือ แต่ละ service ผูกมัดกันอย่างแน่นหนา ยิ่งมีการเรียกใช้ service ข้ามกันเป็นจำนวนมาก ผลที่ตามมาคือ latency และ response time ที่สูงขึ้น แล้วแบบนี้การแยก service ออกจากกันจะมีประโยชน์อะไรกัน !! โดยรูปแบบนี้จะเรียกว่า Microlith หรือ Micro Monolith นั่นเอง

ในบทความยังเน้นอีกด้วยว่าเป็น single instance service ซึ่งน่ากลัวมาก ๆ

เนื่องจากพร้อมตายได้เสมอ เนื่องจากยากต่อการ scale ที่สำคัญแทนที่แต่ละ service จะแยกกันอย่างชัดเจน ตามแนวคิดของ Microservice แต่กลับเป็นตรงกันเสียอย่างนั้น !!

วันนี้เรากำลังสร้าง Microlith ขึ้นมากันหรือไม่นะ ?

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

เรื่อง TDD with Golang จำนวน 2 วัน
เรื่อง application monitoring จำนวน 1 วัน
เรื่อง TDD with Java จำนวน 2 วัน
เรื่อง Introduction to Microservice จำนวน 2 วัน
เรื่อง Automation testing with Android จำนวน 1 วัน

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

เรื่อง TDD with Golang จำนวน 2 วัน

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

พื้นฐานของภาษา Golang สำหรับผู้เริ่มต้น
เรียนรู้เรื่องการเขียนชุดการทดสอบด้วยภาษา Golang ด้วย testing package
เรียนรู้การสร้างระบบ REST APIs ด้วยภาษา Golang ด้วย net/http package
เรียนรู้การทดสอบ REST APIs ด้วย Postman, Silk และ Robotframework

โดยเอกสารต่าง ๆ และตัวอย่าง source code อยู่ที่ Github :: Up1 :: TDD with Golang

เรื่อง Application monitoring จำนวน 1 วัน

ก่อนหน้านี้ทำการแบ่งปันเรื่อง การพัฒนาระบบ REST APIs ด้วย Spring boot ไปนิดหน่อย ดังนั้นสิ่งที่ผู้พัฒนาต้องใส่เพิ่มเข้าไปในระบบคือ ระบบ monitoring โดยสิ่งที่แบ่งปันไปประกอบไปด้วย

ทำการจัดเก็บข้อมูลต่าง ๆ ของการใช้งาน REST APIs ใน Prometheus ซึ่งเป็น Time serie database เหมาะกับข้อมูลการใช้งานมาก ๆ
ระบบ REST APIs ต้องมี endpoint สำหรับเก็บข้อมูลต่าง ๆ ในรูปแบบของ Prometheus
ทำการแสดงผลในรูปแบบ graph สวย ๆ ด้วย Grafana ซึ่งดึงข้อมูลจาก Prometheus มานั่นเอง

เรื่อง TDD with Java จำนวน 2 วัน

เป็น course ที่จัดโดยสถาบัน IMC ซึ่งจะจัดสอนทุก ๆ 3 เดือน โดยในครั้งนี้ทำการแบ่งปันเรื่องต่าง ๆ ดังนี้

ทำความเข้าใจเกี่ยวกับแนวคิด TDD (Test-Driven Development)
ลงมือเขียน test กันตามแนวคิด TDD
เรียนรู้เกี่ยวกับ JUnit ซึ่งเป็น library สำหรับเขียน unit test สำหรับภาษา Java
เรียนรู้การนำ Test Double มาใช้งานเช่น Stub และ Mock เป็นต้น
เรียนรู้เกี่ยวกับ SOLID ซึ่งเป็นแนวคิดในการออกแบบและพัฒนาที่น่าสนใจ
เรียนรู้เกี่ยวกับการทดสอบในส่วนของ User Interface ด้วย Selenium

เรื่อง Introduction to Microservice จำนวน 2 วัน

เป็นเรื่องราวเกี่ยวกับ Microservice ที่ผมไปสอนให้กับนักศึกษาเป็นเวลา 1 เทอม ซึ่งทำการยุบและสรุปเนื้อหาให้อยู่ภายใน 2 วัน โดยมีคนสนใจลงทะเบียนมาเรียนรู้และรับการแบ่งปันด้วย มีเนื้อหาดังนี้

ทำความเข้าใจเกี่ยวกับวิวัฒนาการของ Architecture ของระบบตั้งแต่ Monolith จนมาถึง Microservice
ทำความเข้าใจเกี่ยวกับ RESTful APIs
ทำการออกแบบ service โดยนำเอา Service Design Blueprint มาประยุกต์ใช้งาน ซึ่งทำให้เข้าใจกันมากขึ้น
ทำการพัฒนา service ด้วยภาษาต่าง ๆ ทั้ง Java, Golang และ NodeJS
ทำการทดสอบ service ต่าง ๆ ด้วย Postman, Silk และ Robotframework
ทำการ monitoring service ด้วย Prometheus และ Grafana เช่นเดิม

โดยเอกสารต่าง ๆ และตัวอย่าง source code อยู่ที่ Github :: Up1 :: Microservice และ Course Microservice

เรื่อง Automation testing with Android จำนวน 1 วัน

เป็น private class ซึ่งเป็นการแนะนำให้รู้จักกับการทดสอบแบบอัตโนมัติสำหรับ Android App โดยการทดสอบ Android app นั้นประกอบไปด้วย

การทดสอบที่ต้องการ Emulator/Device ด้วย Espresso
การทดสอบที่ไม่ต้องการ Emulator/Device ด้วย JUnit4

รวมทั้งการทำ Stress testing ด้วย Monkey testing ซึ่งเป็นพื้นฐานที่เหล่านักพัฒนา Android app ต้องเข้าใจ และสามารถนำไปประยุกต์ใช้งาน เพื่อให้เกิดประโยชน์ได้

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

เริ่มด้วยการทดสอบ !!

การเปลี่ยนแปลงต่าง ๆ สิ่งที่เราต้องรู้ก่อนเลยคือ ระบบเดิมนั้นเป็นอย่างไร ? การทำงานที่ถูกต้องเป็นอย่างไร ? มิเช่นนั้น จะเปลี่ยนได้อย่างถูกต้องกันอย่างไร !! หรือเมื่อทำการเปลี่ยนแปลงแล้ว อาจจะต้องแก้ไข bug ที่มีอยู่แล้วก็เป็นไปได้ !! ดังนั้นสิ่งที่ต้องมีคือ ชุดการทดสอบ ทั้ง unit test ทั้ง integration test ทั้ง acceptance test แล้วจะทำให้เรามั่นใจในการเปลี่ยนแปลง ซึ่งมันจะช่วยให้เรา foucs ไปที่ตัวภาษามากขึ้น ทำให้สามารถถึงศักยภาพของภาษาออกมาได้เยอะมาก ๆ ไม่ต้องมาห่วงหน้าพะวงหลัง ปล. ถ้าระบบเดิมทีมีอยู่ไม่มีการทดสอบละ ? สิ่งที่ต้องทำก่อนเลยคือ เขียนชุดการทดสอบด้วยภาษา Kotlin ก่อน เพื่อทดสอบระบบเดิมที่พัฒนาด้วยภาษา Java ซะ

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

ทำการแปลงชุด code เดิมที่เป็นภาษา Java

คำถามแรก ๆ เลยก็คือ เราจะเปลี่ยนแปลง code ชุดไหนดี ? คำตอบที่ง่ายสุด ๆ คือ class ตระกูล POJO (Plain Old Java Object) นั่นเอง แปลงมาอยู่ในรูปแบบของ data class ของ Kotlin ซึ่งช่วยลดจำนวนบรรทัดของ code ลงไปได้มากมาย จากนั้นตามด้วยพวก Utility class/Helper class ต่าง ๆ ส่วนที่ยากคือ ส่วนของ business logic นั่นเอง แต่ถามมีชุดการทดสอบครอบคลุมไว้ น่าจะมั่นใจมากขึ้น รวมทั้งเรื่องของ Nullable มันก็สำคัญมาก ๆ เช่นกัน ปล. มีคำถามว่า ต้องแปลง code จากภาษา Java เป็น Kotlin ให้หมดเลยหรือไม่ ? คำตอบคือ ไม่จำเป็นนะ เนื่องจาก Java และ Kotlin ก็ทำงานร่วมกันได้ ดังนั้นให้ทำการแปลงเท่าที่เรามั่นใจก่อน

ส่วน code ใหม่ ๆ ก็เขียนด้วยภาษา Kotlin ไป

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

ปล. สำหรับ Java Developer ที่ยังใช้ Eclipse IDE อยู่ ผมแนะนำให้ลองมาใช้ IntelliJ IDE ดูนะครับ ส่วน Android Developer ก็เช่นกัน มาใช้ Android Studio เถอะนะ

จากบทความเรื่อง What Are the Top 10 Causes for Unhappiness Among Developers ? ได้พูดถึงการศึกษาเรื่อง On the Unhappiness of Software Developers จึงนำมาแปลและสรุปไว้นิดหน่อย จากการศึกษาโดยพบว่ามีสาเหตุมากถึง 219 ข้อ (มันจะเยอะไปไหน) เพื่อให้เข้าใจได้ง่าย ๆ จึงแบ่งออกเป็น 2 กลุ่มคือ

Internal cause คือสาเหตุมาจากตัว developer เอง
External cause คือสาเหตุมาจากสิ่งอื่น ๆ ที่ developer ควบคุมไม่ได้ แถมส่งผลต่อ developer โดยตรงอีก

ดังนั้นมาดู 10 สาเหตุหลัก ๆ กันดีกว่า

สรุปไว้ดังรูป

จะพบว่า 7 ใน 10 ข้อคือ External cause

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

ส่วนอีก 3 ข้อเป็นเรื่องเกี่ยวกับ Internal cause

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

แน่นอนว่าสาเหตุต่าง ๆ เหล่านี้ส่งผลเสียมากมาย

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

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

โดยแสดงดังรูป มาจาก Consequences of Unhappiness While Developing Software

สุดท้ายแล้ว เราจะจัดการกับปัญหาเหล่านี้กันอย่างไรนะ ?

เช้านี้อ่านบทความเรื่อง How Airbnb use React สัมภาษณ์กับคุณ Leland Richardson ตั้งแต่ต้นปีที่แล้ว (นานเลยนะ) ซึ่งเป็น Lead Engineer ที่ Airbnb และเป็น contributor หลักของ Enzyme มาดูกันว่า ทำไมถึงเลือก React มาใช้ ? ใช้งาน React อย่างไรบ้าง ? มีอุปสรรคและความท้าทายอะไรบ้าง ? จึงทำการแปลและสรุปสิ่งที่น่าสนใจไว้นิดหน่อย ถึงจะเก่าหน่อยแต่คิดว่าน่าจะมีประโยชน์

เรื่องแรกที่น่าสนใจคือ การเริ่มนำ React มาใช้ในการพัฒนาอย่างไร ?

จะหาคนมาทำอย่างไร ? มีการสอนและแบ่งปันกันอย่างไร ? ซึ่งเป็นเรื่องที่เป็นปัญหาอย่างมากสำหรับหลาย ๆ องค์กร !!

โดยแบ่งเป็น 4 ส่วนคือ ส่วนที่ 1 สำหรับพนักงานใหม่ จะมีการจัด Bootcamp ระยะเวลา 3 สัปดาห์ เพื่อเตรียมความพร้อมทั้งเครื่องมือและ process ที่จำเป็นต่าง ๆ ส่วนที่ 2 มีการจัดการสอนภายในอยู่แล้ว ซึ่งใคร ๆ ก็สามารถเข้าร่วมได้ ส่วนที่ 3 น่าสนใจมาก ๆ คือ ใช้งาน Slack เป็นหลัก ซึ่งมีสิ่งต่าง ๆ ครบครัน เหมือนกับเป็น Internal Stack overflow นั่นเอง นั่นคือทุกคนพร้อมช่วยกันถามและตอบปัญหาต่าง ๆ รวมทั้งประวัติการพูดคุยต่าง ๆ สามารถค้นหาได้ง่ายอีกด้วย ซึ่งเป็นประโยชน์ต่อทีมมาก ๆ ส่วนที่ 4 ที่น่าสนใจเข้าไปอีกคือ วัฒนธรรมของการทำ Code Review ซึ่งบอกไว้ว่า เป็นวิธีการที่ดีมาก ๆ สำหรับการเรียนรู้สิ่งใหม่ ๆ ทำให้ความสามารถพัฒนาไปได้เร็วมาก

ดังนั้นเรื่องของ internal process/training มันจึงสำคัญมาก ๆ ถ้าหายากนัก ก็สร้างกันขึ้นมาเองเลย

เรื่องที่สอง ข้อได้เปรียบของ React ที่เห็นได้ชัดสุด ๆ คืออะไร ?

เนื่องจาก React ออกแบบในรูปแบบ component ดังนั้นเรื่องของ reusability และ portability จึงเด่นมาก อีกทั้งเอื้อต่อการ reactoring อีกด้วย

เรื่องที่สาม มีข้อดีก็ต้องมีข้อเสียกันบ้างสำหรับการใช้งาน React ?

สำหรับผู้เริ่มต้นนั้นมักจะงงและสับสนเกี่ยวกับการจัดการ state ต่าง ๆ เพิ่มเติมทั้ง props ทั้ง state อ่านไปอ่านมาเจอ Flux, Redux และอื่น ๆ อีกมากมาย รวมทั้ง ecosystem ที่อาจจะทำให้มึนงงไปได้หลายวัน โดยที่ทีมจัดการ state ต่าง ๆ ของ React app ด้วย alt library มีคำถามว่า ใช้งาน Relay และ GraphQL หรือไม่ ? ตอบเลยว่ายัง

เรื่องที่สี่ เขียน JavaScript ตามมตรฐานใด ?

ใช้งาน ES6 ซึ่งมีรูปแบบหรือ coding style ตามนี้

เรื่องที่ห้า ทดสอบ React App กันอย่างไร ?

เป็นสิ่งที่น่าสนใจมาก โดยแบ่งเป็นดังนี้

ใช้ Mocha สำหรับ Test Runner
ใช้ Chai สำหรับการ assertion หรือตรวจสอบผลการทำงาน
ใช้ Enzyme สำหรับการทดสอบ React library

ส่วนเครื่องมือที่ขาดไปไม่ได้เลยก็คือ lint ซึ่งแนะนำให้ลองเขียน custom rule เองให้เห็นนะ ช่วยลดความผิดพลาดต่าง ๆ ได้มากมาย

เรื่องที่หก จัดการ style ต่าง ๆ กันอย่างไร ?

สั้น ๆ คือ ใช้ SCSS (Sassy CSS)

เรื่องที่เจ็ด ทำการจัดการเรื่องของ rounting ของ React App กันอย่างไร ?

มีหลาย ๆ ส่วนใช้งาน react-router แต่ส่วนใหญ่จะไม่จัดการด้วย JavaScript นะ

มาถึงตรงนี้น่าจะพอทำให้เห็นการนำ React มาใช้ในการพัฒนาระบบบ้างนะครับ ขอให้สนุกกับการ coding ครับ

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

1. กำหนด coding guildline ซะ แล้วนำ lint มาใช้งาน

เพื่อตกลงรูปแบบของ code ร่วมกัน เพื่อให้มีรูปแบบเดียวกัน จากนั้นนำเครื่องมือมาใช้ เพื่อช่วยจัดรูปแบบของ code ให้ หรือบอกจุดผิดพลาด โดยตรงนี้ให้ทำการเขียน hook ใน git ก่อนการ commit ไปเลย (pre-commit) นั่นหมายความว่า เราจะไม่ยอมให้ code ที่มีรูปแบบผิดจากที่ตกลงกัน เข้ามาอยู่ใน repository ของทีมเลย

2. กำหนดรูปแบบของการตั้งชื่อสิ่งต่าง ๆ ซะ

จะใช้ camelCase หรือ snack_case ก็เอาสักทาง คุยกันซะ

3. ชื่อที่สามารถสื่อสารได้อย่างชัดเจน (Communicative Name)

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

4. อย่าเขียน code ที่ซ้ำ ๆ (Don’t Repeat Yourself)

เป็นสิ่งที่น่ากลัวมาก ๆ สำหรับการพัฒนา software ทั้งเสียเวลาในการสร้าง ทั้งเสียเวลาในการดูแลรักษา

5. ระวังการเขียน code ที่มีจำนวนบรรทัดเยอะ !!

ในแต่ละไฟล์ ในแต่ละ class ในแต่ละ method ไม่ควรเขียน code จำนวนบรรทัดเยอะ ๆ นะ เพราะว่าอ่านยาก เพราะว่าเข้าใจยาก เพราะว่าดูแลรักษายาก

6. พยายามแบ่งปัญหาใหญ่ ๆ ออกเป็นปัญหาย่อย ๆ (Work Breakdown)

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

7. พยายามแยกการทำงานเป็นส่วนหรือไฟล์ย่อย ๆ

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

8. พยายามเขียน code ที่ดูฉลาด ๆ ให้มันอ่านง่าย ๆ เข้าไว้

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

9. ทำการ refactor code กันอยู่อย่างสม่ำเสมอ

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

10. ลบ code กันบ้างนะ

code อะไรที่ comment ไว้ก็ลบไปบ้าง code อะไรที่ไม่จำเป็นก็ลบไปบ้าง code อะไรที่ไม่ถูกเรียกใช้ก็ลบไปบ้าง อย่าลืมว่าเราใช้ version control กันนะ

สุดท้ายแล้ว

การเขียน code ที่นั้นสิ่งแรกเลยคือ คนเขียนต้องเขียนและอ่านอย่างเข้าใจก่อน แต่สิ่งที่ต้องจำไว้คือ code เหล่านั้น ไม่ได้มีเพียงเราคนเดียวที่ใช้งานหรือทำงานด้วย ดังนั้นสิ่งที่ต้องตกลงร่วมกันคือ รูปแบบการทำงานร่วมกัน รูปแบบของ code ที่จะเขียนด้วยกัน ซึ่งจะทำให้ทีมง่ายต่อการเขียน อ่าน review และดูแลรักษาต่อไป ดังนั้น code ของทีมจะเน้นไปที่ consistency, simplicity และ readability ขอให้สนุกกับการเขียน code ครับ

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

ผมอ่านภาษาญี่ปุ่นไม่ออกเลยลองไปหาดูใน web แปล ได้ความว่ามันคือ Think Simple เขียนโดย Mr. Ryo Morikawa ซึ่งเป็นอดีต CEO ของ LINE CORPORATION แน่นอนว่า แค่ดูจากปกก็น่าสนใจแล้ว ดังนั้นจึงซื้อมาอ่านกันหน่อยสิ ว่าเป็นอย่างไรบ้าง มาเริ่มกันเลย หนังสือที่แปลเป็นภาษาไทยคือเล่มนี้

เรื่องที่สำคัญมาก ๆ สำหรับหนังสือเล่มนี้คือ

เนื่องจากโลกในปัจจุบันมีการเปลี่ยนแปลงที่รวดเร็วมาก ๆ (Era of rapid change) ดังนั้นสิ่งที่เราต้องพร้อมอยู่เสมอคือ จะตอบรับกับการเปลี่ยนแปลงเหล่านี้ได้รวดเร็วเพียงใด (Responding to change) นั่นคือ การคิดที่เรียบง่ายเข้าไว้ มีเป้าหมายหลัก ๆ เพื่อให้ธุริกิจประสบความสำเร็จ คือ

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

หัวใจของธุรกิจคือ การสร้างสิ่งที่ผู้ใช้งานต้องการและนิยมใช้งานออกมาอย่างต่อเนื่อง ดังนั้นอะไรที่ไม่มีใครใช้ ก็ตัดทิ้งไปซะ !!

ในหนังสือเล่นนี้ มีหลาย ๆ หัวข้อน่าสนใจ เช่น

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

Let’s start with Simply Thinking

ขอให้สนุกกับการอ่านหนังสือครับ

มีคำถามเกี่ยวกับจากการแบ่งปันเรื่อง TDD with Golang ที่เชียงใหม่ ดังนี้

จึงนำมาเขียนอธิบายไว้ใน blog นิดหน่อย เพื่อทำให้เข้าใจมากยิ่งขึ้น มาเริ่มกันเลย สิ่งที่ต้องการคือ ทำการสร้าง function สำหรับดึงข้อมูลจาก API มาเพื่อนำมาทำงานต่อ เป้าหมายที่ต้องการคือ ต้องสามารถทดสอบได้ด้วย โดยไม่จำเป็นต้องเรียกใช้ API ผ่านระบบ network เริ่มด้วย code ที่เขียนมานั้น ต้องง่ายต่อการทดสอบด้วย นั่นคือ นำ interface มาใช้งานนั่นเอง ดังตัวอย่าง [gist id="0c41c372efa84d2562b3f07a43d51c80" file="api.go"] คำอธิบาย ทำการสร้าง interface ชื่อว่า Counter ซึ่งมี method ชื่อว่า count() สำหรับดึงข้อมูล สิ่งที่สำคัญคือ การทำงานอยู่ใน method myProcess() ซึ่งมี argument 1 ตัวคือ interface Counter นั่นเอง ทำให้เราสามารถส่งอะไรก็ได้ ที่มีหน้าตาเหมือนกับ interface Counter โดยทำให้ code ทดสอบได้ง่ายดังนี้ [gist id="0c41c372efa84d2562b3f07a43d51c80" file="api_test.go"] และยังสามารถทดสอบใน case error ได้อีกด้วย ดังนี้ [gist id="0c41c372efa84d2562b3f07a43d51c80" file="api_test02.go"] เพียงเท่านี้ก็ทำให้เราสามารถสร้าง code ที่ทดสอบได้ง่ายขึ้นแล้วครับ

ปัญหาที่พบเจอ เมื่อทำการทดสอบ และสร้าง coverage report ออกมาด้วยคำสั่ง [code] $go test -coverprofile=cover.out $go tool cover -html=cover.out -o coverage.html [/code] จะเกิดปัญหาประมาณนี้ [code] cover: can't find "api.go": cannot find package "_/Users/somkiat/data/slide/golang/poc/" in any of: /usr/local/Cellar/go/1.8.3/libexec/src/_/Users/somkiat/data/slide/golang/poc (from $GOROOT) /Users/somkiat/go/src/_/Users/somkiat/data/slide/golang/poc (from $GOPATH) [/code] ทำให้ไม่สามารถสร้างรายงานของ code coverage ในรูปแบบ HTML ได้ ดังนั้นเรามาแก้ไขปัญหากันหน่อย

เมื่อไปดูใน issue list ของ Golang พบว่า

มี issue 17269 ชื่อว่า cmd/cover: cannot find package in local directory outside GOPATH ซึ่งเป็นปัญหาตั้งแต่ Golang 1.7.1 แล้ว ตอนนี้ลองทดสอบบน Golang 1.9 beta 2 ก็ยังเกิดปัญหาอยู่ เพราะว่า issue ยังอยู่ในสถานะ open !! แต่จากที่อ่านเห็นว่าจะแก้ไขใน version 1.9 และ 1.10 นะ

ปัญหาหลัก ๆ คือ หาไฟล์ใน project ของเราไม่เจอนั่นเอง

นั่นคือ ปัญหาเกิดจากการเข้าไปอ่านข้อมูลของ code coverage จากไฟล์ cover.out มีข้อมูลดังนี้ [code] mode: set _/Users/somkiat/data/slide/golang/poc/api.go:13.53,16.2 1 0 _/Users/somkiat/data/slide/golang/poc/api.go:18.37,20.18 2 1 _/Users/somkiat/data/slide/golang/poc/api.go:23.2,23.10 1 1 _/Users/somkiat/data/slide/golang/poc/api.go:20.18,22.3 1 1 _/Users/somkiat/data/slide/golang/poc/api.go:26.13,29.2 2 0 [/code] ปัญหาที่เกิดคือ ไม่เข้าใจ _/Users/somkiat/data/slide/golang/poc/ จะไปแก้ไข code ที่ cmd/cover tool ก็ดูลำบาก

ดังนั้นเรามาแก้ไขปัญหาเฉพาะหน้ากันก่อนดีกว่า

ด้วยการแก้ไขข้อมูลในไฟล์ cover.out ดังนี้ [code] mode: set ./api.go:13.53,16.2 1 0 ./api.go:18.37,20.18 2 1 ./api.go:23.2,23.10 1 1 ./api.go:20.18,22.3 1 1 ./api.go:26.13,29.2 2 0 [/code] ก็สามารถสร้างไฟล์ HTML ออกมาได้ดังนี้

แต่ถ้าต้องมาแก้ไขเองด้วยมือตลอด คงไม่ดีแน่ ๆ

ดังนั้นก็เขียน script มาใช้งานนิดหน่อย ตามนิสัยคนขี้เกียจดังนี้ [code] go test -coverprofile=cover.out sed -i.bak 's/_\/Users\/somkiat\/data\/slide\/golang\/poc/./g' cover.out go tool cover -html=cover.out -o coverage.html [/code] เพียงเท่านี้ก็พอไปวัดไปวาได้บ้างแล้ว ขอให้สนุกกับการ coding ครับ