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

สรุปการสอนเรื่อง SOA/Microservice ในเวลา 1 เทอม

May 2, 2017, 9:21 am
$
0
0

มีโอกาสได้ไปสอนและแบ่งปันเรื่องของ SOA/Microservice เป็นเวลา 1 เทอม ที่คณะเทคโนโลยีสารสนเทศ สถาบันเทคโนโลยีพระจอมเกล้าเจ้าคุณทหารลาดกระบัง จึงทำการสรุปสิ่งที่สอนและพาทำไว้นิดหน่อย ซึ่งน่าจะพอเป็นประโยชน์ต่อคนที่สนใจบ้าง

เริ่มต้นด้วย course outline หรือหัวข้อการสอน (ไม่รวมการ present ของแต่ละกลุ่ม)

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

สัปดาห์ที่ 1

Evolution of software architecture ตั้งแต่ monolith จนถึง Microservice ว่ามีที่มาที่ไปอย่างไร ข้อดีและข้อเสียของ Microservice

สัปดาห์ที่ 2

การออกแบบ Microservice พื้นฐาน มีขั้นตอนคร่าว ๆ คือ
  • เข้าใจพฤติกรรมของระบบ
  • การแบ่ง service ออกแบบ service ย่อย ๆ
  • รูปแบบการออกแบบ service ซึ่งเป็นจุดเริ่มต้นของ Microservice

สัปดาห์ที่ 3

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

สัปดาห์ที่ 4

การออกแบบ RESTful API โดยได้นำเอา Service Design Blueprint เข้ามาช่วยในการออกแบบ ซึ่งมีขั้นตอนดังนี้
  1. ออกแบบ flow การทำงานของระบบในมุมมองของผู้ใช้งาน
  2. ทำการออกแบบ RESTful API ในแต่ละขั้นตอนการทำงานจากข้อที่ 1 ซึ่งจะได้ชื่อและ endpoint
  3. ทำการกำหนด HTTP method ของ RESTful API
  4. ทำการกำหนดรูปแบบ request และ response
  5. ทำการออกแบบ database สำหรับการจัดการข้อมูลของแต่ละ RESTful API
  6. ทำแบบนี้ไปในทุก ๆ flow การใช้งาน

สัปดาห์ที่ 6 และ 7

ทำการพัฒนา Microservice ด้วย Spring boot ถ้าเพียงแค่ออกแบบมันไม่สนุกเท่าไร ดังนั้นจึงให้ทำการพัฒนาสิ่งที่ออกแบบมาให้ใช้งานได้บ้าง
ออกแบบได้ก็ต้องเขียนหรือสร้างมันขึ้นมาได้ จะได้เข้าใจว่า สิ่งที่ออกแบบเป็นอย่างไร
คำถามคือทำไมต้องใช้ Spring boot ? คำตอบภาษา Java นักศึกษาส่วนใหญ่เขียนมาแล้ว ส่วน Spring boot นั้นผมเลือกให้เอง ไม่มีเหตุผลอะไรมาก เพราะว่า ถ้าใช้ภาษา Java ก็ต้องตัวนี้ น่าจะเป็นความรู้ใหม่ ๆ ติดตัวนักศึกษาไปไม่มากก็น้อย ส่วนการทดสอบ RESTful API นั้น ทำการแนะนำและพาเขียนด้วย Silk ซึ่งง่ายดี แต่ก็มีบางกลุ่มเขียนการทดสอบด้วย Robotframework ส่วนการทดสอบแบบ manual ก็ให้ใช้ Postman กัน

สัปดาห์ที่ 8

สรุปรูปแบบในการออกแบบ Microservice ว่ามีรูปแบบใดบ้าง ซึ่งในส่วนนี้ผมไม่ได้คิดเอง นำข้อมูลมาจาก web Microservices.io กับหนังสือ Building Microservice

สัปดาห์ที่ 9

สรุปรูปแบบการติดต่อสื่อสารระหว่าง service ซึ่งมีทั้งแบบ Synchronous และ Asynchronous เพื่อให้รู้ว่ามีรูปแบบใดบ้าง ส่วนสิ่งที่เลือกให้ใช้ในการพัฒนาคือ Synchronous (ง่ายที่สุดสำหรับการเริ่มต้น)

สัปดาห์ที่ 10 และ 11

ทำการแนะนำเกี่ยวกับเรื่องของ Containerization ซึ่งเป็นอีกแนวคิดหนึ่งที่ได้รับความนิยมในปัจจุบัน ตั้งแต่การพัฒนาไปจนถึงการ deploy ระบบ ซึ่งเลือกใช้ Docker มาช่วยจัดการ ปัญหาการทำ Lab ก็พอสมควร แต่ก็พอไปวัดไปวาได้ด้วยการใช้งานที่ Digital Ocean โดยจะสอนแบบค่อยเป็นค่อยไป ให้รู้จักการสร้าง container ไว้บ้างเล็กน้อย จากนั้นแนะนำวิธีการ deploy ระบบที่พัฒนาด้วย Docker ซึ่งพาเขียน Dockerfile นิดหน่อย แค่ 3 บรรทัดเท่านั้น โดยที่ project ของแต่ละกลุ่มให้ทำการ deploy ด้วย Docker นี่แหละ มีบางกลุ่มใช้ Kubernates ด้วย ก็ยิ่งดีไปใหญ่เลย

สัปดาห์ที่ 12

สิ่งที่ขาดไม่ได้เลยสำหรับ Microservice หรือระบบใด ๆ ก็ตาม คือระบบ Monitoring หรือ Application monitoring หรือ Service monitoring หรือพูดให้ถูกคือ API monitoring โดยใน Lab สอนเรื่อง monitoring ของ Spring boot ด้วย Actuator ซึ่งทำการจัดเก็บข้อมูลลงใน Pometheus ที่เก่งเรื่องข้อมูลแบบ time-serie จากนั้นนำมาแสดงผลด้วย Grafana ที่เก่งเรื่องการแสดงผลข้อมูลแบบสวยงาม ดูดีมีอะไร โดยเขียนสรุปไว้ใน blog เรื่องระบบ Monitoring สำหรับ Spring boot ปล. ในทุก ๆ หัวข้อจะให้นักศึกษาทำ quiz เสมอ !!! โดยที่รายละเอียดและ slide ต่าง ๆ อยู่ที่ Github::Up1::Course Microservice สิ่งที่ยังไม่ได้สอนประกอบไปด้วย
  • การแบ่งกลุ่มของ service โดยนำแนวคิด DDD (Domain-Driven Design) มาใช้
  • API Gateway
  • การ Scale service

การทำงานเป็นกลุ่ม ซึ่งเป็นส่วนสำคัญมาก ๆ

แน่นอนว่า ต้องมีการทำงานเป็นกลุ่ม ให้แต่ละกลุ่ม ออกแบบระบบงานเอง พัฒนาเอง ทดสอบเอง deploy เอง present เอง โดยจะ present 3 สัปดาห์ครั้ง และมีการ present สรุปครั้งสุดท้ายอีก

Source code และ เอกสารต่าง ๆ เขียนใน Wiki ของ Github

เมื่อทำงานเป็นกลุ่ม จึงให้คะแนนในส่วน
  • จำนวนการ commit ของแต่ละคนในกลุ่ม ต้องใกล้เคียงกัน
  • จำนวนการเขียน wiki ของแต่ละกลุ่ม ต้องใกล้เคียงกัน
  • สอนใช้ Issue
  • สอนใช้ Project
ดังนั้นถ้าในกลุ่มกระจายงานกันไม่ดี คะแนนก็จะต่ำ โดยเขียน code แบบขำ ๆ เพื่อดึงข้อมูลจาก Github มาแสดงนิดหน่อย ดังรูป ส่วน source code ก็ทำการวิเคราะห์ด้วย SonarQube นิดหน่อย เพื่อทำให้นักศึกษาเห็นว่า การวิเคราะห์ code ในเบื้องต้นเป็นอย่างไร

เป้าหมายหลักของ course นี้คือ

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

โดยกลุ่มต่าง ๆ ของนักศึกษาอยู่ที่นี่

 
ปล. มันน่าจะมีประโยชน์บ้างนะครับ
สุดท้ายคะแนนทุกอย่างอยู่ใน Google Docs ซึ่งถ้ามันลงตัวอาจจะกลายเป็นระบบงานต่อไปได้เลย ทำไปทำมาซับซ้อนน่าดู !!
↧
Search

[Android] มาเรียนรู้จากคำถามที่ StackOverflow กันหน่อย

May 3, 2017, 3:07 am
$
0
0

StackOverflow นั้นเป็น website หลักของนักพัฒนา Software ดังนั้นเราลองมาเรียนรู้จากหัวข้อต่าง ๆ กันหน่อย เน้นไปที่เรื่องของ Android ประกอบไปด้วยคำถามในส่วน
  • Frequent
  • Votes
คำถามที่น่าสนใจคือ คุณสามารถตอบปัญหา หรือ แก้ไขปัญหาเหล่านี้ได้หรือไม่ ? มาเริ่มกันเลย

1. คำถามต่าง ๆ ในส่วนของ Frequent

คือมี link ต่าง ๆ ในการตอบมาก ๆ ดังนั้น Android developer ลองมาตอบกันหน่อยสิ
  • How to fix android.os.NetworkOnMainThreadException ?
  • Unfortunately MyApp has stopped. How can I solve this ?
  • Strange out of memory issue while loading an image to a Bitmap object
  • Lazy load of images in ListView
  • How do I pass data between Activities in Android application?
  • Saving Android Activity state using Save Instance State
  • How to parse JSON in Android
  • How to use SharedPreferences in Android to store, fetch and edit values
  • What is the difference between “px”, “dp”, “dip” and “sp” on Android?
  • R cannot be resolved - Android error
ในแต่ละข้อนั้น มันคือพื้นฐานของการพัฒนา Android app ทั้งนั้นเลย ไม่ว่าจะเป็นเรื่อง NetworkOnMainThreadException ไม่ว่าจะเป็นการแก้ไขปัญหาเมื่อ App crash ไม่ว่าจะเป็นการจัดการรูปภาพ bitmap ไม่ว่าจะเป็นการดึงข้อมูลมาแสดงที่ Listview ไม่ว่าจะเป็นการส่งข้อมูลระหว่าง Activity ไม่ว่าจะเป็นการจัดการข้อมูลใน SharedPreferences ไม่ว่าจะเป็นการจัดการกับข้อมูลในรูปแบบ JSON

2. คำถามต่าง ๆ ในส่วนของ Votes

คือมีการ vote สูงมาก ๆ ซึ่งเป็นสิ่งที่โดนใจนักพัฒนาหรือตอบแจ่ม ๆ นั่นเอง ดังนั้นลองมาตอบกันหน่อยสิ
  • What is the difference between “px”, “dp”, “dip” and “sp” on Android?
  • Why is the Android emulator so slow? How can we speed up the Android emulator?
  • Close/hide the Android Soft Keyboard
  • Is there a unique Android device ID?
  • Saving Android Activity state using Save Instance State
  • Get screen dimensions in pixels
  • How do I center text horizontally and vertically in a TextView on Android?
  • What is 'Context' on Android?
  • What is the difference between match_parent and fill_parent?
  • Activity restart on rotation Android
  • Gravity and layout_gravity on Android
เป็นเรื่องพื้นฐานอีกแล้ว ลองมาตอบกันสิ ไม่ว่าจะเป็นความแตกต่างระหว่าง px, dp, dip และ sp ไม่ว่าจะเป็นเรื่องของ Android emulator ที่มันช้า ๆ ทำอย่างไรให้เร็ว ไม่ว่าจะเป็นซ่อน Soft keyboard ไม่ว่าบันทึก state ไม่ว่าจะเป็นการดึงข้อมูลของหน้าจอในแต่ละ device ไม่ว่าจะเป็นเรื่องการจัดการ Life cycle ของ Activity ไม่ว่าจะเป็นเรื่องของ Context ไม่ว่าจะเป็นเรื่องของการจัดการ layout ต่าง ๆ
ดังนั้นสิ่งต่าง ๆ เหล่านี้ Android developer ต้องตอบให้ได้ ทำให้เป็น แต่ถ้ายังไม่รู้ แนะนำให้ลองเข้าไปศึกษาจากคำตอบต่าง ๆ ได้เลย มันจะช่วยให้เราเข้าใจมากยิ่งขึ้น มิใช่เพียง copy-and-paste เท่านั้นนะ
↧
↧

[Robotframework] สิ่งละอันพันละน้อยเกี่ยวกับ Google Chrome

May 4, 2017, 12:11 am
$
0
0

วันนี้มีคำถามเกี่ยวกับการทดสอบ web application ด้วย Robotframework ซึ่งใช้งานร่วมกับ Selenium2Library น่าสนใจดังนี้ โดย browser หลัก ๆ จะใช้งานผ่าน Google Chrome
  1. ไม่ต้องการให้แสดงคำว่า Chrome is being controlled by automated test software
  2. ไม่ต้องการให้แสดง popup ถามว่า Do you want Google Chrome to save your password ?
  3. มี Keyword สำหรับการขยายหน้าจอให้ใหญ่ ๆ แต่ก็ไม่ทำงาน !!
  4. มี warning เกี่ยวกับ GPU !!
ดังนั้นจึงทำการสรุปไว้นิดหน่อย เมื่อเริ่มต้นทดสอบใน Google chrome แสดงคำว่า Chrome is being controlled by automated test software เป็นการบอกว่า ตอนนี้ถูกควบคุมด้วยเครื่องมือการทดสอบแบบอัตโนมัตินะ โดยปกติจะแสดงดังนี้ ถ้ามีการ login เข้าระบบที่เป็น HTTPS ทาง Google Chrome ก็จะถามว่า จะให้ทำการบันทึก username และ password ไว้ไหม แสดงดังรูป โดยปัญหาทั้ง 4 ข้อนี้แก้ไขด้วยการ แก้ไข Chrome Driver นิดหน่อย ด้วยการแก้ไข Chrome option เขียน code ได้ดังนี้ [gist id="bb46ad28b4b3ee9f961651e1a2c22e8e" file="custom.robot"] ปล. เขียนด้วยภาษา Python หรือ Java ง่ายกว่านะ
↧

ว่าด้วยเรื่อง JavaScript Testing มันมีอะไรบ้างนะ ?

May 8, 2017, 6:01 am
$
0
0

การพัฒนาระบบงานด้วยภาษา JavaScript นั้น มีทางเลือกมากมาย ซึ่งยากต่อผู็เริ่มต้นมาก การทดสอบก็เช่นกัน มีมากมายสุด ๆ แต่ถ้ามองในมุมกลับกัน แสดงว่า มีความพยายามในการทดสอบระบบที่พัฒนาด้วยภาษา JavaScript ทั้ง Unit testing, Integration testing และ Functional testing ดังนั้นเรามาดูกันหน่อยว่ามีอะไรกันบ้าง มี library จำนวนมากเพียงใด มาเริ่มกันเลย

1. สำหรับการกำหนดโครงสร้าง และ environment ของการทดสอบ

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

2. สำหรับการตรวจสอบการทำงาน หรือ Assertion

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

3. สำหรับการแสดงผลและดูผลการทดสอบ

ประกอบไปด้วย Jasmine, Mocha, Jest และ Karma

4. สิ่งที่ขาดไม่ได้ในการทดสอบคือ Test double เช่น Mock, Stub และ Spy

เพื่อจำลองระบบหรือ dependency ต่าง ๆ ในระบบ ประกอบไปด้วย

5. ว่าด้วยเรื่องของ Code coverage หรือดูว่า test ที่สร้างขึ้นมาครอบคลุม code จำนวนเท่าไร ?

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

6. สำหรับการทดสอบผ่าน Browser หรือ environemt ที่เหมือน Browser

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

เราจะทำการ refactor code ที่ไ่ม่มีชุดการทดสอบอย่างไรดี ?

May 11, 2017, 2:01 am
$
0
0

Refactoring เป็นวินัยที่นักพัฒนา software ที่ดีพึงกระทำ เพื่อทำการปรับปรุงโครงสร้าง code ให้ดียิ่งขึ้น โดยไม่ทำการเปลี่ยนแปลงพฤติกรรมการทำงาน นั่นคือ ถ้าทำงานถูกอย่างไร ก็ต้องถูกอย่างนั้น ถ้าทำงานผิดอย่างไร ก็ต้องผิดอย่างนั้น (จะทำไปทำไม ?)

ปัญหาของการ refactor code คือ

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

บ่อยครั้งนักพัฒนามักจะได้รับมอบหมายงานให้เข้าไปแก้ไข Legacy Code !!

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

แต่ถ้าต้องการให้สามารถทดสอบซ้ำได้

มันก็ต้องเป็น automation test นั่นเอง แต่การสร้างก็ไม่ง่ายเลย ถ้า code ของระบบมันผูกมัดกันอย่างรุนแรงแล้ว ก็ต้องแยก หรือ isolate การทำงานส่วนต่าง ๆ ออกจากกันให้ได้ นั่นคือ code ของเรามันทดสอบได้ไหม (Testable code) ถ้าไม่ นั่นมันคือความท้าทายอีกแล้ว (เยอะแยะไปหมด !!) ดังนั้น ถ้าคุณเพียงเพิ่มความสามารถเข้าไปใน code ที่ไม่มี test มันอาจจะไม่ส่งผลกระทบมากเท่าไร แต่ถ้าคุณต้องทำการ refactor code ที่ไม่มี test แล้ว มันคงไม่มีอะไรที่ดีไปกว่า การเขียน test อีกแล้วนะครับ

สุดท้ายแล้วมันก็มีทางเลือกให้คุณว่าจะทำอย่างไร ?

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

ทำความรู้จักกับ Stack Overflow Trends Tool กัน

May 13, 2017, 8:24 am
$
0
0

ทาง StackOverflow ได้ปล่อยเครื่องมือชื่อว่า Stack Overflow Trends Tools ออกมา สำหรับการดูสถิติและแนวโน้มต่าง ๆ ของภาษาโปรแกรมและเทคโนโลยี ใช้ข้อมูลจากการถามตอบในระบบของ Stack Overflow นั่นเอง โดยที่ระบบนี้ถูกสร้างมาจาก คำถามเดิม ๆ ที่ถามในทุก ๆ ปี ทั้งภาษาโปรแกรมและเครื่องมืออะไรบ้างที่ได้รับความนิยม ? แต่ละภาษาโปรแกรมและเครื่องมือนี้มีความนิยมอย่างไรบ้าง ?

ในระบบนี้เราสามารถเปรียบเทียบข้อมูลต่าง ๆ ได้เลย

ตัวอย่างเช่น JavaScript Framework
  • jQuery
  • angular
  • reactjs
  • vuejs
แสดงผลดังนี้

Mobile Operating System

ภาษาโปรแกรมสำหรับการพัฒนา Mobile app ทั้ง iOS และ Android

เรื่องของ Data Science และ Big Data

ซึ่งบรรดาภาษาโปรแกรมและเทคโนโลยีได้รับความนิยมสูงขึ้นอย่างต่อเนื่อง ทั้งภาษา R, Mathlab, Pandas และ Tensorflow เป็นต้น แสดงดังรูป ส่วนการประมวลผลข้อมูลและจัดเก็บข้อมูลขนาดใหญ่ ก็ได้รับความนิยมทั้ง Apache Spark และ Hadoop แสดงดังรูป ดังนั้นระบบนี้เป็นเครื่องมือที่ดี สำหรับการดูแนวโน้มต่าง ๆ ของภาษาโปรแกรมและเทคโนโลยี ถ้าพลาดแล้วจะเสียใจนะครับ Reference Website https://stackoverflow.blog/2017/05/09/introducing-stack-overflow-trends
↧

[iOS] เราจะทำการจำลอง API server สำหรับ UI testing อย่างไร

May 15, 2017, 5:57 am
$
0
0

คำถามที่น่าสนใจจากทีมเกี่ยวกับจำลอง API server เพื่อทดสอบ UI test สำหรับ iOS app จะทำอย่างไรดี ? คำตอบง่าย ๆ คือ ง่าย ๆ ให้ทำการส่ง url ของ API server ผ่าน environment variable สิเออ !!! พูดแบบนี้อาจจะไม่เห็นภาพ ดังนั้นมาดู code กันหน่อย

ใน UI Test ทำการกำหนดค่าของ url ไว้และใช้งานดังนี้

[gist id="1fe96a5bf11ea512575f5bd96ed3e43e" file="1.swift"] เป็นวิธีการที่ง่ายมาก ๆ เพราะว่าใน UI Test นั้นใช้งาน Mock สิ่งต่าง ๆ ก็ใช้ไม่ได้ จึงต้องส่งค่าบางอย่างเข้าไป จากนั้นต้องเขียน code เพิ่มเพื่อให้เราสามารถควบคุม dependency ต่าง ๆ ได้ เช่นอาจจะส่งค่าบางอย่างเข้าไป จากนั้นใน production ก็ทำการตรวจสอบ เพื่อทำการ Mock class บางตัวให้ทำงานตรงตามที่ต้องการ หรือไม่เช่นนั้นก็ทำการจำลอง API server ขึ้นมาแทนด้วย Stubby4j เป็นต้น ซึ่งวิธีการนี้ก็พอไปวัดไปวาได้

คำถามคือมีวิธีการอื่นอีกไหม ?

ตอบเลยว่ามีนะ คือ การเพิ่ม configuration สำหรับ UI test ใน xCode project เลย ซึ่งสามารถทำการสร้าง configuration ใหม่ขึ้นมา จากตัวอย่างชื่อว่า Localhost แสดงดังรูป   จากนั้นทำการกำหนดค่า LOCALHOST เพื่อส่งไปยัง production code   จากนั้นในส่วนของการทดสอบให้เลือกใช้ configuration Localhost ซะ จากนั้นใน production code ให้เขียน code ประมาณนี้ ตรวจสอบว่า run จาก configuration อะไร จากนั้นก็ทำการกำหนด URL ที่เราต้องการได้ทันที [gist id="1fe96a5bf11ea512575f5bd96ed3e43e" file="2.swift"] ทำไมมันช่างซับซ้อนอย่างนี้นะ !!

ข้อเสียที่เห็นได้ชัดเจนจากวิธีการทั้งสองนี้คือ

ต้องเขียน code เพิ่มเติมเพื่อจัดการตามค่าของ environment variable นั่นเอง ซึ่งเป็น code ที่ไม่ควรอยู่ในส่วนของ production code เลย !!

อีกส่วนคือ API server ที่จำลองขึ้นมาด้วย Stubby4j

มันต้อง start อยู่เสมอด้วยนะ คำถามคือจะแก้ไขอย่างไรดีละ ? ตอบง่าย ๆ คือ เพิ่ม Pre-action และ Post-action ในส่วนของ Test นะครับ เพื่อทำการ start server ก่อนการทดสอบ เพื่อทำการ stop server หลังจากที่ทดสอบเสร็จสิ้น แต่ต้องเขียน shell script นิดหน่อย แสดงดารใช้งานดังรูป

คำถามต่อมาคือ มีอะไรที่คล้าย ๆ กับ MockWebServer หรือไม่ ?

คำตอบก็มีนะเช่น ขอให้สนุกกับการเขียน code ครับ
↧

ทำไมถึงใช้ภาษา Go ?

May 16, 2017, 10:49 pm
$
0
0

จาก post นี้ใน facebook เรื่องเกี่ยวกับการนำภาษา Go มาใช้ในการพัฒนาระบบงาน สิ่งที่สำคัญคือ มีเหตุผลอะไรที่ถึงนำภาษา Go มาใช้งาน ในส่วนของ API service และ Backend ดังนั้นมาสรุปเหตุผลไว้นิดหน่อย จากมุมมองที่ใช้มาบ้างเล็กน้อย อาจจะไม่ถูกแต่คิดว่า มันดีกว่าเดิมอย่างแน่นอน มาเริ่มกันเลย [fb_embed_post href="https://www.facebook.com/somkiatspns/posts/10155340587733588" width="550"/]

1. เป็นภาษาที่เรียบง่าย ไม่ต้องการอะไรเยอะ

ตั้งแต่ความต้องการ และ รูปแบบของภาษา รวมทั้งตัวภาษาเองมีชุดของ library ที่พร้อม ไม่จำเป็นต้องใช้ library จากข้างนอกเลย ตัวอย่างเช่นการพัฒนา API service ตัวภาษาก็มี library เกี่ยวกับ http, json, template ให้ทั้งหมด ที่สำคัญเอกสารครบที่ Go Document

2. สิ่งที่ชอบมาก ๆ คือ ผลจากการ compile และ build ได้ไฟล์ binary เดียวเท่านั้น

โดยไฟล์ binary ที่ได้จะถูกสร้างตามสถาปัตยกรรมและ OS ที่ใช้งาน รวมทั้ง app และ library ต่าง ๆ เข้าด้วยกัน ทำให้ง่ายต่อการติดตั้งอย่างมาก ทำให้เราได้รับ feedback กลับมาอย่างรวดเร็วอีกด้วย บ่อยครั้งอาจจะคิดว่า มันง่ายเกินไปหรือไม่ ? ทำอะไรผิดหรือเปล่า ?

3. ส่วนตัวชอบเรื่อง Static Type System

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

4. มีชุดเครื่องมือที่จำเป็นต่อนักพัฒนา

ตัวอย่างเช่น
  • go clean สำหรับลบไฟล์ที่ compiler สร้างขึ้นมา
  • go fmt สำหรับจัดการรูปแบบของ code
  • go get สำหรับจัดการเรื่อง library/dependency
  • go test สำหรับการทดสอบ
  • go doc สำหรับการสร้างเอกสาร
ลองดูเพิ่มเติมด้วยคำสั่ง $go tool

5. เรื่องประสิทธิภาพการทำงานที่ดีขึ้นมาก ๆ

แต่สิ่งที่สำคัญกว่าคือ การใช้ resource ต่าง ๆ น้อยลง ทั้ง CPU และ Memory เมื่อเทียบกับระบบเดิมที่พัฒนาด้วยภาษาอื่น ๆ เช่น Java และ Python น่าจะมาจากเรื่องของ concurrency model และ CPU scalability ที่ตัว compiler จัดให้ ตรงนี้มาจากระบบที่ทำเท่านั้น อาจจะแตกต่างกันไปในแต่ละระบบ

6. มี IDE และ Text Editor สนับสนุนมากมาย

เอาที่สบายใจเลยตั้งแต่ vi ยัง IDE ที่ดูดีอย่าง JetBrans IDEA, Webstorm เป็นต้น

สุดท้ายคือ เขียนชุดการทดสอบได้ง่าย

ถ้าไปดู code ของภาษา Go จะพบว่า ในทุก ๆ ไฟล์มีชุดการทดสอบทั้งหมด ซึ่งเป็นแหล่งการเรียนรู้ที่ดีมาก ๆ ปล. ถ้าง่ายง่ายเลย แต่ถ้ายากยากเลย !! ถามว่าในอนาคตจะมีอะไรที่ดีกว่าไหม ? ตอบได้เลยว่ามีสิ ประเด็นคือ เราทำการศึกษาสิ่งใหม่ ๆ หรือไม่ ? จากนั้นก็ต้องพิจารณาดูความพร้อมในมุมต่าง ๆ อีกด้วย เช่น การดูแลรักษาและพัฒนาต่อไป ? ดังนั้นเลือกเครื่องมือให้ถูกกับงาน และ คนด้วยครับ
ภาษาดี แต่คนสร้างแย่ มันก็ไม่ดีนะ
ขอให้สนุกกับการเขียน code ครับ
คำถามปิดท้าย ทำไมถึงไม่ใช้ภาษา Go ?
↧
Search

สิ่งที่นักพัฒนาส่วนใหญ่ลืมก่อนการ commit code

May 17, 2017, 2:51 am
$
0
0

เมื่อวานมีโอกาสแบ่งปันความรู้เรื่องการใช้งาน Version Control ด้วย Git ไป การ commit หรือบันทึกการเปลี่ยนแปลง การ push หรือการส่งการเปลี่ยนแปลงไปยัง remote repository การ pull หรือการดึงการเปลี่ยนแปลงจาก remote repository มายังเครื่องเรา ทั้งหมดนี้คือ การพูดคุยและการทำงานร่วมกันของทีมพัฒนา
ยิ่งทำการ commit/push/pull บ่อย ๆ มากเพียงใด ปัญหาที่เกิดก็จะน้อยลงไป !!
ลองคิดสิว่าระหว่าง commit บ่อย ๆ กับนาน ๆ ครั้ง แบบไหนจะดีกว่ากัน ?

ก่อนที่จะทำการ commit code ต้องทำอะไรบ้าง ?

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

1. Code ที่ทำการแก้ไข compile ผ่านหรือไม่ ?

บ่อยครั้งพบว่า เมื่อแก้ไข code แล้ว code เหล่านั้นไม่สามารถ compile ได้ เป็นสิ่งที่นักพัฒนาห้ามพลาด

2. สิ่งที่เปลี่ยนแปลงทำงานถูกต้องและไม่ส่งผลกระทบต่อส่วนอื่น ๆ หรือไม่ ?

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

3. ถ้าใน code มีการเขียน comment ต้องทำการแก้ไข ตาม code ที่เปลี่ยนไปด้วย

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

4. ทำการปรับปรุง code ด้วยหรือยัง ?

ทั้งรูปแบบของ code ให้ตรงตามที่ตกลงกันไว้ เช่น coding standard ทั้งการแก้ไขโครงสร้าง code ทั้งลบ code ที่ซ้ำซ้อน ทั้งลบ code ที่ไม่ถูกใช้งาน มันช่วยทำให้ชีวิตเราดีขึ้น แต่ส่วนใหญ่มักไม่ทำ !!

5. ทำการเพิ่มหรือลบไฟล์จาก repository ให้ครบด้วยนะ !!

ในแต่ละ commit หรือการเปลี่ยนแปลง ควรทำการเพิ่มหรือลบไฟล์ที่ต้องการให้ครบด้วย มิเช่นนั้นจะเกิดปัญหาหนักตามมา เช่นเอา code ขึ้นไม่ครบ !!

เพียงเท่านี้ก็จะทำให้เรามั่นใจได้ว่า

ในแต่ละ commit หรือการเปลี่ยนแปลงนั้น มันทำงานได้อย่างถูกต้อง สมบูรณ์ตามที่เราคาดหวัง เพื่อลดปัญหาที่จะเกิดตามมา พยายามทำให้เป็นแบบอัตโนมัติมากที่เท่าที่จะทำได้ เพื่อลดเวลาที่ต้องเสียไป เอาเวลาไปทำอย่างอื่นดีกว่านะครับ
คำถาม ปัจจุบันก่อน commit code เราทำอะไรกันบ้าง ?
↧
↧

เมื่อภาษา Kotlin เข้ามาเป็นอีกหนึ่งภาษาหลักในการพัฒนา Android app

May 19, 2017, 5:03 am
$
0
0

ก่อนหน้านี้สำหรับ Android developer หรือ JVM developer น่าจะคุ้นเคยกับภาษา Kotlin กันมาพอสมควร ทั้งใช้งานบน production แล้ว ทั้งลองใช้งานเล่น ๆ นักพัฒนา Android app น่าจะสนุกและมีทางเลือกมากขึ้น เมื่อทีมพัฒนา Android ของ Google นั้น สนับสนุนภาษา Kotlin อย่างเป็นทางการแล้ว ซึ่งประกาศในงาน Google I/O 2017
Kotlin is becoming a 100% first class language for Android development.
ดังนั้นนักพัฒนาทั้งหลายก็ต้องเริ่มศึกษาภาษา Kotlin กันอย่างจริงจังได้แล้วนะ

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

สำหรับ Android developer ก็เริ่มด้วยการ download Android Studio 3.0 Canary 1 มาใช้ซะ ส่วนเอกสารเริ่มต้นทางทีมพัฒนา Android ก็เตรียมไว้ให้ที่ Hello Kotlin ซึ่งหลัก ๆ แนะนำการใช้งาน Android Studio 3.0 Cannary 1 นั่นเอง ทั้งการสร้าง project และการ convert จาก Java เป็น Kotlin อย่างไร รวมทั้ง FAQ และสรุป resource สำหรับศึกษาภาษา Kotlin ให้มาเพียบ

โดยความสามารถพื้นฐานจะเหมือน ๆ กับการใช้งาน Kotlin plugin ก่อนหน้านี้

แต่อำนวยความสะดวกมากกว่า ตั้งแต่การสร้าง project ที่ให้เลือกภาษาได้ ว่าจะใช้ภาษา Kotlin หรือไม่ จากนั้นจะสร้าง project ให้แบบง่าย ๆ กันไปเลย ไม่ต้องมานั่ง convert อะไรให้เสียเวลา (แน่นอนว่าสามารถ convert code ได้นะ) แสดงดังรูป และเมื่อต้องการเพิ่มไฟล์หรือ Activity ใด ๆ เข้ามาใน project ก็สามารถเลือกภาษาได้อีกเช่นกัน แสดงดังรูป

ส่วนความสามารถของภาษา Kotlin คงไม่ต้องอธิบายอะไรมาก

เพราะว่า ทำให้ JVM developer พัฒนาระบบได้สนุกมากยิ่งขึ้น เช่น
  • Nullable
  • Named parameter
  • When statement
  • Data class
  • Smart cast
  • Extension function
  • Lambda

ปล. ทางทีมพัฒนา Kotlin ได้ออกมาตอบข้อสงสัยต่าง ๆ เกี่ยวเรื่องนี้ไว้ดังนี้

Kotlin on Android. Now official เช่น Kotlin จะมีเป้าหมายหลักคือ Android อย่างเดียวหรือไม่ ? แน่นอนว่าไม่ใช่ เนื่องจาก Kotlin สร้างมาเพื่อ one language, run in multiple platform
  • Kotlin/JVM
  • Kotlin/JS
  • Kotlin/Native
จะกระทบต่อ release cycle ของ Kotlin หรือไม่ ? แน่นอนว่าไม่เกี่ยวข้องกันและแยกกันเป็นอิสระ แต่การทำงานของทั้งสองทีมจะใกล้ชิดกันอย่างมา เพื่อทำให้การ release แต่ละครั้งไม่เกิดปัญหา ที่สำคัญยังคงพัฒนา Android Studio Plugin ต่อไป สุดท้ายแล้ว Google จะเข้ามาซื้อ JetBrains หรือไม่ ? ตอบสั้น ๆ ว่า ไม่
Let’s start with Try Kotlin !!!
ขอให้สนุกกับการ coding ครับ https://www.youtube.com/watch?v=czKo-jPVweg
↧

ว่าด้วยเรื่อง Android App Architecture จาก Google

May 20, 2017, 5:38 am
$
0
0

จากงาน Google I/O 2017 นั้นมีของใหม่ ๆ ออกมาเยอะมาก ไม่รู้จะเยอะไปไหน !! มีหลายสิ่งอย่างน่าสนใจ ยกตัวอย่างเช่น Guide to App Architecture หรือโครงสร้างต่าง ๆ สำหรับการพัฒนา Android app ซึ่งทางทีมพัฒนาได้สรุปและเตรียม component ต่าง ๆ ไว้ให้อย่างครบครัน โดยแยกส่วนการทำงานต่าง ๆ ออกเป็น component อย่างชัดเจน ประกอบไปด้วย
  • Component สำหรับการจัดการ Lifecycle ของ Activity/Fragment ให้ง่ายขึ้น
  • LiveData คือ observer สำหรับ data holder เพื่อคอยดูการเปลี่ยนแปลงของข้อมูล โดยทำงานร่วมกับ lifecycle ของ Activity/Fragment/Service อีกทั้งยังช่วยจัดการไม่เกิด memory leak อีกด้วย มีการทำงานเช่นเดียวกับ RxJava และ Agera
  • ViewModel เตรียมข้อมูลสำหรับ UI component ต่าง ๆ ซึ่งข้อมูลต่าง ๆ มาจาก LiveData นั่นเอง
  • Room Persistence Library คือ Object mapping สำหรับ SQLite นั่นเอง ที่สำคัญยังคอยดูการเปลี่ยนแปลงข้อมูลอีกด้วย นั่นคือทำงานร่วมกับ LiveData นั่นเอง
  • Repository คือคนกลางสำหรับจัดการข้อมูลจากที่ต่าง ๆ ไม่ว่าจะมาจาก Local หรือ Remote ก็ตาม
  • Networking แนะนำให้ใช้ Retrofit
  • การจัดการ component ที่ต้องทำงานร่วมกันแนะนำให้ใช้ Dagger 2
แสดงโครงสร้างของระบบดังนี้

ซึ่งโครงสร้างนี้มีเป้าหมายเพื่อ ช่วยแก้ไขปัญหาต่าง ๆ ดังนี้

การจัดการ Life Cycle ของ Activity/Fragment/Service ซึ่งมันซับซ้อนและยากต่อการจัดการ ส่งผลให้นักพัฒนาลำบากมาก ๆ และ จัดการหรือเอาไม่อยู่ !! ส่งผลให้ App พังหรือหยุดทำงานได้ง่ายมาก ๆ บ่อยครั้งพบว่า การจัดการต่าง ๆ เขียนอยู่ใน Activity/Fragment ทั้งหมด บ่อยครั้งพบว่า เขียน code จัดการแบบผิด ๆ บ่อยครั้งพบว่า มีการใช้ resource แล้วไม่ยอมคืน บ่อยครั้งพบว่า เกิด memory leak ขึ้น ดังนั้นตามแนวคิดของ Separation of Concern (SoC) นั่นคือแยกส่วนการทำงานออกเป็นส่วน ๆ หรือ component ตาม component ด้านบน โดยแนวทางนี้เป็นเพียงแนวทางหนึ่งในการแก้ไขปัญหาเท่านั้น ซึ่งช่วยทำให้ app มีความน่าเชื่อถือ ทดสอบและดูแลรักษาได้ง่าย แน่นอนว่า มันน่าลองทำตามเป็นอย่างยิ่ง ดังนั้นมาเริ่มกันดีกว่า !!

ปิดท้ายมาดูการทดสอบกันหน่อย

เนื่องจากแยกส่วนการทำงานออกจากกันชัดเจน ดังนั้นทำให้แต่ละส่วนทดสอบได้ง่าย มาดูกันว่าทดสอบกันอย่างไร ? 1.ในส่วนของ User Interface ใช้งาน Espresso ส่วนการทำงานต่าง ๆที่ User Interface ต้องการใช้งาน เช่น ViewModel ก็ให้ mock ไว้ซะ 2. ViewModel สามารถทดสอบด้วย JUnit ได้เลย ส่วนอื่น ๆ ที่ทำงานด้วย เช่น Repository ก็ให้ mock ไว้ซะ 3. Repository สามารถทดสอบด้วย JUnit เช่นกัน 4. DAO (Data Access Object) สำหรับการจัดการข้อมูลผ่าน Room แนะนำให้ใช้งานผ่าน Instrumentation test นั่นเอง เนื่องจากมีการใช้งาน library ของ Android นั่นเอง จากนั้นให้ทำการทดสอบด้วย in-memory database ซึ่งจะส่งผลกระทบต่อการทำงานน้อยมาก ๆ และอย่าทดสอบผ่าน SQLite ตรง ๆ เนื่องจากในแต่ละ device อาจจะใช้ SQLite version ต่างกัน !! 5. WebService/REST API ให้ทำการทดสอบผ่าน WebMockServer ซึ่งช่วยทำงานสร้าง face webserver ขึ้นมาแบบง่าย ๆ นั่นเอง 6. Testing Artifact โดยที่ Architecture component ได้เตรียม library สำหรับการควบคุมการทำงานใน background thread มาให้ ประกอบไปด้วย InstantTaskExecutorRule และ CountingTaskExecutorRule
ซึ่งน่าจะทำให้การพัฒนา Android app ง่ายและเป็นมาตรฐานยิ่งขึ้น ดังนั้นจะช้าอยู่ทำไม มาเขียน code กันเถอะ
↧

สรุป Tips 10 ข้อจาก VDO เรื่อง Speeding Up Your Android Gradle Builds

May 21, 2017, 7:13 pm
$
0
0

ในงาน Google I/O 2017 นั้นมี session เรื่อง Speeding Up Your Android Gradle Builds โดยแนะนำเทคนิคต่าง ๆ ในการปรับแต่งการทำงานของ Gradle เพื่อเพิ่มความเร็วในการ build สำหรับ Android app เป้าหมายเพื่อเพิ่ม productivity ของนักพัฒนา app นั่นเอง มาดูกันเลย
Slow builds are not normal !!
ปล. การวัดประสิทธิภาพจะใช้ 3 ค่า คือ
  • Full build
  • Incremental build เมื่อ code java เปลี่ยนแปลง
  • Incremental build เมื่อ resource เปลี่ยนแปลง
โดยแต่ละข้อเป็นเรื่องพื้นฐานที่ต้องเข้าใจและนำไปใช้งานต่อไป ผลจากการแก้ไขนั้นอาจจะเหมือนหรือแตกต่างกันก็เป็นไปได้ เนื่องจากขึ้นอยู่กับปัจจัยหลาย ๆ อย่าง !! มาเริ่มกันเลย

1. ใช้งาน Android gradle plugin ล่าสุดจาก maven repository ของ Google

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

2. หลีกเลี่ยง Legacy multidex

คำถามแรกเลยก็คือ Legacy multidex คืออะไร ? คำตอบง่ายคือ Multidex + minSdkVersion < 21 นั่นเอง มันส่งผลให้การ build ช้ามาก ๆ !! ซึ่งใน Android Studio ตั้งแต่ 2.3 ขึ้นไปจะหลีกเลี่ยงการ build ลักษณะนี้เป็นอย่างมาก ดังนั้นใน project ไหนที่เป็น Legacy multidex แล้ว แนะนำให้สร้าง productFlavors ใหม่ เพื่อกำหนด minSdkVersion เป็น 21 ซะ ดังนี้ [gist id="b8cb2a95eb15ac8e4eaa715f301824de" file="2.txt"]

3. ปิด multi-APK ซะ

ซึ่งความสามารถนี้ไม่จำเป็นสำหรับขั้นตอนการพัฒนาเลย ดังนั้นให้ทำการปิดไปซะ ใน block splits{} ดังนี้ [gist id="b8cb2a95eb15ac8e4eaa715f301824de" file="3.txt"]

4. ให้ใช้งาน resource ที่มีขนาดเล็กที่สุดในการพัฒนา

แน่นอนว่าทำการ config เช่นเดียวกับ minSdkVersion นั่นเอง

5. ปิด PNG crunching ซะ !!

ซึ่ง Android studio เปิดความสามารถนี้อยู่แล้ว !! จะมีผลอย่างมากสำหรับ Full build แต่ส่วนอื่น ๆ ไม่แตกต่างกันเลย [gist id="b8cb2a95eb15ac8e4eaa715f301824de" file="5.txt"]

6. ใช้งาน Instant Run ซะ

รู้หรือยังว่าใน Android Studio แยกออกเป็นสองปุ่มนะ ระหว่าง Regular Run กับ Instant Run

7. หลีกเลี่ยงการเปลี่ยนแปลง resource ที่ไม่จำเป็น

เช่น versionCode ของ app เป็นต้น ซึ่งส่งผลต่อเวลาการ build อย่างมาก

8. สำหรับการใช้งาน dependency ต่าง ๆ อย่าใช้ Dynamic version เด็ดขาด

ตัวอย่างเช่น เป็นการบอก gradle ให้ตรวจสอบ version ล่าสุดของ dependency ซึ่งทำให้เวลาการ build สูงขึ้นมาก [gist id="b8cb2a95eb15ac8e4eaa715f301824de" file="8.txt"] ดังนั้นระบุ version ที่ต้องการไปเลยนะ

9. ระมัดระวังเรื่องของ Memory ที่จอง

แน่นอนว่าแต่ละ project ต้องการ memory ที่แตกต่างกันในการ build แต่ต้องระมัดระวังเป็นอย่างมาก

10. เปิด Gradle caching ด้วยเสมอ

มีมาใน Gradle 3.5 เป็นต้นมาก สามารถเปิดการใช้งานดังนี้ [gist id="b8cb2a95eb15ac8e4eaa715f301824de" file="10.txt"]

ผลจากการปรับปรุงตาม 10 ข้อได้ผลดังนี้

  • Full build เร็วขึ้น 3 เท่า
  • Incremental change สำหรับ Java เร็วขึ้น 12 เท่า
  • Incremental change สำหรับ Resource เร็วขึ้น 3 เท่า
สามารถดูการปรังแต่งเพิ่มเติมได้จาก Github :: Santa tracker android

สำหรับ VDO นี้ยังไม่หมดนะ !!

ยังมีเรื่องของ Multi-module project กับ Android gradle plugin 3.0 มีอะไรเปลี่ยนแปลงบ้าง ? เพื่อทำให้การ build เร็วขึ้น แน่นอนว่า ถ้า module ไหนมีการเปลี่ยนแปลงแล้ว จะต้องทำการ compile ใหม่เสมอ ทั้ง ๆ ที่การเปลี่ยนแปลงเหล่านั้นไม่ส่งผลกระทบต่อผู้ใช้งานเลย !!
โดยในการอ้างถึง module จะใช้ compile เสมอ ซึ่งใน VDO บอกว่าผิดอย่างแรงส์
ใน Android gradle plugin 3.0 แนะนำให้ใช้ api หรือ implementation แทน ส่วน compile นั้นถูก deprecated แล้ววว !! เพื่อหลีกเลี่ยงการ compile ที่ไม่จำเป็น นั่นคือช่วยให้การ build เร็วขึ้นเป็นกอง ดังนี้ [gist id="b8cb2a95eb15ac8e4eaa715f301824de" file="more.txt"]

คำถามที่ตามมาคือ แล้ว api ต่างกับ implementation อย่างไร ?

api จะเหมือนกับ compile นั่นเอง จะทำการ import public API จาก module นั้น ๆ มาเป็นของตัวเอง ส่วน implementation นั้นเพื่อไม่ให้ consumer เห็น public API จาก module นั้น ๆ ดังนั้นถ้า module นี้เปลี่ยนแปลง ก็จะไม่ทำการ compile นั่นเอง
ผลที่ตามมาคือ แนวคิดแบบ Modular จะมีประโยชน์ขึ้นอย่างมาก เพราะว่า gradle จะทำการ build แบบ parallel ลองใช้งานกันดูนะครับ

แล้วมีอะไรต่อไปอีก

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

ถ้าต้องการตัวช่วยสำหรับดูว่าขั้นตอนการ build ช้าอย่างไร ?

Gradle ก็มีตัวช่วยดังนี้ ขอให้สนุกกับการ coding ครับ
↧

นั่งแกะ code จาก vdo เรื่อง Introduction to Kotlin จากงาน Google I/O 2017

May 24, 2017, 5:52 am
$
0
0

จาก VDO เรื่อง Introduction to Kotlin ของงาน Google I/O 2017 เป็น session ที่แนะนำให้รู้จักภาษา Kotlin เป็น session ที่เขียน code กันสด ๆ ให้ดูกัน ว่าภาษา Kotlin มีความสามารถอะไรบ้าง ว่าภาษา Kotlin ช่วยลดจำนวน code ที่ต้องเขียนลงเยอะไหม ปิดท้ายด้วย Coroutine นิดหน่อย ดังนั้นจึงทำการนั่งแกะ code ใน VDO ออกมาหน่อย เพื่อศึกษาและดูว่ามีการแนะนำความสามารถอะไรของภาษา Kotlin บ้าง มาเริ่มกันเลย

1. เริ่มด้วย Data class กันเลย

ไม่ต้องมาเขียน setter/getter method ใน POJO รวมทั้ง method equals(), hashCode() และ toString() อีกต่อไป ตัวอย่าง code และการใช้งาน เป็นดังนี้ [gist id="0a4262751699d6f9623d741c85147417" file="1.kt"] แต่สิ่งที่สนใจมาก ๆ คือ เครื่องหมายไม่เท่ากัน ใน IntelliJ IDEA มันสวยมาก ๆ แสดงดังรูป จึงเกิดคำถามกับตัวเองว่า คืออะไร ? ดังนั้นจึงไปค้นหาพบว่ามันคือ Fira Code ต้องทำการเปิด feature นี้ใน preference ของ IDE เลือก Enable font ligatures และ Primary font เป็น Fira Code ดังรูป เพียงเท่านี้ก็สามารถแสดง operation ใน Equality หรือการเปรียบเทียบข้อมูลได้แล้ว แสดงตัวอย่างดังนี้ เพียงเท่านี้ก็สวยแล้ว ส่วน code จริง ๆ ก็เป็นเหมือนเดิมคือ !=, !==, == และ === นั่นเอง

2. ว่าด้วยเรื่องของการสร้าง function/method

ซึ่งทุก ๆ function/method ของ Kotlin ที่ไม่ใส่ return type ไปนั้น ไม่ใช่ void นะแต่เป็น Unit สามารถกำหนดค่า default ของ parameter ได้เลย ดังนั้นผู้เรียกใช้ function/method นี้ไม่ต้องส่งมาก็ได้ ยังไม่พอ เรียกใช้งานผ่าน Named parameter ซึ่งสลับตำแหน่งได้อีก ดังนี้ [gist id="0a4262751699d6f9623d741c85147417" file="2.kt"] มีอีกนิดนึงคือ ถ้า function/method มีเพียงบรรทัดเดียวและ return ข้อมูล สามารถใช้งาน expression body ได้เลย (Single expression function) [gist id="0a4262751699d6f9623d741c85147417" file="3.kt"] ซึ่งใน IntelliJ IDEA มีการแปลงให้อีกด้วย

3. ดูการใช้งาน Single expression function กับ When expression แบบสวย ๆ

ต้องการสร้าง function/method สำหรับแปลงค่าเงินเป็นสกุล Dollar ขึ้นมา สามารถเขียนด้วยการใช้ when ได้ดังนี้ สิ่งที่ชอบคือ ขั้นตอนการ refactor code ซึ่งมี 3 ขั้นตอนดังนี้ [gist id="0a4262751699d6f9623d741c85147417" file="4.kt"]

4. ว่าด้วยเรื่องของ Extension function

สามารถเพิ่มความสามารถใหม่ ๆ ได้ตามที่ต้องการ นั่นคือ extension function นั้นเอง ซึ่งหลาย ๆ ภาษาก็ทำได้ เช่นภาษา Swift เป็นต้น ตัวอย่าง code เป็นดังนี้ ซึ่งสร้าง function ใหม่ชื่อว่า percent และ percentOf [gist id="0a4262751699d6f9623d741c85147417" file="5.kt"] ยังไม่พอนะ ยังมี infix notation ให้ใช้อีกด้วย โดยทำการใส่ keyword infix ไปหน้า function จะทำให้ code ดูสวยงามมากยิ่งขึ้น ตัวอย่างเช่น [gist id="0a4262751699d6f9623d741c85147417" file="6.kt"]

5. ต่อด้วยเรื่อง Extension property

จาก code ตัวอย่างนั้นพบว่าการสร้าง BigDeciaml มันเหนื่อยมากหรือสร้างยากนั่นเอง มีทางในการสร้างที่ดีกว่าหรือไม่ ? แน่นอนว่า ทาง Kotlin ได้เตรียมวิธีการสร้างง่าย ๆ ไว้ให้ ตัวอย่างเช่น [gist id="0a4262751699d6f9623d741c85147417" file="7.kt"]

6. เรื่องของการสร้าง Data Type class ด้วย sealed class

ตัวอย่างเป็นการสร้าง data class สำหรับ return ผลการทำงานของส่วนต่าง ๆ ออกมา ซึ่งตัวอย่างคือ UserResult ประกอบไปด้วย Success และ Failure เขียน code ได้ดังนี้ [gist id="0a4262751699d6f9623d741c85147417" file="8.kt"] โดยในการใช้งานเรียกว่า Smart cast จะสังเกตุว่าใช้ผ่าน keyword is ซึ่ง compiler จะทำการ cast type ของ Result ให้แบบอัตโนมัติ แสดงดังนี้ ขอให้สนุกกับการ coding
↧
↧

สรุปเรื่อง Interface และ Composition design จาก Ultimate Go Workshop

May 26, 2017, 2:03 am
$
0
0

มีโอกาสมาเรียน course Ultimate Go Workshop จากงาน GopherCon Singapore โดยมีหัวข้อต่าง ๆ ดังนี้
  • Ultimate Go
  • Language mechanic
  • Software design
  • Concurrency
  • Profiling
ซึ่งเป็นเรื่องพื้นฐานแบบลึกมาก ๆ เนื่องจากลงไปถึง philosophy ของตัวภาษา Go ว่าเป็นอย่างไร ? ตั้งแต่เรื่อง integrity, readability, simplicity ไปจนถึง Productivity vs Performance Correctness s Performance ลงไปจนถึงว่า CPU แต่ละตัวทำงานอย่างไร ทำอย่างไรให้สามารถดึงข้อมูลมาทำงานใน CPU ได้รวดเร็วที่สุด Hardware นั้นชอบ data structure แบบ Array มากที่สุด เนื่องจากมัน predictable ได้ง่ายนั่นเอง ส่วน LinkedList มันตรงข้ามกันเลย การจัดการหน่วยความจำ !! การใช้งาน go tool สำหรับ tracing, profiling เพื่อ optimize การทำงานของ code !!

แต่เรื่องที่น่าสนใจและสนุกมาก ๆ คือ Interface and Composition Design

ซึ่งทำให้เข้าใจการออกแบบระบบได้อย่างชัดเจน รวมทั้งเข้าใจเหตุผลของการออกแบบแต่ละอย่างอีกด้วย ว่าต้องการแก้ไขปัญหาอะไรบ้าง ? ที่สำคัญทำให้ code แยกออกจากกันอย่างชัดเจน (Decouple) ผลที่ตามมาคือ ง่ายต่อการแก้ไข ให้จำไว้ว่า
Coding for Today Design for Tomorrow
มาเริ่มกันเลย

ขั้นตอนที่ 1 Structure composition

ในการพัฒนาระบบนั้นเริ่มต้น จากการแบ่งงานใหญ่ออกเป็นงานย่อย ๆ โดย code ตัวอย่างนั้น ต้องการดึงข้อมูลจากอุปกรณ์ต่าง ๆ ออกมา ซึ่งข้อมูลมีมากกว่า 1 บรรทัด จากนั้นทำการจัดเก็บข้อมูลเหล่านั้น มาดูกันว่า ทำการแยกงานย่อย ๆ ได้อะไรบ้าง 1. สร้างโครงสร้างข้อมูลชื่อว่า Data โดยสร้างด้วย struct ดังนี้ [gist id="f32b0009b12116d03ef92848f1219f5c" file="1.go"] 2. สร้างส่วนการดึงข้อมูลจากอุปกรณ์ โดยข้อมูลของอุปกรณ์ประกอบไปด้วย ชื่อเครื่องกับ Timeout สร้างด้วย struct และมี method Pull() สำหรับดึงข้อมูล ดังนี้ [gist id="f32b0009b12116d03ef92848f1219f5c" file="2.go"] 3. สร้างส่วนการจัดเก็บข้อมูลจากอุปกรณ์ มีโครงสร้างเหมือนกัน แต่สิ่งที่ต่างคือมี method Store() สำหรับจัดเก็บข้อมูลดังนี้ [gist id="f32b0009b12116d03ef92848f1219f5c" file="3.go"] 4. สร้างส่วน logic ของการ pull ข้อมูลจากอุปกรณ์จริง ๆ ด้วยการสร้าง method pull() ขึ้นมา จากนั้น extract ข้อมูลแต่ละบรรทัดออกมาดังนี้ [gist id="f32b0009b12116d03ef92848f1219f5c" file="4.go"] 5. สร้างส่วน logic ของการ store ข้อมูล ด้วยการสร้าง method store() ขึ้นมาดังนี้ [gist id="f32b0009b12116d03ef92848f1219f5c" file="5.go"] 6. สิ่งที่ยังขาดไปคือ ส่วนการทำงานหลัก สำหรับดึงและบันทึกข้อมูล [gist id="f32b0009b12116d03ef92848f1219f5c" file="6.go"]

จะเห็นได้ว่าเราทำงานแบ่งปัญหาใหญ่ ๆ ออกเป็นปัญหาเล็ก ๆ

เพื่อทำการแก้ไขไปเรื่อย ๆ จากนั้นทำการรวมหรือ composition เข้าด้วยกัน จนสามารถแก้ไขปัญหาที่ต้องการได้ นี่คือ ความสามารถที่สำคัญของนักพัฒนา software
แต่ว่านี่เป็นเพียงการเริ่มต้นเท่านั้น สำหรับ Coding for Today มันยังมีต่ออีกยาว !!
จากตัวอย่าง code นั้นพบว่า ทำงานได้อย่างดี แต่ปัญหาที่น่าสนใจ หรือ Code Smell คือ ในตอนนี้ Data กับ Behavior ของ Device และ Storage รวมกันอยู่ นั่นคือผูกมัดกันอย่างมาก
ลองคิดดูสิว่า ถ้ามีจำนวน Device และ Storage จำนวนมาก ซึ่งมีพฤติกรรมการทำงานที่แตกต่างกัน ดังนั้นจึงต้องหาวิธีแก้ไขปัญหา ?

ขั้นตอนที่ 2 Decoupling with Interface

โดย interface นั้นใช้สำหรับการกำหนดพฤติกรรมการทำงาน ซึ่งถูกใช้งานจากผู้เรียกใช้งานนั่นเอง เป็นแนวทางที่มาก ๆ ใน Go จากตัวอย่างจะแยกพฤติกรรมออกมาจาก Device และ Storage ดังนี้ สำหรับ Device จะแยกออกมาเป็น Puller สำหรับ Storage จะแยกออกมาเป็น Storer เขียน code ได้ดังนี้ [gist id="f32b0009b12116d03ef92848f1219f5c" file="7.go"] ผลที่ตามมาคือ ต้องทำการแก้ไข code ในส่วนของ method ที่ทำงาน pull() และ store() ข้อมูล จากเดิมที่ส่ง struct เข้าไป ก็เปลี่ยนเป็น interface ได้ดังนี้ [gist id="f32b0009b12116d03ef92848f1219f5c" file="8.go"] มาถึงตรงนี้เราสามารถแยกส่วนของข้อมูลกับพฤติกรรมการทำงานออกจากกัน ทำให้ตอบโจทย์เรื่องการเปลี่ยนแปลงได้ง่ายมากขึ้น และลดผลกระทบจากการเปลี่ยนแปลงอีกด้วย
ในงาน GopherCon มักจะพูดว่า interface คือ first-class citizen ด้วยนะ
โดยการทำงานร่วมกันนั้น เราไม่ต้องรู้หรอกว่า คุณเป็นใคร สนใจเพียงว่าทำอะไรร่วมกันได้บ้าง นั่นคือที่มาของ interface นั่นเอง

ขั้นตอนที่ 3 Interface Composition

จะเห็นได้ว่าการใช้งาน interface Puller และ Storer นั้นจะทำงานร่วมกันเสมอ ดังจะเห็นได้จาก method Copy() แสดงดัง code [gist id="f32b0009b12116d03ef92848f1219f5c" file="9.go"] สังเกตุได้ว่าสิ่งที่ส่งมายัง method Copy() คือ System ซึ่งเป็น struct ที่รวมเอา Device และ Storage ไว้ด้วยกัน แต่สิ่งที่ควรส่งมาคือ พฤติกรรมของการทำงานมากกว่า !! คำถามคือ จะส่งอะไรมาระหว่าง Puller และ Storer ? คำตอบคือทั้งสองตัว !! สิ่งที่ต้องทำคือ สร้าง interface ใหม่ชื่อว่า PullStorer เพื่อทำงานรวมทั้งสอง interface เข้าด้วยกัน แสดงดัง code [gist id="f32b0009b12116d03ef92848f1219f5c" file="10.go"] ยังไม่พอนะ ยังไม่จบ

ขั้นตอนที่ 4 Decoupling with Interface composition

จะเห็นได้ว่า struct System นั้น ยังผูกมัดอยู่กับ struct Device และ Storage คือข้อมูลนั่นเอง ดังนั้นเราควรที่จะแยกออกมา ด้วยการใช้งาน interface composition แทน นั่นคือ [gist id="f32b0009b12116d03ef92848f1219f5c" file="11.go"] มาถึงตรงนี้จะเห็นได้ว่า การทำงานแต่ละส่วนแยกออกจากกันอย่างชัดเจนด้วย interface ซึ่งทำให้ง่ายต่อการเปลี่ยนแปลง และลดผลกระทบจากการเปลี่ยนแปลงอีกด้วย

ยังไม่จบนะ จะสังเกตุได้ว่า มี composition interface ที่หน้าตาเหมือนกันเลย

นั่นคือเกิด duplication code ขึ้นมาแล้ว (Remove interface pollution) ดังนั้นให้ทำการลบ code ส่วนนั้นทิ้งไปซะ นั่นคือ interface PullStorer นั่นเอง จะได้ code ทั้งหมดดังนี้ [gist id="f32b0009b12116d03ef92848f1219f5c" file="12.go"]
มาถึงจุดนี้กันได้อย่างไร ? รู้สึกอย่างไรบ้างสำหรับการออกแบบ Interface และ Composition

สุดท้ายแล้วยังมีเรื่องที่น่าสนใจและมึนงงอีกมากมาย

ทั้งเรื่องการทำงานของ Garbase Collection ทั้งเรื่องการทำงานของ Slice ทั้งเรื่องการทำงานของ Goroutine ทั้งเรื่องการทำงานของ Concurrency ทั้งเรื่องของ Profiling และ Optimization แน่นอนว่าต้องใช้เวลาในการย่อยอีกสักพัก แล้วจะนำมาเขียนสรุปต่อไปครับ ขอให้สนุกกับการเขียน code
ที่สำคัญต้องเข้าใจด้วยว่าปัญหาที่คุณกำลังแก้ไขคืออะไร นั่นคือคุณเข้าใจ domain และ data นั่นเอง
Reference Websites https://github.com/ardanlabs/gotraining https://www.goinggo.net/2015/09/composition-with-go.html
↧

ว่าด้วยเรื่องการใช้งาน Context package ของภาษา Go

May 26, 2017, 9:44 pm
$
0
0

จากงาน GopherCon Singapore 2017 มี session อธิบายเกี่ยวกับการใช้งาน Context package โดยที่ context นั้นสามารถส่งค่าต่าง ๆ ระหว่าง process ใน request scope ซึ่งสามารถกำหนดค่าต่าง ๆ ใน context ได้ดังนี้ เช่น
  • withCancel()
  • withDeadline()
  • withTimeout()
  • withValue()
โดยตัวอย่างที่ใช้ context บ่อย ๆ คือการสื่อสารระหว่าง client-server ตัวที่ชัดที่สุดคือ การใช้งาน context ร่วมกับ net/http package ถ้าฝั่ง server ทำงานช้าเกินเวลาที่กำหนด จะส่งสัญญาณยกเลิกการทำงานกลับมา แต่มาเริ่มด้วย code ง่าย ๆ กันดีกว่า

เริ่มจาก code จำลองการทำงานของ function ที่ทำงานช้า ๆ

ทำงานตามลำดับกันดังนี้ [gist id="127c27c5f4fe810a2f7f2d976717109e" file="1.go"] ต่อมาลองคิดดูสิว่า ถ้าเจอปัญหาลักษณะนี้ แน่นอนว่า ไม่มีใครอยากรอไปเรื่อย ๆ เพราะว่าเปลืองทั้งเวลา เปลืองทั้ง resource ที่ต้องใช้งาน ดังนั้นสิ่งที่ต้องทำคือ การกำหนด Timeout

ถ้าเขียนด้วยภาษา Go นั้น

เราสามารถนำ buffered channel มาใช้จัดการได้ดังนี้ [gist id="127c27c5f4fe810a2f7f2d976717109e" file="2.go"]

แต่ข้อเสียของวิธีการนี้คือ

ถ้าการทำงานของ goroutine ใช้ resource เยอะมาก ๆ การรอจนกว่าจะ timeout น่าจะไม่มีประโยชน์อะไรเลย !! เนื่องจากเปลือง resource อย่างมาก เพราะว่าเรามั่นใจได้อย่างไรว่า roroutine มันถูกยกเลิกการทำงาน หรือ คืน resource ไปไหม ? ดังนั้นสิ่งที่เราต้องการคือ ยกเลิกการทำงานของ goroutine นั้น ๆ (Cancelation) คำถามคือ แล้วจะทำการยกเลิกอย่างไรดี ? คำตอบคือ การใช้งาน context โดย function ที่ทำงานจะต้องรับค่า context.Context เพิ่ม โดยใน context นั้นเราสามารถกำหนดค่าได้เยอะ จากตัวอย่างจะทำการกำหนด timeout เป็น 5 วินาที ดังนั้นถ้า function ทำงานเกิน 5 วินาทีแล้ว จะทำการยกเลิกการทำงานของ goroutine ทันทีดังนี้ [gist id="127c27c5f4fe810a2f7f2d976717109e" file="3.go"] เป็นวิธีการที่ดีกว่าทั้งสองแบบมาก ๆ จัดการเรื่อง timeout ได้ง่ายขึ้น จัดการเรื่อง การใช้งาน resource ได้ดีขึ้น ขอให้สนุกกับการเขียน code Resources https://talks.golang.org/2014/gotham-context.slide#1 http://dahernan.github.io/2015/02/04/context-and-cancellation-of-goroutines/ https://www.linkedin.com/pulse/gos-context-library-explained-smita-vijayakumar
↧
Search

พื้นฐานเกี่ยวกับ Code Coverage

May 27, 2017, 8:50 pm
$
0
0

มีโอกาสได้อธิบายเรื่องเกี่ยวกับ Code coverage จึงนำมาเขียนสรุปไว้นิดหน่อยว่า คืออะไร ? มีประโยชน์อะไร ? แต่ละภาษามีเครื่องมืออะไรบ้าง ? พร้อมตัวอย่าง code นิดหน่อย

Code coverage คืออะไร ?

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

แล้ว Code coverage ทำการคำนวณอะไรบ้าง ?

  • Function/method coverage จำนวนของ function/method ถูกเรียกใช้งาน
  • Statement coverage จำนวนของ statement ถูกเรียกใช้งาน
  • Branch coverage จำนวนของ branch หรือเงื่อนไขใน if statement ถูกเรียกใช้งานทั้ง true และ false
  • Line coverage จำนวนของบรรทัดที่ถูกเรียกใช้งาน
โดยแต่ละตัวจะสรุปเป็นตัวเลข 2 ค่าคือ source code ที่ถูกทดสอบ และ ไม่ถูกทดสอบ
อธิบายไปก็เข้าใจยาก ! ไม่ว่าจะเป็น statment คืออะไร ? ไม่ว่าจะเป็น branch คืออะไร ? ไม่ว่าจะเป็น Line หรือ Line of Code คืออะไร ? ดังนั้นมาดูจาก code ตัวอย่างกันดีกว่า

โดยเครื่องมือที่ใช้มีสำหรับแต่ละภาษาโปรแกรมเช่น

  • Java มี Cobertura, Jacobo และ Clover
  • JavaScript มี Istanbul, Blanket.js
  • PHP มี PHPUnit
  • Python มี Coverage.py
  • Ruby มี SimpleCov

มาเริ่มดู code ตัวอย่างด้วยภาษา JavaScript กันนิดหน่อย

[gist id="40f62c2eb11922b6fb7c8837d23640f7" file="coverage_01.js"] จากนั้นทำดูค่า Code Coverage ด้วย Istanbul ดังนี้ [code] $istanbul cover coverage_01.js [/code] ผลที่ได้เป็นดังนี้ ยังไม่พอนะ Istanbul ยังสร้างรายงานในรูปแบบ HTML ให้อีก ซึ่งดูได้ทั้งภาพรวมของ Code coverage และรายละเอียดในแต่ละบรรทัด แสดงดังนี้ แต่เพื่อความเข้าใจลอง comment หรือ ลบ code ในบรรทัดที่ 8 นั่นคือ เราไม่ทดสอบหรือเรียกใช้งาน กรณีที่เป็น false จะได้ผลของ Code coverage ดังนี้ คำอธิบาย ค่าของ Function coverage ยังคงเป็น 100% เนื่องจากยังถูกเรียกใช้งาน ค่าของ statement และ line coverage จะลดลงเหลือ 80% นั่นคือมีบางบรรทัดไม่ถูกทดสอบหรือเรียกใช้ ค่าของ Branch coverage ลดลงเหลือเพียง 50% นั่นหมายความว่า ในส่วนของการตรวจสอบเงื่อนไขใน if statement นั้น ทำการทดสอบหรือเรียกใช้งานเพียง branch เดียวเท่านั้น ซึ่งรายละเอียดแสดงดังรูป

เราเห็นประโยชน์อะไรจาก Code Coverage บ้าง ?

เป็นเครื่องมือที่ช่วยทำให้เรารู้ว่า source code ส่วนไหนถูกเรียกใช้งานหรือทดสอบหรือไม่ ? แต่ว่าทำงานถูกหรือไม่ ก็เป็นอีกเรื่อง !! ดังนั้น Code coverage จึงบอกได้เพียงว่า ส่วนไหนของ source code ถูกเรียกและยังไม่ถูกเรียกใช้ จากนั้นให้นำข้อมูลเหล่านี้มาช่วยตัดสินใจ ว่าจะทำอะไรต่อไป
ส่วนเรื่องความถูกต้องจำเป็นต้องทดสอบ เช่น unit test, integration test และ acceptance test เป็นต้น
ที่สำคัญอย่านำค่าของ Code coverage มาเป็น KPI เพื่อวัด performance ของทีมนะ เนื่องจากจะทำให้ทีมกดดัน และจะส่งผลต่อคุณภาพของ software อีก เช่นสนใจแต่ค่า Code coverage มากเกินไป จนไม่สนใจเรื่องความถูกต้อง !!!

สุดท้ายแล้วค่า Code coverage สูง ๆ

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

[Android] ลองใช้ ViewModel class จาก Architecture Component กันหน่อย

May 29, 2017, 10:15 am
$
0
0

จาก Architecture Component สำหรับ Android app ที่ทางทีมพัฒนาของ Google ประกาศออกมาในงาน Google I/O 2017 ที่ผ่านมา ดังนั้น เรามาลองใช้งานแบบง่าย ๆ ก่อนดีกว่า แน่นอนว่า ต้องเขียน code กันนิดหน่อย โดยสิ่งที่เลือกใช้ประกอบไปด้วย
  • ActivityLifeCycle
  • ViewModel
  • LiveData
  • Retrofit
แสดงดังรูป

ระบบที่พัฒนาขึ้นมานั้น ทำการค้นหาหนังสือจาก Google Book API

ซึ่งเป้าหมายหลักของระบบประกอบไปด้วย
  • ใช้งาน ViewModel
  • ใช้งาน LiveData สำหรับเก็บข้อมูลเพื่อใช้ใน ViewModel
  • ใช้งาน ActivityLifeCycle สำหรับจัดการเรื่องการเปลี่ยนแปลง configuration ต่าง ๆ
  • ไม่จำเป็นต้องใช้ method onSaveInstanceState() อีกต่อไป
ปล. code ตัวอย่างนี้ส่วนการดึงข้อมูลด้วย Retrofit ยังทำการ hardcode ไว้ใน ViewModel ซึ่งไม่ดีนะครับ !!
การพัฒนาใช้ Android Studio 3 Canary 2 ซึ่งเพิ่ม Maven Google Repository มาให้ตั้งแต่สร้างระบบงานอยู่แล้ว ดังนั้นจึงสบายขึ้นเยอะ แต่ถ้าเป็นระบบเก่า ๆ ก็ต้องใส่เองดังนี้ [gist id="9601ce2c2c0f7cff95d2f121a6325a48" file="build.gradle"] จากนั้นทำการเพิ่ม dependency ของ Lifecycle Architecture Component ซึ่งจะมี ViewModel มาให้ด้วยดังนี้ [gist id="9601ce2c2c0f7cff95d2f121a6325a48" file="app.build.gradle"] เริ่มเขียน code กันดีกว่า

ขั้นตอนที่ 1 สร้าง interface BookService สำหรับดึงข้อมูลจาก Google Book API

ด้วยการส่ง keyword ที่ต้องการค้นหาผ่าน HTTP GET ดังนี้ [gist id="9601ce2c2c0f7cff95d2f121a6325a48" file="BookService.java"]

ขั้นตอนที่ 2 สร้าง ViewModel ขึ้นมาชื่อว่า BookViewModel

ใช้สำหรับเก็บข้อมูลเพื่อนำไปแสดงผลใน View ซึ่งในการพัฒนาต้อง extends จาก ViewModel แน่นอนว่า ภายใน BookViewModel จะมี LiveData ทำการจัดเก็บข้อมูลที่มาจาก Google Book API และส่วนการดึงข้อมูลจาก Google Book API ก็อยู่ในส่วนนี้ด้วย ปล. เป็น code ที่ไม่ดีเลยนะครับ ต้องทำการแยกออกไปอยู่ใน model จะดีกว่ามาก !! [gist id="9601ce2c2c0f7cff95d2f121a6325a48" file="BookViewModel.java"]

ขั้นตอนที่ 3 ทำการเรียกใช้งาน ViewModel จาก Activity

ทำการสร้าง BookViewModel ผ่าน ViewModelProviders จากนั้นทำการดักพังการเปลี่ยนแปลงของข้อมูลผ่าน method observer() ทำการเปลี่ยน class ที่ extends จาก AppCompatActivity เป็น LifecycleActivity ส่วน method onSaveInstanceState() ก็ไม่จำเป็นแล้วนะ ที่สำคัญข้อมูลใน BookViewModel จะยังคงอยู่ใน Lifecycle ของ Activity ให้เลย ดังนั้นถ้ามีการเปลี่ยนแปลงต่าง ๆ เช่น Activity มีการสร้างใหม่ จะใช้ข้อมูลล่าสุดที่อยู่ใน Lifecycle ของ Activity เขียนง่าย ๆ ได้ดังนี้ [gist id="9601ce2c2c0f7cff95d2f121a6325a48" file="MainActivity.java"]
ปล. ถ้าอยากให้การสร้าง ViewModel ส่วนงามมากขึ้น แนะนำให้ใช้งาน Factory pattern มาช่วย
เพียงเท่านี้เราก็สามารถนำ ViewModel + LiveData + Activity Lifecycle มาใช้งานได้แล้ว ส่วน source code ของตัวอย่างอยู่ที่ Github :: Up1 :: Android ViewModel
↧
↧

XCode Playground แนะนำความสามารถใหม่ ๆ ของ Swift 4

May 29, 2017, 9:22 pm
$
0
0

เช้านี้เห็น XCode Playground สำหรับอธิบายความสามารถใหม่ ๆ ของ Swift 4.0 (Development/Snapshot) ได้อย่างน่าสนใจ ประกอบไปด้วย
  • One-sided ranges
  • String
  • Key path
  • Encoding และ Decoding
  • การปรับปรุงของ Dictionary และ Set
  • Generic
  • Class และ Subtype
  • Multi-line string
มาเริ่มต้นกันครับ น่าสนุกมาก ๆ ทำการ Download ได้จาก Github :: What’s new in Swift 4.0 ขั้นตอนการติดตั้งและใช้งาน Let’s coding with Swift 4.0 กันครับ
↧

[Golang] มาทำการ optimize code ด้วยการทำ benchmark และ profiling กัน

May 31, 2017, 4:06 am
$
0
0

จากงาน Golang meetup ครั้งที่ 1 ของกลุ่ม Golang Thailand มีการพูดถึงเรื่องการทำ profiling ทั้ง CPU และ Memory ทำการวิเคราะห์และหา code ที่ใช้ทรัพยากรมากเกินไป เพื่อทำการปรับปรุงประสิทธิภาพการทำงานของ code ให้ดีขึ้น ดังนั้นลองมาฝึกกันหน่อยสิ

เริ่มด้วย code ที่เขียนเอาไว้ แน่นอนว่าต้องมีชุดการทดสอบด้วย

เป็น code ของระบบ web application ว่าด้วยการบวกเลข !! มันจะง่ายไปไหม ? แต่ไม่เป็นไร !! โดยใน code นั้นมีการทำงานดังนี้
  1. รับจากจาก query string มีสองตัวคือ operand1 และ operand2
  2. ทำการแปลงข้อมูลจาก String เป็น Int
  3. ทำการบวกเลข
  4. ผลลัพธ์แสดงออกมาด้วย template

code เริ่มต้นเป็นดังนี้

[gist id="d689193018b4d75612045ab0c40c557a" file="original_add.go"] มีชุดการทดสอบดังนี้ [gist id="d689193018b4d75612045ab0c40c557a" file="add_test.go"] ก่อนจะทำอะไรต่อไปต้องทดสอบให้ผ่านก่อน !! [code] $go test [/code]

จากนั้นมาเริ่มทำ CPU profiling กันเลย

ด้วยคำสั่ง [code] $go test -run none -bench . -benchtime 3s -benchmem -cpuprofile cpu.out [/code] ได้ผลการทำงานดังนี้ [gist id="d689193018b4d75612045ab0c40c557a" file="1.txt"]

ทำการวิเคราะห์ CPU profile ด้วย pprof

[code] $go tool pprof profiling.test cpu.out [/code] จากนั้นจะเข้าสู่ interactive mode (สำหรับมือใหม่จะงงมาก ๆ ว่าต้องพิมพ์อะไรต่อไป) สามารถอ่านเพิ่มเติมได้ที่ Golang :: Blog :: Profiling go program [code] Entering interactive mode (type "help" for commands) (pprof) [/code] ต้องการดูว่ามี function ไหนบ้างใช้งาน CPU เยอะ ๆ ด้วย top20 [gist id="d689193018b4d75612045ab0c40c557a" file="top20.txt"] ต้องการดู function ที่ใช้งานเยอะ ๆ แบบชัด ๆ [gist id="d689193018b4d75612045ab0c40c557a" file="top_cum.txt"] function handleAdd() ใช้ CPU เยอะเลยนะ ไปดูใน function นี้กันหน่อยสิ [gist id="d689193018b4d75612045ab0c40c557a" file="handleAdd_list.txt"] ยังไม่พอ มาดูในรูปแบบกราฟกันหน่อย ด้วยการใส่คำสั่ง web list handleAdd แสดงผลดังนี้

มาถึงต้องนี้ทำให้เราเห็นว่า

บรรทัดที่ 24 เข้าใช้งาน CPU ถึง 4.92 วินาที !! น่าจะเป็นจัดที่น่าสนใจ เพื่อทำงาน optimize code ต่อไปนะ สิ่งที่ใช้เวลาการทำงานเยอะ ๆ คือ การเปิดไฟล์ template ขึ้นทำงานนั่นเอง นั่นคือ function template.parseFile() !! จาก code จะเห็นว่าทำการ parseFile() ทุก request ซึ่งเป็นวิธีการที่แย่มาก ๆ ดังนั้นมาทำการแก้ไข code ดีกว่า ด้วยการ parseFile() ครั้งเดียวพอ [gist id="d689193018b4d75612045ab0c40c557a" file="new_add.go"] จากนั้นทำการทดสอบใหม่อีกรอบ [gist id="d689193018b4d75612045ab0c40c557a" file="new_bench.txt"] สังเกตุไหมว่า performance ดีขึ้นเยอะมาก ๆ ลองดูกราฟสิ อีกสักนิดลองทำการเปรียบเทียบผลการทดสอบด้วย benchcmp นิดหน่อย [gist id="d689193018b4d75612045ab0c40c557a" file="compare.txt"] มาถึงตรงนี้เราทำเพียง CPU profiling นะ ยังเหลือ Memory profiling อีกนะ แต่เอาไว้ก่อนดีกว่า !! โดย code ที่ใช้งานอยู่ที่ Github :: Web Add Number ขอให้สนุกกับการ coding ครับ Reference Websites https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go https://medium.com/@hackintoshrao/analyzing-benchmarks-with-ease-using-benchcmp-and-benchviz-golang-add607fc46d6
↧

หนังสือน่าอ่านสำหรับ DevOps

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

มาดูหนังสือที่น่าสนใจเกี่ยวกับ DevOps ซึ่งผู้ที่สนใจเกี่ยวกับเรื่องนี้ควรอ่านเอามาก ๆ เพื่อทำให้เรารู้และเข้าใจมากขึ้น เพื่อให้สามารถนำมาใช้ให้เกิดประโยชน์มากกว่าโทษ มาดูกันว่ามีหนังสือเล่มไหนบ้าง ? เล่มที่ 1 The Phoenix Project เป็นการเล่าเรื่องราวของการพัฒนาและส่งมอบ Software ช่วยทำให้เข้าใจว่าการปรับปรุงและเปลี่ยนแปลงเป็นอย่างไร ซึ่งผลที่ตามมาคือ แนวคิดใหม่ ๆ ที่ต่างไปจากเดิม และที่สำคัญ ไม่อยากกลับไปเป็นเหมือนเดิมอีกเลย เล่มที่ 2 The DevOps Handbook เป็นหนังสือที่ต่อเนื่องมากจากเล่มแรก ซึ่งเป็นหนังสือ How-to ที่ลงในรายละเอียดมากยิ่งขึ้น ลงรายละเอียดเรื่องของ business value, culture และ เครื่องมือต่าง ๆ เป็นเป้าหมายหลักของการนำ DevOps practice มาใช้งานให้ประโยชน์สูงสุด เล่มที่ 3 Continuous Delivery เป็นหนังสือเล่มแรก ที่อธิบายเกี่ยวกับขั้นตอนแบบอัตโนมัติ ตั้งแต่การ build deploy ไปจนถึง Infrastructure management, data migration และ virtualization เพื่อลดความเสี่ยงในแง่มุมต่าง ๆ ของการพัฒนา software เล่มที่ 4 The DevOps 2.0 ว่าด้วยเรื่องของ DevOps กับสถาปัตยกรรมแบบ Microservice ตั้งแต่การทำงานกับโลกของ container การทดสอบเป็นอย่างไร การ deploy/release บ่อย ๆ ทำอย่างไร การ provisioning environment ต่าง ๆ ทั้งหมดนี้ทำงานแบบอัตโนมัติ เล่มที่ 5 Building DevOps Culture หนังสือเล่มนี้เน้นอธิบายเรื่องของการ transform วัฒนธรรมขององค์กร จากรูปแบบเดิมที่ต่างคนต่างทำ ต่างทีมต่างแยกงานกันทำของใครของมัน โดยไม่ได้สนใจผลสุดท้ายที่ออกมา มายังรูปแบบใหม่ ซึ่งเน้นการทำงานร่วมกันของคนจากส่วนต่าง ๆ เล่มที่ 6  Implementing Lean Software Development เป็นหนังสือที่อธิบายเกี่ยวกับ Lean Software Development ซึ่งเป็นพื้นฐานที่สำคัญของ DevOps
วันนี้เราอ่านหนังสือเกี่ยวกับ DevOps เล่มไหนบ้าง ?
Reference Websites https://dzone.com/articles/5-books-every-devops-enthusiast-must-read
↧
Viewing all 1997 articles
Browse latest View live
Search