Quantcast
Channel: cc :: somkiat
Viewing all 1997 articles
Browse latest View live
↧

[Git] ว่าด้วยเรื่องของการ merge

May 3, 2018, 1:13 am
$
0
0

สัปดาห์ที่ผ่านมานั้น มีโอกาสแบ่งปันความรู้เรื่อง การจัดการ source code ด้วย Git ซึ่งหนึ่งในคำถามและปัญหาคือ การ merge code นั่นเอง ถ้า merge แล้วไม่มีปัญหา คงไม่เป็นไร แต่ถ้า merge แล้วมีปัญหาที่ code ขัดแย้งหรือ conflict กัน จะต้องทำอย่างไรดี ? ที่สำคัญคือ Git มันทำการ merge อย่างไร ? ดังนั้นมาหาคำตอบกันดีกว่า

ในการจัดการ version ของ source code ด้วย Git นั้น

เรามักจะเริ่มด้วย branch มากกว่า 1 branch เสมอ ไม่ว่าจะเป็น master/dev, integration branch, feature branch และ git flow ยิ่งจำนวน branch ยิ่งเยอะ ปัญหาก็ยิ่งแยะ !! มันก็มีข้อดีมากมาย แต่สิ่งที่ตามมาคือ การ merge code !!
คำถามที่น่าสนใจคือ วันนี้นักพัฒนา merge code กันอย่างไร ?

ก่อนที่จะ merge เราเตรียมการอย่างไรบ้าง ?

ทำการตรวจสอบ code ที่ local หรือเครื่องของเราว่า มีสถานะล่าสุดตรงกับ remote หรือบน server หรือไม่ ? ด้วยคำสั่ง git fetch จากนั้นต้องทำย้ายไปยัง branch การทำงานหลักของเรา เพื่อทำการดึงการเปลี่ยนแปลงล่าสุดมาจาก remote ด้วยคำสั่ง [code] $git checkout $git pull [/code] ตรงคำสั่ง git pull นั้นจะมีการทำงาน 2 ขั้นตอนคือ [code] $git fetch $git merge [/code] สิ่งที่เราจะพบเจอมีอยู่ 2 อย่างคือ
  1. ถ้าไม่มีการเปลี่ยนก็ชิว ๆ ไป
  2. ถ้ามีการเปลี่ยนแปลง ก็จะเจอการ merge แบบขัดแย้งและไม่ขัดแย้ง !!
ซึ่งตรงการ merge นี่แหละเป็นสิ่งที่เราต้องมาดูในรายละเอียดกัน

การ merge โดยปกติจะเรียกว่า Fast Forward Merge

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

แต่ถ้า branch หลักแตกต่างจาก branch ของเราสิ่งที่เกิดขึ้นคือ Three-way merge

แค่ชื่อก็มี 3 ทางแล้ว ดูน่ากลัวและซับซ้อนน่าดู สิ่งที่เกิดขึ้นจากการ merge คือ ทำการสร้าง commit ใหม่ขึ้นมา 1 commit ซึ่งจะขึ้นต้นด้วยคำว่า Merge branch ... of เพื่อผูกหรือเชื่อมโยงของ branch ทั้งสองเข้าด้วยกัน pointer ในแต่ละ branch ไม่ได้เปลี่ยนแปลงเลย เกิดเป็น 3 ทางดังรูป ผลที่ตามมาคือ การ merge จะเกิด conflict หรือไม่นั่นเอง !! ถ้าไม่มี conflict ก็รอดไป แต่ถ้ามีจะเราสามารถใช้คำสั่ง git status เพื่อดูปัญหาได้ [gist id="7373d581ccf0acf8ef7e8ae3d122ef45" file="1.txt"] จากตัวอย่างเราลอเปิดไฟล์ xxx.txt มาดู จะเจอบรรทัดที่เกิด conflict จะมีตัว maker ใส่ไว้ดังนี้
  • <<<<<<< คือ จุดเริ่มต้นของ Conflict
  • ======= คือ เส้นแบ่งระหว่างการเปลี่ยนแปลงจาก branch หลัก กับ branch ของเรา
  • >>>>>>> คือ จุดสิ้นสุดของ Conflict
แสดงดังนี้ [gist id="7373d581ccf0acf8ef7e8ae3d122ef45" file="xxx.txt"] จากนั้นเราก็ต้องตัดสินใจว่า ส่วนไหนจะอยู๋หรือจะไป หรือต้องรวมกัน ตรงนี้นี่เอง ที่นักพัฒนาส่วนใหญ่ จะถามหาเครื่องมือในการ merge code !! แต่ว่าเครื่องมือมันไม่ใช่การแก้ไขที่ต้นเหตุนะ

ดังนั้นเพื่อลดความเสี่ยงของการ merge แล้วเกิด conflict

จำเป็นต้องแก้ไขที่ต้นเหตุคือ การคุยกัน และหนึ่งในการคุยกันที่ดีคือ commit-> pull-> push บ่อย ๆ นั่นเอง ส่วนเครื่องมือมันจะตามมาทีหลัง เมื่อทุกอย่างเรียบร้อยก็ทำการ add, commit ต่อไป ขอให้สนุกกับการ coding ครับ Reference Websites https://kolosek.com/git-merge
↧
Search

แนะนำ Appraise สำหรับ Visual Testing แบบอัตโนมัติ

May 4, 2018, 1:51 am
$
0
0

ในการพัฒนา software นั้น เรื่อง Look and Feel เป็นสิ่งที่สำคัญมาก ๆ software มีเพียงความสามารถที่ดียังไม่พอ ต้องดูดี สวยงามและใช้งานง่ายอีกด้วย คำถามที่น่าสนใจคือ เราทำการทดสอบกันอย่างไร ? แต่อาจจะกว้างไป เอาแคบลงมาคือ เราทำการทดสอบในส่วนของการแสดงผลอย่างไรบ้าง ? ในเชิงของการทดสอบจะเรียกว่า Visual Testing

ปกติเราน่าจะทดสอบด้วย คน

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

ดังนั้นเราควรลดเวลาการทดสอบลงไหม ?

เพิ่มคนทดสอบสิ !! หาเครื่องมือมาช่วยสิ ? ทดสอบแบบอัตโนมัติสิ ? ไม่ว่าจะเป็นทางไหน เราควรทำนะ ถ้าต้องการทดสอบในระดับนี้ จำเป็นต้องแยกการ build และ deploy ออกมาจากระบบงานเดิม เพราะว่าถ้ายังเอาไปผูกกับ End-to-End test อยู่ก็ไม่รอดแน่ ๆ เพราะว่าทำงานได้ช้ามาก ๆ และพังบ่อยสุด ๆ ดังนั้นต้องคิดใหม่ทำใหม่

ในบทความนี้ขอแนะนำ Appraise (Painless visual test automation)

ทีมผู้สร้างก็ไม่ใช่ใครที่ไหน คือ Gojko Adzic เขียนหนังสือที่น่าสนใจเช่น Specification by Example, Bridging the communication gab และ Fifty Quick Idea to Improve your Tests ทำการสร้าง Appraise ขึ้นมาจากความเจ็บปวดล้วน ๆ ซึ่งเจอในการพัฒนาที่ MindMup เป็น consumer application ส่วนใหญ่เป็นเด็กนักเรียนทั้งนั้น ดังนั้นในส่วนของ user interface (UI) จึงสำคัญมาก ๆ โดยขนาดของทีมเล็ก จำนวนคนน้อย คนดูแลและsupport ก็น้อยไปอีก แต่ตรงข้ามกับ code ที่มีขนาดใหญ่ขึ้นในทุก ๆ วัน ทำให้การพัฒนา feature ใหม่ยากและใช้เวลาสูงขึ้นมาก ๆ ถึงแม้จะมีชุดการทดสอบในส่วนต่าง ๆ ทั้ง unit, integration และ UI หรือ Visual Testing จำนวนมาก แต่ก็ยากต่อการดูแลรักษามาก โดยเฉพาะ Visual Testing ซึ่งใช้การตรวจสอบ DOM element เป็นหลัก

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

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

Appraise นั้นได้นำแนวทางของ Specification by Example มาใช้

นั่นหมายความว่า ในแต่ละ test case ต้องมี concrete example ที่ชัดเจน นำ test case เหล่านี้ไปทดสอบแบบอัตโนมัติ ทำการทดสอบด้วย Google Chrome Headless ซึ่งจะทำการ snapshot ส่วนที่ต้องการเป็นรูปภาพและเปรียบเทียบกับผลที่คาดหวังหรือไม่ ถ้าผลออกมาไม่ตรงกับที่คาดหวังแล้ว Appraise จะแสดงผลที่แตกต่างออกมาให้เห็น จากนั้นจะให้คนมา approve ว่าผลที่แตกต่างถูกหรือไม่ต่อไป ถ้าทำการยอมรับความแตกต่างก็จะบันทึกผลใหม่ให้ทันที ซึ่งง่ายต่อการดูแลรักษา test case อย่างมาก
ทำให้เครื่องมือตัวนี้ ไม่ได้ใช้แค่ QA/Tester เท่านั้น แต่ยังรวมเป็นถึงทีมทั้งหมดหรือ Cross-functional team นั่นเอง ทำให้แต่ละคนแต่ละทีม พูดคุยกันได้ง่ายขึ้น เห็นภาพของเป้าหมายตรงกัน ที่สำคัญช่วยให้การ review มีประสิทธิภาพยิ่งขึ้น

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

ทำการติดตั้งด้วยคำสั่ง [code] $npm install appraise -g [/code] ตัวอย่างง่าย ๆ เช่นต้องการแสดงข้อความเป็นสีเขียว มาลองเขียน test case กัน ซึ่งจะอยู่ใน directory ขื่อว่า examples ดังนี้ [gist id="d38dd20b4935aa735bdef1573dd1beb7" file="hello.md"] จากนั้นทำการสร้างไฟล์ hello.js สำหรับทดสอบจริง ๆ [gist id="d38dd20b4935aa735bdef1573dd1beb7" file="hello.js"] ทำการ run ครั้งแรก จะเกิด error ดังนี้ [gist id="d38dd20b4935aa735bdef1573dd1beb7" file="1.txt"] และจะสร้างผลการทดสอบใน directory results ขึ้นมาดังนี้ จะเห็นได้ว่า test case นี้ยังไม่ได้กำหนด expected result หรือผลที่คาดหวัง ดังนั้น เราต้องทำการ approve ผลการทำงานนี้ก่อน เพื่อทำการยอมรับผลนี้ ด้วยคำสั่ง [code] $appraise approve --page "hello" [/code] ผลที่ได้คือ
  • ทำการบันทึกหน้าจอเป็นรูปภาพให้
  • ทำการแก้ไขไฟล์ hello.md ด้วยการเพิ่มผลที่คาดหวังของ test case ลงไป
[gist id="d38dd20b4935aa735bdef1573dd1beb7" file="hello_update.md"] จากนั้นทำการทดสอบอีกครั้ง ก็จะผ่าน ดังนี้ [gist id="d38dd20b4935aa735bdef1573dd1beb7" file="2.txt"] ลองไปดูผลลัพธ์อีก เท่านี้ก็สามารถเริ่มต้นทดสอบได้แล้ว เพียงแค่เปลี่ยนไปเรียกระบบงานจริง ๆ เท่านั้น หรือถ้ามีการเปลี่ยนแปลง เช่นขยายขนาดของตัวอักษร ผลการทำสอบจะไม่ผ่าน และแสดงส่วนที่แตกต่างดังรูป ซึ่งง่ายมากและสะดวกมาก ๆ ลองใช้งานกันดูนะ

สุดท้ายแล้ว

เครื่องมือต่าง ๆ มันเป็นตัวช่วยให้เราทำงานร่วมกัน พูดคุยกันได้อย่างมีประสิทธิภาพเท่านั้น วันนี้เราพูดคุยและตกลงร่วมกันหรือยัง ? ขอให้สนุกกับการ coding Reference Website https://github.com/AppraiseQA/appraise https://www.infoq.com/news/2018/05/automated-visual-testing
↧
↧

สรุปแหล่งเรียนรู้และติดตามข่าวสารของภาษา Go

May 5, 2018, 2:55 am
$
0
0

ในกลุ่ม Golang Thailand มีการพูดเรื่องเกี่ยวกับ แหล่งเรียนรู้และติดตามข่าวสารเกี่ยวกับภาษา Go ว่ามีที่ไหนบ้าง ? ซึ่งก็มีแหล่งที่มาเพียบเลย ดังนั้นทำการสรุปไว้นิดหน่อย   ติดตามเพิ่มเติมได้ที่ Go mailing list Go ใน Google+ Google+ community Go ใน twitter Golang CLS Go News หรือค้นหาด้วย #golang น่าจะมีประโยชน์บ้างนะครับ ลองไป subscribe หรือ เพิ่มลงใน feed ไว้อ่านกันครับ
↧

Kotlin :: งง ๆ กับ keyword class และ object

May 6, 2018, 2:41 am
$
0
0

เขียน code ด้วยภาษา Kotlin ไปเรื่อย ๆ ก็มักจะเจอ keyword class และ object อยู่ตลอด บางครั้งก็ใช้ class keyword บางครั้งก็ใช้ object keyword มาดูกันหน่อยสิ

เมื่อไปดูในเอกสารจาก Kotlin พบว่า

Object นั้นมีทุกอย่างคล้ายกับ class มาก ๆ แต่ว่าจะมีเพียง instance เดียวเท่านั้นที่ถูกสร้างขึ้นมาเมื่อถูกเรียกใช้ครั้งแรก (Lazy instantiation) ถ้า object นี้ไม่ถูกเรียกใช้งาน จะไม่ทำการสร้าง instance ขึ้นมา และเป็น thread-safe โดย default อยู่แล้ว มันคือ Singleton pattern นั่นเอง เทียบกับภาษา Java ได้ดังนี้ [gist id="6d19313d231ca190c58e189f5169319e" file="MySingleton.java"] เมื่อแปลงมาเป็นภาษา Kotlin เขียนแค่นี้พอไม่ต้องเยอะ [kotlin] object MySingleton { fun hello() { print("Hello from object") } } fun main(args: Array) { MySingleton.hello(); } [/kotlin]

ยังไม่พอนะ เมื่อใช้ไปเรื่อย ๆ ก็จะเจอ Companion object อีก

ซึ่งจะถูกประกาศหรือใช้ภายใน class ด้วย keyword companion มันก็คือ การประกาศ static field/method ใน Java นั่นเอง ถ้าเป็น method ก็ออกแนว Factory pattern อีกแล้ว [kotlin] class DatabaseConnection { private constructor() {} companion object { fun create() = DatabaseConnection() } } fun main(args: Array) { val connnection = DatabaseConnection.create() } [/kotlin] และบ่อยครั้งเรานำ object expression มาใช้สำหรับสร้าง Annonymous class อีกด้วย หรือนำมาใช้สำหรับการสร้าง single instance ของ object ง่าย ๆแบบนี้ได้อีก ซึ่งอำนวยความสะดวกไม่ต้องไปสร้าง class หรือ data class มองว่าเป็น structure ของข้อมูลไปเลย [kotlin] fun main(args: Array) { val point = object { var x = 100 var y = 200 } print("x=${point.x}, y=${point.y}") } [/kotlin] ถึงตรงนี้น่าจะพอทำให้เข้าใจขึ้นมาบ้างแล้ว ขอให้สนุกกับการ coding ครับ
↧

บันทึกการเขียน Unit test สำหรับ RxJava บน Android app ไว้นิดหน่อย

May 9, 2018, 8:04 am
$
0
0

จดบันทึกไว้นิดหน่อยสำหรับการเขียน Unit test สำหรับทดสอบ Android app ที่พัฒนาด้วย Reactive for Java 2.x (RxJava) ซึ่งมีโครงสร้างง่าย ๆ คือ
  • Presenter สำหรับควบคุมการทำงานหลักของระบบ
  • Repository สำหรับจัดการการดึงข้อมูลจาก REST APIs
โดยนำ RxJava มาใช้ในส่วนของ Presenter เพื่อทำงานกับการดึงข้อมูลจาก Repository คำถามที่ตั้งไว้คือ จะทำการทดสอบในส่วนของ Presenter อย่างไรดี ? เพราะว่ามีการใช้งานทั้ง Repository หนักกว่านั้นคือ RxJava นั่นเอง ดังนั้นมาเขียนชุดทดสอบกันดีกว่า
ปล. ถ้าไม่ทดสอบใน Layer นี้ ก็ต้องไปทดสอบ Layer ที่สูงกว่านี้ ไม่ว่าจะเป็น UI testing และ Manual testing ต่อไป แต่จะใช้เวลาในการทดสอบสูง !!

มาดู code ในส่วนของ Presenter ก่อนดีกว่า

[gist id="f86f43eaf629ef7e29df05686fb3ad9a" file="LoginPresenter.kt"] คำอธิบาย การทำงานง่ายมาก ๆ คือ เรียกใช้งานการ authenication ผ่าน Repository จากนั้นก็รอผลลัพธกลับมา ซึ่งมีทั้งสำเร็จและไม่สำเร็จ ดังนั้นเราต้องทดสอบทั้ง 2 กรณีด้วยนะ การทดสอบมีความยุ่งยากนิดหน่อย เนื่องจากมีหลายสิ่งอย่างต้องควบคุม สิ่งที่เลือกใช้คือ
  • Mockito สำหรับการทำ Stub และ Mock ทั้ง class และ interface ที่ Presenter ต้องใช้งาน
  • class RxAndroidPlugin มาจาก Rx Android ใช้สำหรับการกำหนดค่าเริ่มต้นของการทำงาน
เรื่องของเครื่องมือนั้น จำเป็นต้องลงไปอ่านเอกสารของ library ที่นำมาใช้งานด้วย ทั้ง RxJava และ Rx Android มันสำคัญมาก ๆ นะ
ได้เวลาการเขียน Unit test แล้ว

ขั้นตอนที่ 1 ทำการกำหนดค่าต่าง ๆ ที่ต้องใช้งานในการทดสอบ

ทั้งการสร้าง stub และ mock ของ class และ interface ที่ Presenter ใช้งาน โดยสร้าง stub ของ class Repository สำหรับการกำหนดการทำงานตามชุดการทดสอบ และสร้าง mock ของ interface View เพื่อใช้ตรวจสอบพฤติกรรมการทำงาน รวมทั้งการกำหนดค่าต่าง ๆ สำหรับจัดการทดสอบทั้ง Rx Android และ Mockito แสดงดัง code [gist id="f86f43eaf629ef7e29df05686fb3ad9a" file="LoginPresenterTest.kt"]

ขั้นตอนที่ 2 เขียนชุดการทดสอบแรกคือ กรณีทำงานสำเร็จ

สิ่งที่คาดหวังคือ function หรือ method ใน interface View จะต้องถูกเรียกใช้งาน 1 ครั้ง เป็นการตรวจสอบพฤติกรรมการทำงานของ Presenter ว่าทำงานตามที่ต้องการหรือไม่ ? โดยสิ่งที่ต้องทำคือ การสร้าง stub ของ Repository ขึ้นมา และกำหนดผลจากการทำงานของ Repository ให้ทำงานได้อย่างถูกต้อง เขียนได้ดังนี้ [gist id="f86f43eaf629ef7e29df05686fb3ad9a" file="test_success.kt"]

ขั้นตอนที่ 3 เขียนชุดการทดสอบที่สองคือ กรณีทำงานไม่สำเร็จ

ในกรณีนี้มีเหตุการณ์มากมาย ที่ทำให้การทำงานไม่ถูกต้อง โดยสิ่งที่เลือกคือ กำหนดให้เกิด error เรื่องของ Network กลับมา ผลที่คาดหวังคือ function หรือ method ใน interface View จะต้องไม่ถูกเรียก เขียนได้ดังนี้ [gist id="f86f43eaf629ef7e29df05686fb3ad9a" file="test_error.kt"] เพียงเท่านี้เราก็สามารถเขียนชุดการทดสอบแบบง่าย ๆ ได้แล้ว ซึ่งน่าจะทำให้เรามั่นใจใน code ได้มากขึ้นมาบ้าง เมื่อไปดูค่า code coverage ก็ได้ออกมาดังนี้
อย่าลืมว่า เมื่อเลือกอะไรมาใช้แล้ว ใช้เป็นอย่างเดียวไม่พอ จำเป็นต้องทดสอบมันได้ด้วย
ขอให้สนุกกับการเขียน code ครับ
↧
↧

ว่าง ๆ มาทำทำความรู้จักกับ Navigation Architecture Component

May 11, 2018, 5:32 am
$
0
0

จากงาน Google I/O 2018 นั้นมีหลายสิ่งอย่างมาก ๆ สำหรับชาว Android จะเห็นได้ว่าทำการสรุปและรวบรวมชุดเครื่องมือต่าง ๆ ไว้ในชื่อใหม่ว่า Android Jetpack ซึ่งช่วยทำให้การพัฒนาง่ายและสะดวกขึ้น ลดจำนวน code ขยะหรือที่ไม่จำเป็นลงไป รวมทั้งช่วยพัฒนาระบบที่มีคุณภาพและเสถียรอีกด้วย บอกได้คำเดียวว่าเพียบ มีทั้งของเก่าและใหม่ มีตัวหนึ่งที่น่าสนใจคือ Navigation หรือ Navigation Architecture Component ดังนั้นมาทำความรู้จักกันหน่อย จะเข้าใจง่ายขึ้น ก็ต้องใช้งานสิ มาเริ่มกันเลย

Navigation Architecture Component คืออะไร ?

ตามชื่อมันเลย เอามาช่วยจัดการเรื่อง flow การทำงานของ app นั่นเอง โดยปกติเรามักจะออกแบบ flow การทำงานของ app ผ่านพวกเครื่องมืออื่น ๆ เช่นพวก Sketch หรือในกระดาษ ชาวพัฒนา Android app อาจจะแอบอิจฉาทางพัฒนา iOS app ที่มี Storyboard ใน XCode ให้ใช้งาน ทำให้เห็น flow การทำงานของ app ชัดเจนกว่า (ถ้าใช้งานและจัดการดี ๆ นะ) แล้วใน Android Studio ละ ไม่มีให้ใช้หรือ ? คำตอบคือ มันมีให้แล้ว แต่ต้องใช้งานผ่าน Android Studio 3.2 Canary นะ ซึ่งมีความช้า และ ความกิน Memory ไม่เป็นสองรองใครทั้งสิ้น

ปกติการจัดการ flow การทำงานของระบบ

เช่นจาก Activity ไป Activity ใช้ startActivity() ต่อจากนี้ไปไม่ต้องแล้ว มี NavController ให้เลย จากนั้นก็ระบุชื่อของปลายทาง และค่าที่จะส่งไปให้ผ่าน Argument ได้อีก สบายกันละ ถ้าใครเคยจัดการเรื่อง Flow การทำงานของ app น่าจะคุ้นกับพวก Flow หรือ Navigation หรือ Routing pattern

จากนั้นมาลองใช้งานกัน เพื่อทำความเข้าใจมันมากขึ้น

หลังจากที่ติดตั้ง Android Studio 3.2 แล้ว ก็ต้องทำการเพื่อ dependency ของ Navigation Architecture Component เข้ามายังไฟล์ /app/build.gradle ด้วย ดังนี้ [gist id="71a057ad07ac105e9b95a67ab8650b40" file="build.gradle"] ปล. มีชุด library สำหรับทดสอบให้อีกด้วยนะครับ ทำการสร้าง Android Resource File ชนิด Navigation ซึ่งจะสร้างไฟล์ใน directory navigation ขึ้นมา

เข้าสู่โลกของ Navigation กัน

ประกอบไปด้วย 3 ส่วนการทำงานหลัก คือ
  1. Destination list สำหรับหน้าจอทั้งหมดที่อยู่ใน navigation ของเรา
  2. Graph editor ซึ่งอยู่ตรงกลาง สามารถลากวางได้ง่าย ๆ หรือแก้ไขผ่าน XML ก็ได้
  3. Attribute editor สำหรับกำหนดค่าต่าง ๆ นั่นเอง
การใช้งานก็ง่ายมาก ๆ แค่เพิ่ม Destination เข้ามาก่อน สามารถเลือก Activity/Fragment ที่มีอยู่เข้ามาได้ หรือจะสร้างขึ้นมาใหม่ก็ได้ การสร้าง Destination ใหม่ ซึ่งจะเป็น Fragment นั่นเอง

มาดูสิ่งที่อยากทำดีกว่า

ผมต้องการให้ Activity หลักมีการทำงานดังนี้ หน้าที่ 1 คือ List จะมีปุ่มให้ใช้ 2 ปุ่มคือ ไปหน้า Detail และหน้า Setting หน้าที่ 2 คือ Detail หน้าที่ 3 คือ Setting ดังนั้นก็ทำการสร้างทั้ง 3 หน้าหรือ destination ขึ้นมา แสดงดังรูป ที่สำคัญยังทำการสร้าง code ของ Fragment หรือ Destination ให้ด้วยนะ โดย code อาจจะเยอะหน่อย แต่ก็อ่านเข้าใจได้ง่าย ซึ่งถ้าปกติจะมี action, argument และ interface/listener ให้ใช้งานด้วย แต่เพียงเท่านี้ยังไม่สามารถทำงานได้ เราต้องทำการเขียน code สำหรับจัดการ action การกดปุ่มในหน้า List ก่อน ซึ่งตรงนี้ก็ใช้คำสั่งง่าย ๆ ผ่าน NavController ไปเลย ดังนี้ [gist id="71a057ad07ac105e9b95a67ab8650b40" file="List.kt"] เมื่อทุกอย่างพร้อม เราก็ run app ทดสอบกันได้เลย น่าจะทำให้การจัดการ floe การทำงานของ app ง่ายขึ้นกว่าเดิมมาก ๆ และน่าจะทำให้ขั้นตอนการ app เปลี่ยนไปด้วย ขอให้สนุกกับการเขียน code ครับ
↧

Link ต่าง ๆ เกี่ยวกับ Android จากงาน Google I/O 2018

May 15, 2018, 6:51 am
$
0
0

นั่งดู VDO ของ session ต่าง ๆ จากงาน Google I/O 2018 รวมทั้งบทความต่าง ๆ พบว่ามันเยอะมาก ๆ เลยทำการสรุปไว้อ่านนิดหน่อย ไม่รู้ว่าจะอ่านและดูหมดหรือไม่ ?

เริ่มจาก VDO ทุก session เกี่ยวกับ Android มีทั้งหมด 63 เรื่อง

ประกอบไปด้วย
  • What’s new in Android ?
  • What’s new in Android Development Tool ?
  • Modern Android Development: Android Jetpack and Kotlin
  • What’s new in Architecture Component ?
  • Easy background processing with WorkManager
  • Manage UI navigation with Navigation Controller
  • How to Kotlin ?

เอกสารในเรื่องที่น่าสนใจ

Codelabs และ code ตัวอย่าง

↧

เริ่มต้นเขียน Automation Test กันดีกว่า

May 16, 2018, 9:50 am
$
0
0

มีโอกาสแบ่งปันเรื่องการทดสอบระบบงานแบบอัตโมมัติ (Automation Test) ทั้ง Web, API และ Mobile ใช้การทดสอบเป็นตัวหลักในการขับเคลื่อนการพัฒนา software เป็นสิ่งที่สำคัญและขาดไปไม่ได้เลย ช่วยทำให้เรามีความเชื่อมั่นต่อ code ที่เขียน อีกทั้งลดความกลัวจากการแก้ไข และช่วยให้เรากล้าทดลองทำในสิ่งใหม่ ๆ อีกด้วย แต่สำหรับการเริ่มต้นมันไม่ง่ายเลย จึงทำการสรุปสิ่งที่ควรจะรู้ไว้นิดหน่อย

กฏการเขียนชุดการทดสอบ โดยเฉพาะ Unit test ที่ดี

แต่ละ test case ต้องทำงานได้รวดเร็ว ในปัจจุบันต้องอยู่ในหน่วย nano/millisecone กันไปเลย ถ้าใครยังเป็นระดับวินาทีน่าจะผิดทาง ลองปรับกันดู ในแต่ละ test case ต้องเป็นอิสระแก่กัน นั่นคือแต่ละ test case จะไม่เกี่ยวข้องกัน ทำให้สามารถทดสอบแบบสุ่ม และ แบบขนานได้อีกด้วย แต่สิ่งที่พบเจอเป็นประจำคือ ผลจาก test case ที่ 1 เป็น input ของ test case ที่ 2 ผลจาก test case ที่ 2 เป็น input ของ test case ที่ 3 และ .... ถ้าเป็นแบบนี้บอกได้เลยว่า น่าจะมาผิดทาง เนื่องจากแต่ละ test case ผูกมัดกันไปหมด และต้องทำงานแบบเรียงลำดับกันด้วย จะไม่มีการทำงานร่วมกับระบบ Network และ Database ใด ๆ ทั้งสิ้น ถ้าทำงานด้วยน่าจะเป็น Integration หรือไม่ มันช้า !! และมักจะเกิดเหตุการณ์ที่ไม่สามารถควบคุมหรือไม่คาดฝันเยอะมาก ๆ ดังนั้นแต่ละ test case ต้องสามารถทำงานซ้ำ ๆ แล้วยังไม่ผลเหมือนเดิมทุกครั้ง ไม่ใช่ ทำงานผ่านบ้างไม่ผ่านบ้าง !! แบบนี้จะไม่มีใครเชื่อถือการทดสอบเลย สุดท้ายก็จะเลิกใช้ เลิกทำและกลับไปทำแบบเดิมก่อนหน้านี้ !! อะไรก็ตามที่ไม่สามารถควบคุมได้ เราต้องหัดเรียนรู้การควบคุม เนื่องจากมันจะทำให้เรามีปัญหาได้ ยกตัวอย่างเช่น เรื่องของเวลา และ Timezone เป็นต้น

โครงสร้างของชุดการทดสอบต้องดีด้วย

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

โดยสิ่งที่จะเน้นมาก ๆ คือ การคิดก่อนทำ (TDD)

นั่นคือ ก่อนที่จะเริ่มต้นทำ คุณต้องเข้าใจปัญหา หรือ มีเป้าหมายก่อน จากนั้นจึงแบ่งปัญหาใหญ่ออกเป็นปัญหาย่อย เพื่อให้แก้ไขปัญหาได้ง่ายขึ้น ค่อยทำไป test case by test case

ยังมีเรื่องของ Test Double อีก

ทั้ง Dummy, Stub, Spy, Mock และ Fake ซึ่งล้วนมีเป้าหมายที่ต่างกันไป แต่เป้าหมายที่เหมือนกันคือ ทำการควบคุมสิ่งที่ควบคุมไม่ได้ เพื่อให้เราสามารถเขียน test case ได้ดีขึ้น ยกตัวอย่างเช่น ถ้าต้องการทดสอบ buisiness flow ที่ต้องไปดึงข้อมูลจาก API และ Database คำถามคือ เราจะควบคุม API และ Database อย่างไร ? เพื่อให้เราสามารถทดสอบ business flow ได้ครบทุกเงื่อนไข ทั้ง success และ fail case คำตอบคือ ยากมาก ดังนั้นเราลองมาใช้แนวคิดของ Test Double มาช่วย

การทดสอบจะง่ายหรือไม่นั้น

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

มีคำถามว่า จะทดสอบระบบเดิมหรือ Legacy อย่างไร ?

ตอบง่าย ๆ คือ ถ้ายังไม่เข้าใจมันก็อย่าไปยุ่ง ตอบแบบนี้ อย่าตอบดีกว่า แต่สิ่งที่ควรเข้าใจคือ ของเดิมอย่าให้เพิ่ม นั่นหมายความว่า ถ้ามีการเพิ่มหรือแก้ไข ก็ให้เพิ่มชุดการทดสอบเข้าไป แน่นอนว่ามีปัญหาแน่ ๆ ดังนั้นเตรียมรับมือไว้เลย แต่จำเป็นต้องลงมือแก้ไขให้ดีขึ้น ยิ่งถ้ามี incident หรือ bug มาจาก production แล้วยิ่งดี ก็ให้เขียน test case เพื่อให้เกิดปัญหาจริง ๆ จากนั้นจึงลงมือแก้ไข ไปจนกว่า test case จะผ่าน ทำให้เราได้ test case มาแล้วนะ มันคือแนวทางของ Bug-Driven Development นั่นเอง ค่อย ๆ เพิ่มความเชื่อมั่นขึ้นไปเรื่อย ๆ เจ็บได้ แต่อย่าเจ็บซ้ำที่เดิม

บางคนบอกว่า เขียนชุดการทดสอบที่แย่ ก็อย่าเขียนเลยดีกว่า

แต่ผมมีความเชื่อว่า ถ้ายังไม่เขียนก็เขียนไปก่อน แล้วเรียนรู้จากผลที่ออกมาว่า ดีหรือแย่ แล้วปรับปรุงกันไป อย่าหยุด เพื่อหาสิ่งที่เหมาะสมกับเรา บางคนชอบเถียงหรือพูดคุยกันว่า จะเขียนชุดการทดสอบเรื่องอะไรบ้างดี ? ต้องเขียนทั้งหมดเลยไหม ? ตอบง่าย ๆ คือ เขียนให้หมด มั่นใจไหม ถ้าไม่มั่นใจ ต้องทำอย่างไรให้มั่นใจ แล้วเรียนรู้ แต่ถ้ายังไม่เขียนก็อย่าเพิ่งเถียงกัน ลงมือเขียนก่อน
วันนี้เราเขียนชุดการทดสอบกันหรือยัง ? ถ้ายัง ไปเขียนได้แล้ว Shut up and write test
↧
Search

แนะนำ Play with Kubernetes

May 24, 2018, 7:34 am
$
0
0

แนะนำแหล่งเรียนรู้เกี่ยวกับ Kubernetes (K8s) คือ Play with Kubernetes classroom เป็นระบบการเรียนรู้ผ่าน browser เหมือนกับ Play with Docker เลย ทำให้ไม่ต้องมาเสียเวลาในการติดตั้ง software ใด ๆ ซึ่งเหมาะมาก ๆ สำหรับผู้เริ่มต้น ประกอบไปด้วยเอกสารการใช้งาน มีทั้ง command line ให้ลองฝึกใช้งาน ดังนั้นมาใช้งานกันครับ เนื้อหาประกอบไปด้วย
  • การสร้าง cluster
  • การ build Docker image จาก source code ด้วย Docker compose
  • เริ่มต้นการ deploy ระบบด้วย Kubernetes
  • การใช้งาน Load balancer
  • การรองรับปริมาณการใช้งานเยอะ ๆ
  • การ roll out ระบบ
  • เรื่องของ auto scaling
  • Blue-green deployment และ canary release
  • สถาปัตยกรรม
  • การใช้งานผ่าน kubectl command
ถ้าใครอยากลองไปติดตั้งหรือ contributed ก็ไปที่ Github::Play with Kubernetes ได้เลย ถ้าใครไม่มีเครื่องของลองใช้งานก็ไปที่ Play with Kubernetes ได้อีกนะ
↧
↧

[Java] มาลองใช้งาน Test containers กัน

May 26, 2018, 10:20 pm
$
0
0

โดยปกติการทดสอบในระดับ integration test และ component นั้น มักจะทดสอบผ่านระบบจริง ๆ ซึ่งควบคุมได้ยาก ยกตัวอย่างเช่น การทดสอบกับ Database, Data store รวมไปถึงการทดสอบระดับ UI/Acceptance test ซึ่งต้องทดสอบผ่าน browser แน่นอนว่า การจัดการนั้นไม่ง่ายเลย แต่เมื่อเข้าสู่ยุคของ container แล้วนั้น เรื่องต่าง ๆ เหล่านี้จะง่ายขึ้น แต่แลกมาด้วยการเรียนรู้และเครื่องที่แรงขึ้น หนึ่งในเครื่องมือนั้นคือ Test containers ซึ่งเป็น library ที่พัฒนาด้วยภาษา Java 1.8 ที่สำคัญคือ ใช้งานร่วมกับ JUnit ได้เลย เหมาะมากสำหรับการทดสอบระบบงาน
ปล. เครื่องทดสอบต้องติดตั้ง Docker 17.06 ด้วยนะ และ JDK 1.8 ขึ้นไป
ดังนั้นมาเริ่มใช้งานกันหน่อย น่าจะเป็นอีกหนึ่งแนวทางสำหรับการพัฒนาและทดสอบระบบงาน ให้มีคุณภาพและลดความเสี่ยงต่าง ๆ ลงไป

ยกตัวอย่างการใช้งานกับ Spring Boot

สำหรับการทำงานร่วมกับ Database ผ่าน Spring Data JPA ปกติเราสามารถทดสอบผ่าน @DataJpaTest ได้เลย ซึ่งนั่นก็คือการทดสอบผ่าน Embedded database เช่น H2 เป็นต้น แต่ว่า Database จริง ๆ ไม่ใช่ Embedded database แน่นอน ยกตัวอย่างเช่น MySQL และ PostgreSQL เป็นต้น ซึ่งอาจจะส่งผลให้การทดสอบผิดพลาดหรือต่างไปจากของจริงก็เป็นไปได้มาก ดังนั้นถ้าใช้ Database จริง ๆ เหมือนกับ production กันเลยไหม โดยสามารถใช้ผ่าน Test container ได้ดังนี้ ขั้นตอนที่ 1 เพิ่ม dependency หรือ libray ของ Test containers เข้าไปก่อน ขั้นตอนที่ 2 ทำการกำหนด Image ของ database ที่ต้องการใช้ผ่าน Test containers เลือกใช้งาน PostgeSQL รวมทั้งกำหนดชื่อฐานข้อมูลและ username/password ให้เรียบร้อย ผ่านส่วนของ @ClassRule ของ Unit ดังนี้ [gist id="f6d306e654c6c648692995bac1a9a5b7" file="HelloContainerTest1.java"] ขั้นตอนที่ 3 ทำการกำหนด class Initialzer สำหรับ Spring Boot เพื่อให้ชุดการทดสอบไปเรียกใช้งาน Database ที่เรากำหนดไว้ในขั้นตอนที่ 2 [gist id="f6d306e654c6c648692995bac1a9a5b7" file="HelloContainerTest2.java"] ขั้นตอนที่ 4 เขียนชุดการทดสอบและ run มันซะ [gist id="f6d306e654c6c648692995bac1a9a5b7" file="HelloContainerTest3.java"] เพียงเท่านี้เราก็สามารถทดสอบระบบผ่าน Test containers ได้แล้ว ซึ่งง่ายขึ้นเยอะเลย แต่มันยังเป็น alpha version อยู่นะ ขอให้สนุกกับการ coding ครับ
↧

ลดละเลิกการเขียน Log เพื่อ Debug ระบบงานกันเถอะ

May 27, 2018, 1:04 am
$
0
0

ในการพัฒนาระบบงานนั้น บ่อยครั้งนักพัฒนาชอบเขียน code แสดงผลการทำงานในส่วนต่าง ๆ ออกมายังหน้าจอหรือ console เพื่อทำให้รู้ว่า การทำงานในแต่ละส่วนเป็นอย่างไรบ้าง หรือบางครั้งก็ใช้เพื่อหาจุดที่ทำงานผิดพลาด หรือ งง ๆ เรามักเรียกกันว่า การ debug เป็นวิธีการหนึ่งที่ดีนะ สำหรับการพัฒนาระบบงาน แต่ปัญหาที่พบเจอต่อมาคือ code ของการ debug เหล่านี้ ดันขึ้นไปอยู่บน production server ด้วยนะสิ ยิ่งถ้าเป็นฝั่ง frontend เช่น Web และ Mobile ยิ่งน่ากลัว เพราะว่า เราได้ทำการเปิดเผยข้อมูลการทำงานให้ผู้ใช้งาน หรือ ใครก็ไม่รู้ ดังนั้นสิ่งที่ควรทำก่อนคือ ถ้าใช้งานมันแล้ว ต้องจัดการให้ดี อย่าละเลย หรือถ้าเป็นไปได้ ก็ลด ละ เลิกลงซะ จะได้ไม่ต้องมาห่วงหน้าพะวงหลัง และทำผิดซ้ำ ๆ อีก ยิ่งไปดูผลสำรวจของนักพัฒนาฝั่ง Node.JS พบว่า ใช้งาน console.log() ในการ debug มากกว่า 80% กันเลยทีเดียว บางครั้งเราก็เรียกวิธีแบบนี้ ขำ ๆ ว่า CLTDD (Console.Log Test-Driven Development) หรือในฝั่ง Mobile เช่น Android App ก็มี log เยอะเหลือเกิน บ่อยครั้งไม่ปิดอีกต่างห่าง นักพัฒนาช่างใจดีเหลือเกิน เปิดเผยทุกสิ่งอย่างให้รู้หมดเลย ดังนั้นก็อย่าไปเขียนมันเลย !! ไปใช้แนวทางอื่นเถอะ เช่นการเขียน Test หรือว่าเป็นการใช้ความสามารถของ Android Studio ช่วยแทน
วันนี้นักพัฒนาเขียน log แล้วหรือยัง ? ถ้ายัง นั่นแหละดีแล้ว แต่ถ้าเขียนก็ ลด ละ เลิก ลงกันบ้างนะ
Reference Websites https://android.jlelse.eu/add-logs-without-using-code-bd49fe9202ca https://dev.to/hitman666/introduction-to-tdd-in-js-and-ionic-framework-1-4080 https://blog.risingstack.com/node-js-developer-survey-results-2016/ https://hackernoon.com/please-stop-using-console-log-its-broken-b5d7d396cf15
↧

ว่าด้วยเรื่องของ Scope ในภาษา Go

May 29, 2018, 3:27 am
$
0
0

เห็นในกลุ่มภาษา Go นั้นมี quiz เรื่องของ Declaration และ Scope ในภาษา Go รวมไปถึงเรื่องของ Block อีกด้วย อ่าน code ใน quiz แล้วยังงง ๆ เลยไปนั่งดู Specification ของภาษาหน่อย พบว่ามีรายละเอียดเยอะจริง ๆ ดังนั้นลองมาเขียน code กันหน่อย เริ่มด้วยตัวอย่าง code ซึ่งจะมี nest block [gist id="6145e3c1900f16027076311a0fa4dd83" file="1.go"] ผลที่ได้คือ ในบรรทัดที่ 15 นั้นจะ compile ไม่ผ่าน เนื่องจากไม่เห็นตัวแปร v จาก code จะพบว่า ตัวแปร v นั้นถูกประกาศใน block {} ซึ่งในบัรทัดที่ 15 นั้นอยู่นอก block มาดู code ตัวอย่างที่ 2 กันอีก ในบรรทัด 11 เพิ่มการกำหนดค่า 2 ให้กับตัวแปร v [gist id="6145e3c1900f16027076311a0fa4dd83" file="2.go"] ผลที่ได้คือ 2 2 แต่ถ้าเปลี่ยน code นิดหน่อยจากการกำหนดค่ามาเป็นการประกาศตัวแปร [gist id="6145e3c1900f16027076311a0fa4dd83" file="3.go"] จะได้ผลที่ต่างออกไปคือ 2 1 ซึ่งทำให้เห็นว่า scope หรือขอบเขตการใช้งานของตัวแปรนั้น ๆ ขึ้นอยู่กับว่ามันประกาศอยู่ตรงจุดไหน ถ้าประกาศอยู่นอกสุดแล้ว ข้างในหรือ innner block ก็ใช้ได้ดังนี้ [gist id="6145e3c1900f16027076311a0fa4dd83" file="4.go"] และใน level เดียวกันก็ไม่สามารถประกาศซ้ำได้นะ [gist id="6145e3c1900f16027076311a0fa4dd83" file="5.go"] พอลองมานั่งอ่านและเขียนดู ก็ทำให้เข้าใจขึ้นเยอะเลย ว่าแต่การเขียนแบบ nest block แบบนี้ไม่ค่อยได้ใช้งานเลย ขอให้สนุกกับการเขียน code นะครับ
↧

ว่าง ๆ มาปรับปรุงการทำงานของ Spring Boot ให้เร็วขึ้น

May 29, 2018, 9:47 pm
$
0
0

ปัญหาที่พบเจอในการทดสอบระบบที่พัฒนาด้วย Spring Boot

เมื่อเริ่มเขียนชุดการทดสอบของระบบที่พัฒนาด้วย Spring Boot นั้น ชีวิตก็จะสบายขึ้นมาเยอะ เนื่องจาก Spring Boot ได้เตรียม Spring Boot Unit test หรือ Integration test มาให้อยู่แล้ว แต่ขั้นตอนการทำงานภายในนั้น มันจะทำการสร้าง context ขึ้นมาทุกครั้ง ดังนั้นผลที่ตามมาคือ "ความช้า" และนี่แหละคือปัญหาที่ต้องเจอ จะแก้ไขหรือปรับปรุงอย่างไร เพื่อให้ทำการทดสอบได้รวดเร็วขึ้น

การแก้ไขในเบื้องต้นนั้น

จะพยายามเขียน Spring Boot Unit test (Slice testing) เท่าที่จำเป็นเท่านั้น ส่วนเรื่องอื่น ๆ ในการ mock ด้วย Mockito กับ JUnit มาช่วย ซึ่งทำการทดสอบได้อย่างรวดเร็ว แต่ไม่การันตีว่า ระบบจะสามารถทำงานได้ เนื่องจากเป็นการทดสอบส่วนย่อย ๆ เท่านั้น

มาหาต้นเหตุของปัญหา

เมื่อใช้งาน Spring Boot Unit test แล้ว ก็จำเป็นต้องรู้การทำงานภายในของมันหน่อย ง่าย ๆ ก็แค่ debug เท่านั้นเอง [code] $mvn test -Ddebug [/code] เนื่องจากเรามักจะใช้ @SpringBootApplication, @EnableAutoConfiguration และ @ComponentScan ผลที่ได้คือ Spring Boot มัน load class ต่าง ๆ เยอะมากจนน่าเกลียด ทั้ง class ที่ใช้งานและไม่ได้ใช้งาน นี่คือต้นเหตุของปัญหา [gist id="67cabf0589b54bf798b8563a9a6c4e88" file="1.log"]

การแก้ไขปัญหา

ก็ให้ทำการ load class เท่าที่จะใช้งาน ซึ่งไม่ง่ายเลยเพราะว่า มันเยอะมาก ๆ แต่ก็สามารถทำได้ด้วยการใช้ @Import เอง โดย class ต่าง ๆ ก็เอามาจาก log จากด้านบนนั่นเอง จากนั้นก็เลือกที่เราคิดว่า ต้องการใช้งาน แล้วทำการทดสอบใหม่อีกครั้ง ถ้าทำงานได้เช่นเดิมก็รอดตัวไป ยกตัวอย่างเช่น [gist id="67cabf0589b54bf798b8563a9a6c4e88" file="DemoApplication.java"] จากการใช้งานนั้น โดยปกติจะใช้เวลาในการทดสอบประมาณ 1 นาที เมื่อเปลี่ยนวิธีการตามข้างบนพบว่า เวลาเหลือเพียง 20 วินาที โดยที่วิธีการนี้ใช้ได้ทั้งระบบงานหลักและการทดสอบ มั่นใจได้ว่า เร็วขึ้นแน่นอน อีกอย่างที่น่าสนใจคือ โดยปกติแล้วนั้น Spring Boot ใช้ Apache Tomcat ต้องการใช้ Memory Heap ประมาณ 100 MB และมี Thread มากว่า 15 ตัว ใหญ่น่าดู ดังนั้นเราสามารถทำงาน exclude Apache Tomcat ออกไป แล้วใช้งาน Jetty หรือ Undertow แทน ก็จะดีขึ้นไปอีก
สุดท้ายแล้ว Spring Boot ถูกออกแบบมาสำหรับการทำ Service เล็ก ๆ หรือ Microservices ดังนั้นขนาดของ Service เราเป็นอย่างไร ? ตรงนี้น่าคิดมาก ๆ
ขอให้สนุกกับการ coding ครับ
↧
↧

สรุปสิ่งที่น่าสนใจจาก Technology Radar Vol. 18 เดือนพฤษภาคม

June 1, 2018, 8:08 am
$
0
0

ข้อมูลจาก Technology Radar Vol. 18 ล่าสุดนั้น หลัก ๆ เป็นเรื่องของเทคโนโลยีต่าง ๆ บน web browser ที่มากขึ้น ทำให้ฝั่งผู้ใช้งานใหญ่ขึ้นเรื่อย ๆ ส่วนการทำงานฝั่ง server ลดน้อยลงเรื่อย ๆ ยกตัวอย่างเช่น
  • WebAssembly
  • Web Bluetooth ทำให้ native application บน browser สามารถใช้งาน Bluetooth ได้เลย รวมทั้ง Physical Web ยิ่งทำให้การทำงานบนมือถือง่ายขึ้น
  • พวก CSS ก็ไม่น้อยหน้ามีทั้ง CSS Grid Layout และ CSS Modules ออกมาให้ใช้งาน

การใช้งาน Cloud น่าจะเป็นสิ่งพื้นฐานไปเสียแล้ว

ทั้ง Google Cloud Platform (GCP) ทั้ง Microsoft Azure ส่วนการจัดการในระดับ application นั้นจะใช้งาน Kubernetes กันเป็นหลัก ส่วนแนวปฏิบัติที่จำเป็นมาก ๆ คือ Continuous Delivery และ Infrastructure as a Code ซึ่งช่วยทำให้ง่ายต่อการ deploy ระบบงาน ซึ่งช่วยทำให้ง่ายต่อการเปลี่ยนแปลงสิ่งต่าง ๆ ของระบบงาน

ในการพัฒนา software เรื่อง security นั้นสำคัญและมีความจำเป็นอย่างมาก

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

ส่วนเรื่องของ IoT (Internet of Things) ก็ยังคงพัฒนาและปรับปรุงอย่างต่อเนื่อง

ทั้งแนวทางการพัฒนาที่ดี และเรื่องของ security ดังจะเห็นได้จากที่ Cloud Provider ต่าง ๆ ล้วนมีบริการต่าง ๆ ออกมาให้ใช้งาน ยกตัวอย่างเช่น Google IoT Core AWS IoT Microsoft Azure IoT Hub รวมทั้งยังมี platform ต่าง ๆ ออกมาสนับสนุนอีกด้วย เช่น EMQ และ Mongoose OS

ส่วนสิ่งที่น่าสนใจมาก และ เตือนไว้คือ

การกลับมาของ ESB (Enterprise Service Bus) ด้วยการใช้งาน Kafka เนื่องจาก Kafka ได้รับความนิยมใช้งานสูงมาก ๆ ทำให้หลาย ๆ องค์กร ก็นำไปใช้แบบผิด ๆ คือ นำ Kafka เป็นเป็นระบบแบบ centralize หรือแบบรวมศูนย์ แทนที่จะใช้กับ product/service นั้น ๆ ไป รวมไปถึงเรื่องของ API gateway ที่มาพร้อมกับ Microservices แนวทางของ API gateway เพื่อรวมศูนย์ของการเรียกใช้งาน Microservices ให้ง่าย รวมทั้งการจัดการเรื่องทั่วไปเช่น authentication, authorization และ rate limit เป็นต้น แต่เมื่อใช้งานไปเรื่อย ๆ พบว่า เรานำ business logic ไปใส่ในส่วนนี้ หรือที่เรามักเรียกว่า Middleware ทำให้ระบบงานมีความซับซ้อน และ ยากต่อการทดสอบอีกด้วย เรื่องใหม่ที่น่าสนใจคือ Generic Cloud Usage นั่นคือเรามักจะใช้งาน feature ที่มีอยู่ในทุก ๆ Cloud Provider เท่านั้น เพื่อง่ายต่อการประเมินค่าใช้จ่าย ที่สำคัญกลับทำให้เราไปผู้ติดกับ Cloud กันอีก ทั้ง ๆ ที่เราไม่ต้องการไปผูกติดกับสิ่งใดเลย ใช่ไหม ? ดังนั้นสิ่งที่ควรทำคือ พิจารณาว่า เราต้องการทำอะไร ใช้อะไรบ้าง จากนั้นจึงไปดูว่า ใน Cloud Provider ต่าง ๆ มีสิ่งที่เราต้องการหรือไม่ เพื่อใช้ให้เกิดประโยชน์สูงสุดนั่นเอง
ไป Download อ่านเพิ่มเติมได้ PDF :: Technology Radar Vol. 18
↧

สิ่งที่ควรทำก่อนจะเริ่ม Microservices

June 1, 2018, 9:09 am
$
0
0

ในเรื่องของ Microservices นั้นเรามักจะพูดกันถึง จะออกแบบ และ แยก service ออกมาเป็น Microservices กันอย่างไร ? จะต้องพัฒนาอย่างไร ? จะต้องทดสอบอย่างไร ? จะต้องดูแลอย่างไร ? แต่ก่อนที่จะไปกันไกล ให้กลับมาดูตัวเราเองก่อนว่า มีสิ่งที่ Microservices ต้องการหรือยัง ? ซึ่งเป็นความรู้และสิ่งจำเป็นพื้นฐานอย่างมาก ในมุมมองของนักพัฒนานั้น การทำอะไรที่มันเล็ก ๆ แยกส่วนการทำงานออกจากกันอย่างชัดเจน เป็นสิ่งที่ชอบมาก ๆ ( แต่หาไม่ค่อยเจอ ) ดังนั้นจึงชอบแนวคิดของ Modular และ Microservices อย่างมาก แต่เมื่อมองในมุมของ operation พบว่ามันน่าสะพรึงกลัวอย่างมาก เป็นเรื่องที่เครียดมาก ๆ เพียงระบบเดียวยังดูแลยากลำบาก เพียงระบบเดียวยังติดตั้งยาก เพียงระบบเดียวยัง ... ยากลำบาก ดังนั้นก่อนจะเริ่ม Microservices มาเตรียมสิ่งเหล่านี้ให้พร้อมก่อนดีกว่าไหม ?

1. เตรียม environment ได้เร็วไหม ?

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

2. ขั้นตอนการ deploy ระบบงานเร็วไหม ?

ยกตัวอย่างเช่น เมื่อมีการเปลี่ยนแปลง source code และ configuration ต่าง ๆ แล้ว ขั้นตอนการ build -> test -> package -> deploy นั้นมีความเร็วเท่าไร ? รวมไปถึงการ deploy ใน environment ต่าง ๆ เช่น QA/Test, UAT, Staging และ Production ใช้เวลาเป็นชั่วโมง เป็นวันหรือไม่ ? ยังทำแบบ manual หรือไม่ ? ถ้ายังเป็นเช่นนี้ ก็ให้ปรับปรุงและเปลี่ยนแปลงก่อนเลย ด้วยการกำหนดหรือสร้าง Deployment pipeline ขึ้นมา ทำงานแบบอัตโนมัติให้ได้มากที่สุด แต่สุดท้ายจำเป็นต้องเป็นแบบอัตโนมัติ

3. ระบบ Monitoring

ส่วนใหญ่เรามักมีระบบ Monitoring ทั้ง infrastructure และ application บน production server เท่านั้น แต่กลับไม่มีใน environment อื่น ๆ ทำให้เจอปัญหาได้ช้ามาก และแก้ไขก็ช้าเช่นกัน บ่อยครั้งต้องเสียค่าใช้จ่ายในการแก้ไขสูงมาก ดังนั้นสิ่งที่ควรต้องมีระบบ Monitoring ใน environment ต่าง ๆ ด้วย อาจจะจะไม่ครบหรือเต็มเหมือนกับ production แต่ขอให้มีแบบขั้นพื้นฐานทาง technical issue เป็นต้นก่อน เพื่อช่วยให้เห็นปัญหาได้รวดเร็วขึ้น

โดยทั้ง 3 สิ่งนี่แหละ คือ สิ่งที่จำเป็นมาก ๆ ต่อ Microservices

นั่นหมายความว่า ทั้งทีม Development และ Operation ต้องทำงานร่วมกัน เพื่อให้เกิดสิ่งต่าง ๆ เหล่านี้ขึ้นมา มันคือ DevOps culture ชัด ๆ ขอให้สนุกกับการ coding ครับ Reference Websites https://martinfowler.com/bliki/MicroservicePrerequisites.html https://martinfowler.com/articles/break-monolith-into-microservices.html
↧
Search

จดบันทึกสิ่งที่น่าสนใจจาก WWDC 2018 นิดหน่อย

June 4, 2018, 8:20 pm
$
0
0

จาก Keynote ของงาน WWDC 2018 ของ Apple มีหลายสิ่งอย่างถูกประกาศและปล่อยออกมา ทั้งความสามารถใหม่ ๆ และสิ่งที่ปรับปรุงของ
  • iOS 12 เร็วแรงขึ้น
  • watchOS 5
  • Apple TV 4K แล้ว
  • macOS Mojave ที่ปรับปรุงการใช้งานเยอะมาก ๆ
มาดูกันหน่อย App ทุก ๆ ตัวสามารถเรียกใช้งาน Siri ได้เลย ซึ่งทำงานได้ทั้งบน iPhone, iPad และ Apple Watch โดย feature ใหม่นี้เรียกว่า Siri Shortcuts อีกอย่างคือ iOS app บน MacOS เป็นข่าวคราวมานานนั้น ไม่มีจริงนะ แต่อาจจะมีเครื่องมือบางอย่างช่วย port มาได้ง่ายขึ้น ซึ่งเป็นสิ่งที่ดี และ ช่วยนักพัฒนาให้สะดวกสบายขึ้นได้ โดยทาง Apple น่าจะเริ่มลองจาก Apple News และ Stocks เป็นต้น ซึ่งน่าจะเริ่มใช้งานกันได้ในปี 2019 พวก Animoji และ Memoji (สร้าง Animoji ของตัวเราเอง) นี่คือ feature ใช่ไหมเนี่ย !! สามารถเลือกสีผิว สีผม แว่นตา และ อื่นได้เพียบ Facetime group คุยได้มากกว่า 1 คนตั้งแต่ 2 ไปจนถึง 32 คน watchOs สนับสนุน walked talkie แล้ว !! MacOs สนับสนุน Dark mode แล้ว ดังนั้นชาว Xcode developer ได้ใช้แบบไม่ต้องทำอะไรแล้วนะ และมีความสามารถอื่น ๆ เพียบนะ เช่น Dynamic desptop ตามเวลาเลย อีกอันที่ชอบคือ จัดการไฟล์ และ folder ใน Descktop นั่นเอง จัดง่ายขึ้นเยอะ ปรับปรุงเรื่องการค้นหา เน้นไปที่รูปภาพมาก ๆ iBooks เปลี่ยนชื่อเป็น Apple Books ARKit 2 ปรับปรุงเรื่องของ face tracking และ 3D object detection รวมไปถึงเรื่องของการ rendering Xcode 10 นั้น integrate กับ Gitlab ได้เลย
ไปลองของใหม่ที่ Developer Beta program ได้ แต่ตอนนี้ยังไม่เปิดนะ (Coming soon)
↧

สรุปการแบ่งปันเรื่อง การเริ่มต้นพัฒนาระบบงานด้วยภาษา Go

June 5, 2018, 9:52 pm
$
0
0

พอดีได้มีโอกาสไปแบ่งปันความรู้เรื่อง การเริ่มต้นพัฒนาระบบงานด้วยภาษา Go ให้กับน้อง ๆ ที่เข้ามาฝึกฝนในค่าย The SCK SEAL Team นิดหน่อย ซึ่งใช้เวลาในการแนะนำและแบ่งปันไปประมาณ 1-2 ชั่วโมง ประกอบไปเรื่องพื้นฐานดังนี้

1. ว่าด้วยเรื่องของ go env

เป้าหมายเพื่อให้เข้าใจเกี่ยวกับ environment ต่าง ๆ ของภาษา Go ทั้ง GOROOT, GOPATH, GOOS และ GOARCH เพื่อให้นำไปใช้ได้อย่างถูกต้อง ไม่งง ยกตัวอย่างเช่น
  • GOROOT สำหรับกำหนด path ของ Go compiler ง่าย ๆ คือ บ้านของ Go
  • GOPATH สำหรับกำหนด path ของ project หรือระบบงานของเรานั่นเอง
สิ่งที่น่าสนใจมาก ๆ คือ GOPATH เพราะว่าที่เจอมานั้น ผู้เริ่มต้นใหม่ ๆ จะใช้ GOPATH ที่เป็นค่า default คืออยู่ใน folder <user folder>/go ทำให้ทุก ๆ project ไปอยู่ใน folder นี้หมด ซึ่งไม่ถูกต้อง ดังนั้นสิ่งที่ควรทำคือ ในแต่ละ project ควรมี GOPATH แยกกันไป

2. มาลองทำความเข้าใจกับ GOPATH เพิ่มขึ้น

ด้วยการลองใช้ go get เพื่อ download library ต่าง ๆ มาใช้งาน คำถามคือ go get ทำอะไรบ้าง ? เป็นสิ่งที่คนใช้งานจำเป็นจะต้องรู้ ลองไปตามดูนะครับ ผลที่เกิดขึ้นคือ
  • ทำการ download library ไปยัง GOPATH/src
  • ทำการ compile/install library ไปยัง GOPATH/pkg

3. เมื่อเข้าใจก็มาถึง project structure

ก็ควรมีโครงสร้างง่าย ๆ คือ GOPATH/src นั่นเอง ส่วน folder pkg และ bin ก็เอาไว้เก็บผลลัพธ์ต่าง ๆ คือ
  • ​pkg เอาไว้เก็บผลจากการ install library จาก package ต่าง ๆ
  • bin เอาไว้เก็บ binary จากการ build ระบบงาน
แนะนำให้เริ่มจากที่นี่ How to Write Go Code จากนั้นพูดถึงเรื่องของ โครงสร้าง package ของระบบงาน ควรแยกออกไปตาม feature/domain ของงาน จากนั้นให้แยก package ย่อย ๆ ตามความเหมาะสม เช่น package calendar อาจจะมี package ย่อยตามหน้าที่การทำงาน
  • ​controller
  • service
  • repository
แต่พยายามไม่ให้มีการเรียกข้าม package เพื่อลดความซับซ้อนของระบบงาน

4. ชุดคำสั่งที่ต้องใช้งานกันเลย

สิ่งที่ทีมควรสรุปร่วมกันคือ workflow การทำงานนั่นเอง ว่าจะเป็นอย่างไร ซึ่งทุก ๆ คนควรทำงานเหมือนกัน ทั้งการเขียน code ทั้งการเขียน test ทั้งการ build -> test -> run ยกตัวอย่างเช่น ชุดคำสั่งต่าง ๆ ควรใช้เหมือนกัน หรืออาจจะสรุปออกมาเป็น shell script ไว้เลย โดยชุดคำสั่งที่ควรต้องมี เช่น
  • ​go fmt สำหรับจัด format ของ code
  • go test สำหรับการทดสอบ
  • go tool cover สำหรับการสร้างรายงานของ code coverage
  • go install สำหรับการ compile library/package ต่าง ๆ ซึ่งไปเก็บไว้ใน folder pkg
  • go build สำหรับการสร้าง binary ซึ่งให้กำหนดไปไว้ที่ folder bin
เพียงเท่านี้ก็น่าจะพอเริ่มงานกันได้ เริ่มที่ว่ายากแล้ว ที่เหลือยากกว่าเยอะนะ แต่ก่อนอื่นไปเล่น Go Tour ก่อนนะ แนะนำให้ศึกษาเพิ่มเติมคือ
↧
↧

สรุปเกี่ยวกับการเข้าซื้อ GitHub ของ Microsoft จาก #movingtogitlab

June 8, 2018, 12:51 am
$
0
0

หลังจากทาง Microsoft ประกาศการซื้อ GitHub อย่างเป็นทางการ ถือว่าสั่นสะเทือนวงการ software development มากพอควร ซึ่งมีทั้งข่าวดี ข่าวร้าย ออกมามากมาย ซึ่งส่งผลดีและผลเสีย
หนึ่งในนั้นคือ การย้ายออกจาก GitHub ไปยัง GitLab มี Hashtag ใน Twitter ที่น่าสนใจคือ #movingtogitlab
ลองติดตามดูได้ ว่ามีผลกระทบอะไรเกิดขึ้นบ้าง ซึ่งมีความน่าสนใจมิใช่น้อย มาดูกันว่า มีอะไรที่น่าสนใจบ้าง

ก่อนอื่นมาดูการประกาศของทั้ง Microsoft และ GitHub

ยังไม่พอนะ ยังมี Open Letter ถึง GitHub อีกด้วย ซึ่งเหล่า maintainer ของ repository ที่ได้รับความนิยมร่วมกันเขียนถึง GitHub สิ่งที่น่าสนใจคือ Microsoft นั้นได้เปลี่ยนไปเยอะมาก ทั้งการ opensource project ต่าง ๆ ใน GitHub เช่น ไม่พอนะ Microsoft นั้นเข้ามา contribute open source project มากที่สุดด้วยนะ อีกทั้ง VS Code และ Type Script และ .Net Core ที่ใช้งานกันอยู่ ก็มาจาก Microsoft ยุคใหม่ทั้งนั้นนะ ดังนั้น น่าจะไว้ใจได้ว่า Microsoft น่าจะมาช่วยทำให้ GitHub ดีขึ้นไปอีก แต่ก็ต้องรอดูกันต่อไปว่าจะเป็นอย่างไรต่อไป ...

สิ่งที่น่าสนใจคือ มีการย้าย repository ไปยัง GitLab ขึ้นจำนวนมากขึ้น

ซึ่งทาง GitLab ออกมาประกาศว่าจำนวน repository เพิ่มขึ้นถึง 75% กันเลยทีเดียว ทาง GitLab ก็ได้ออก promotion package สำหรับผู้ที่ย้ายมาลดไป 75% กันอีกด้วย

เมื่อไปดูในสังคม online ก็มีการแสดงออกในทางลบเยอะเช่นกัน

ทั้งการ commit message ใน GitHub repository ทั้งล้อเลียน เช่น หรือภาพที่ใช้บ่อย ๆ มาก ก็มีเช่นกัน ยังไม่พอนะ มีคนทำ project สำหรับ Google Chrome Extension Theme Microsoft ใน Github อีกด้วยนะ คือ GitHub XP หรือ script การย้าย [gist id="54e837824dffee44653fa8d4a8b2603a" file="1.txt"] มีคนไปดูอีกว่า Gitlab นั้นใช้บริการของ Microsoft อีกด้วยคือ Microsoft Azure อีก ยังไม่พอนะ เมื่อย้ายไป Gitlab มาก ๆ ก็รับไม่ไหวเช่นกัน หลาย ๆ คนที่ใช้งานอย่างมีความสุข ก็เริ่มไม่สบายใจแล้ว กับการรับมือของ Gitlab
แล้วคุณละ คิดอย่างไรกับเหตุการณ์ใหญ่ครั้งนี้บ้าง ?
Reference Websites https://medium.com/@ow/microsoft-acquiring-github-is-a-good-thing-heres-why-6a6a57eb83ac https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/
↧

Session เกี่ยวกับการทดสอบจากงาน WWDC 2018

June 9, 2018, 5:52 am
$
0
0

ในงาน WWDC 2018 นั้นมี session ที่น่าสนใจเกี่ยวกับการทดสอบ app ด้วย ซึ่งที่เห็นมามีอยู่ 2 session คือ จึงทำการสรุปแบบสั้น ๆ ไว้นิดหน่อย

เรื่องแรกคือ What’s new in Testing ?

มาดูว่ามีอะไรใหม่ ๆ เกี่ยวกับการทดสอบบ้าง ประกอบไปด้วย
  • ​Code coverage
  • การจัดการชุดการทดสอบ (Test selection)
  • การกำหนดลำดับการทดสอบ (Test ordering)
  • Parallel testing
เรื่องของ Code coverage นั้น มีทั้งเรื่องการปรับปรุง performance และความถูกต้องมากขึ้น โดยขนาดของไฟล์ coverage นั้นจะเล็กลง ดังนั้นการ load และการทำงานจึงรวดเร็วขึ้น เราสามารถแยก code coverage ออกตาม target ที่ต้องการได้ ในส่วนของ Editor ก็แสดงผล code coverage ได้ดียิ่งขึ้น ถ้าเราเปิด feature นะ แสดงดังรูป มี command line ใหม่คือ xccov ช่วยทำให้สามารถง่ายต่อการ integrate เข้ากับระบบอื่น ๆ รวมทั้งสามารถออก report ในรูปแบบต่าง ๆ ได้ เช่น text และ JSON เป็นต้น ยกตัวอย่างเช่น Continuous Integration Server นั่นเอง ไปต้องไปใช้ 3-party tool อีกต่อไปแล้ว ทำไมเพิ่งคิดได้นะ แต่ก็ยังดีที่มา !! ตัวอย่างการใช้งาน มีเรื่องที่น่าสนใจคือ สามารถทดสอบแบบ random ได้ นั่นคือ จะไม่ทดสอบแบบเรียงลำดับเหมือนเดิมแล้ว เพราะว่า บางคนเข้าใจว่า การทดสอบจะทำจากบนลงล่าง หรือ ตามตัวอักษร ซึ่งไม่ดีเลย เพราะว่า มักจะเขียนชุดการทดสอบแต่ละตัวผูกกันไปมา ส่งผลให้การทดสอบไม่เสถียรและช้ามาก ๆ ดังนั้น การที่มีการทดสอบแบบ random เข้ามา ก็น่าจะช่วยให้ชุดการทดสอบมีคุณภาพมากยิ่งขึ้น ปิดท้ายด้วย Parallel Testing ปกติการทดสอบทำได้ทีละ device ที่สำคัญ device ที่กำลังทดสอบนั้น ไม่สามารถใช้งานได้ ส่งผลให้การทดสอบช้ามาก ๆ ดังนั้นใน Xcode 9 จึงเปลี่ยนใหม่ให้ทำการทดสอบแบบขนาน แต่ใช้ได้กับการทดสอบต่าง device เท่านั้นนะ !! อีกทั้งใช้งานผ่าน xcodebuild เท่านั้นนะเออ เมื่อมาถึง Xcode 10 จึงยกเครื่องเป็น Parallel Distributed Testing ใหม่ ซึ่งใช้เทคนิคการ clone simulator หรือ container ทำให้ทดสอบแบบ parallel ได้ง่ายขึ้น

เรื่องที่สองคือ Testing tips and tricks

เนื้อหาใน session นี้จะเป็น technical session สำหรับการทดสอบและ code ที่ทดสอบได้ง่าย (Testable app) รวมไปถึงเทคนิคการทดสอบ เช่นการ mocking และการนำ protocol มาใช้แยกการทำงานส่วนต่าง ๆออกจากกัน เพื่อให้สามารถทดสอบได้ง่าย ซึ่งการแนวทางในการทดสอบจะตามแนวคิดของ Pyramid Testing นั่นเอง ประกอบไปด้วย
  • ​End-to-End testing
  • Integration testing
  • Unit testing
แน่นอนว่า มี code ตัวอย่างให้ดูอีกด้วย ลองไปดูกัน น่าจะมีประโยชน์ ทั้งการทดสอบพวก REST API ทั้งการทดสอบพวก Notification ในช่วงท้าย พูดถึงเทคนิคให้การทดสอบรวดเร็วอีกด้วย ซึ่งการทดสอบที่ช้านั้น มันส่งผลต่อ productivity ของนักพัฒนาอย่างมาก ถ้าช้ามาก ๆ แล้วสุดท้ายก็ไม่มีใครอยากจะทำ ดังนั้นต้องทำให้การทดสอบมีความรวดเร็ว อีกอย่างในการทดสอบต้องไม่มีการ delay รอด้วยนะ ใครทำลงไปแล้วบ้าง ยกมือขึ้น ? สิ่งที่ควรทำมากกว่าคือ Timer และ DispatchQueue.asyncAfter รวมถึงการ mocking เรามักใช้งาน XCTNSPredicateExpectation ซึ่งมันช้า และเหมาะกับการใช้ในส่วนของ UI Testing เท่านั้น ในส่วนของ Unit Testing ไม่ควรใช้นะ แนะนำให้ใช้
  • ​XCTestExpectation
  • XCTNSNotificationExpectation
  • XCTKVOExpectation
ในการทดสอบนั้น ขั้นตอนการ launch app ก็สำคัญ ควรมีขั้นตอนการทำงานที่น้อย ๆ อะไรที่ไม่จำเป็นก็เอาออกไป เพราะว่า การทดสอบจะเริ่มได้เมื่อ app ถูก launch แล้วเท่านั้น หรือบางครั้งต้องกำหนด environment variable สำหรับการ launch argument เพื่อข้ามบางขั้นตอนไป
วันนี้เขียนชุดการทดสอบหรือยัง ? วันนี้ app ของเรานั้นง่ายต่อการทดสอบหรือไม่ ? ขอให้สนุกกับการ coding นะครับ
↧

[JUnit 5] มาลองใช้งาน RepeatTest และ DynamicTest

June 15, 2018, 7:03 am
$
0
0

ระหว่างรอรถก็นั่งอ่านเอกสารของ JUnit 5 มีความสามารถใหม่ ๆ เยอะเลย ที่สำคัญน่าจะได้เวลานำมาใช้อย่างจริงจังได้แล้ว จึงลองเล่นสัก 2 features ประกอบไปด้วย
  • RepeatTest
  • DynamicTest ให้ทำงานในรูปแบบ Parameterized
มาเขียน code กันดีกว่า

ความสามารถแรกคือ Repeat Test

สามารถทำการทดสอบแต่ละ test case ตามจำนวนที่เรากำหนดหรือต้องการได้ ซึ่งน่าจะเหมาะสมกับการทดสอบการทำงานของ method เป้าหมาย ว่ามีการทำงานที่เสถียรหรือไม่ ? บางครั้งอาจจะเอามาลองดูประสิทธิภาพการทำงานก็ได้ ใช้งานผ่าน @RepeatTest โดยกำหนดทดสอบจำนวน 5 รอบ [gist id="e664c1411ed39b7c6d1fd55d224a411c" file="DemoRepeatTest.java"]

ความสามารถที่สองคือ Dynamic Test

โดยปกตินั้นใน JUnit 4 เราสามารถลดจำนวน test case ด้วยการแยก data test และ business flow ออกจากกัน ทำให้ลดจำนวน test case ลงไป ซึ่งเราจะนำ Parameterized มาใช้งาน เหมือนว่าจะง่าย ก็ไม่ง่าย เพราะว่ามีขั้นตอนการใช้งานซับซ้อนน่าดู แต่ใน Unit 5 นั้นมี Dynamic Test ให้ใช้งาน ทำให้ code ของชุดการทดสอบสั้นและง่ายขึ้น ด้วยการใช้งานผ่าน @TestFactory [gist id="e664c1411ed39b7c6d1fd55d224a411c" file="DemoDynamicTest.java"]
จากการใช้งาน JUnit 5 มาสักพักใหญ่ ๆ คิดว่าน่าจะได้เวลาใช้งานจริง ๆ จัง ๆ ได้แล้ว ไหน ๆ ก็เขียน Java 8+ และ Lambda กันแล้ว
ขอให้สนุกกับการเขียน code นะครับ
↧
Viewing all 1997 articles
Browse latest View live
Search