สถิติของ Java Application Server ที่ได้รับความนิยมในปี 2016 จาก Plumbr

May 2, 2016, 11:07 pm

≫ Next: ว่าด้วยเรื่อง Clean Swift Architecture

≪ Previous: แปลเรื่อง Infrastructure as Code

$

0

0

มาดูสถิติการใช้งาน Java EE Server จาก Plumbr monitoring for performance ว่าในปี 2016 นั้นอะไรได้รับความนิยมกันบ้าง โดยข้อมูลที่ Plumbr จัดเก็บและนำมาสรุปผล ประกอบไปด้วย

• เวอร์ชันของ Java อะไรบ้าง เช่น 6, 7, 8
• ใช้ JVM อะไรบ้าง เช่น Oracle Hotspot และ OpenJDK
• Web/Application server อะไรที่ติดตั้งบ้าง
• มีการเปลี่ยนแปลงอย่างไรบ้าง

มาดูสถิติการใช้งานกันดีกว่า

เริ่มด้วยเวอร์ชันของ Java ที่ได้รับความนิยมในปี 2016

Java 7 ยังคงได้รับความนิยมสูงสุดอยู่ และ Java 8 ก็ตามมาติด ๆ ซึ่งน่าจะได้รับความนิยมสูงสุดต่อไปแน่นอน ส่วน Java 6 ก็ใช้น้อยมาก ๆ แสดงดังรูป ถ้าดูข้อมูลตั้งแต่ปี 2013 ถึง 2016 จะเห็นการเปลี่ยนแปลงที่ชัดเจนอย่างมาก แสดงดังรูป จากนั้นมาดู JVM กันนิดหน่อย พบว่า Oracle Hotspot ใช้เยอะสุดอยู่แล้ว 88% แสดงดังรูป

จากนั้นมาดูว่า Application Server ที่ใช้กันมาก ๆ มีอะไรบ้าง ?

• Apache Tomcat 58.22%
• Boss/WildFly 20.22%
• Jetty 10.67%
• Glass fish 5.56%
• Weblogic 2.89%
• อื่น ๆ นั้นประกอบไปด้วย IBM WebSphere, Resin, Orion, OC4J และ SAP NetWeaver เป็นต้น

แสดงดังรูป และมีข้อมูลการใช้งานตั้งแต่ปี 2013-2016 ให้ด้วยนะ ทั้งหมดนี้เป็นอีกข้อมูลที่น่าสนใจสำหรับชาว Java นำไว้ใช้สำหรับการพิจารณาและตัดสินใจต่อไปครับ Reference Websites https://plumbr.eu/blog/java/java-version-and-vendor-data-analyzed-2016-edition https://plumbr.eu/uncategorized/most-popular-java-ee-servers-2016-edition

---

ว่าด้วยเรื่อง Clean Swift Architecture

May 3, 2016, 9:10 pm

≫ Next: สรุปสิ่งที่น่าสนใจในรายงาน State of Agile ครั้งที่ 10  จาก VERSIONONE

≪ Previous: สถิติของ Java Application Server ที่ได้รับความนิยมในปี 2016 จาก Plumbr

$

0

0

วันนี้ได้อ่านบทความต่าง ๆ จาก Clean Swift จึงทำการสรุป และ แปลไว้อ่านกันนิดหน่อย ซึ่งน่าจะมีประโยชน์สำหรับนักพัฒนาอย่างมาก มาเริ่มด้วยเรื่อง Clean Swift คืออะไร ?

เป้าหมายหลักของ Clean Swift Architecture คือ แก้ไขปัญหา Massive View Controller

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

เมื่อลงมือทำแล้ว ผลที่ออกมาคือ ไม่สามารถส่งมอบงานตามเวลาที่บอกไว้ได้

นั่นคือ

• คุณไม่ได้ทำตามสัญญาที่ให้ไว้
• คุณทำลายความน่าเชื่อถือของตัวเอง
• คุณได้สร้างความไม่พอใจขึ้นมา
• ลูกค้าโมโห ฟาดงวงฟาดงาใส่คุณ
• เสียทั้งเวลา และ เงิน !!

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

บางครั้งลูกค้าไม่รู้ว่า เรามำการพัฒนาอย่างไร ? บางครั้งลูกค้าไม่เข้าใจว่า เราทำการพัฒนาอย่างไร ?

• ระบบมีความซับซ้อนอย่างไร ?
• ต้องหยุดเปลี่ยนความต้องการบ่อย ๆ
• ต้องสนใจที่ function ในการทำงานมากกว่า User Interface(UI)
• ถ้าทำการแก้ไข code ที่ทำไว้สัก 1-2 เดือนที่แล้ว จะใช้เวลาน้อยใช่ไหม ?

ฝั่งนักพัฒนาก็เช่นกัน เข้าใจสิ่งที่เขียนหรือสร้างเพียงใด ?

code เป็นอย่างไร ? มีกี่ class ? มีกี่ method ? มี loop และ condition ที่ซับซ้อนไหม ? code แต่ละบรรทัดทำการทดสอบไหม ? เมื่อเกิดปัญหาแล้ว รู้สาเหตุหรือไม่ ? หรือต้องทำการ debug ? เมื่อเกิดปัญหาแล้ว สามารถจำลอง หรือ สร้างปัญหาเหล่านั้นได้หรือไม่ ? เมื่อทำการเปลี่ยนแปลง code แล้ว สามารถเห็นผลของการเปลี่ยนแปลงหรือไม่ ? ทำซำ้ ๆ แบบนี้ไปจนกว่าจะแก้ไขปัญหาได้ หรือว่า เมื่อทำการแก้ไข หรือ เพิ่ม code ใหม่เข้าไปแล้ว คุณจะรู้สึกกลัวว่า สิ่งที่แก้ไข หรือ เพิ่มเข้าไปนั้น มันจะไปกระทบต่อส่วนอื่น ๆ !! เพราะว่า ไม่มีชุดของ unit test และไม่สามารถทำ regression test ได้บ่อย ๆ

ซึ่งปัญหาต่าง ๆ เหล่านี้มันคือ วงจรชีวิตแบบแย่ ๆ ของการพัฒนา software ที่พบเจอกันอยู่อย่างเสมอ !!

ดังนั้นวิธีการแก้ไขปัญหา เรามักจะใช้ MVC pattern (Model View Controller)

ถ้าเป็น iOS app นั่นคือ เราทำการ refactor code ในส่วนของ View Controller ให้อยู่ในโครงสร้างที่ดีขึ้น นั่นคือ แยกส่วนการทำงานที่ไม่ควรอยู่ใน View Controller ออกมา ทำการแยกส่วนของ business logic ไปไว้ที่ model เป็นวิธีการที่เรียบง่ายมาก ๆ แถมทำให้เราเขียนชุดการทดสอบในแต่ละส่วนได้ง่ายมาก ๆ

แต่มีนักพัฒนาน้อยคนมาก ๆ ที่จะทำ !! มันแปลก ๆ ดีนะ

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

ส่งที่เรากำลังทำอยู่ มันคือการแก้ไขที่ต้นเหตุของปัญหาหรือเปล่านะ ?

ต้นเหตุของปัญหาหลัก ๆ คือ Architecute ของระบบงาน !! แต่เมื่อไปค้นหาว่ามี Architecture แบบไหนบ้าง ก็จะเจอแนวคิดมากมาย เช่น

• MVC
• MVP
• MVVM
• Reactive
• VIPER
• Protocol Oriented MVVM

จะใช้อะไรดีล่ะ ? !!!!! แนะนำให้ลองทุก ๆ ตัวดูนะ

แต่สิ่งที่จะแนะนำและอ้างอิงคือ แนวคิด Clean Architecture ของคุณ Uncle Bob

โดยแนวคิดนี้จะช่วยทำให้

• ทำการหาและแก้ไขปัญหาได้ง่ายและรวดเร็วขึ้น
• มั่นใจในการเปลี่ยนแปลง
• ง่ายต่อการเพิ่ม feature ใหม่ ๆ
• แต่ละ method/function จะสั้น ๆ และมีหน้าที่การทำงานเพียงอย่างเดียว
• ทำการแยกส่วนการทำงานออกจากกันอย่างชัดเจน
• แยกส่วนการทำงานออกจากส่วนการแสดงผล
• สร้างส่วนการทำงานที่ใช้ซ้ำ ๆ ออกมา เพื่อให้สามารถ reuse ได้ง่าย
• ทำการเขียน code ที่ดูแลรักษาได้ง่าย
• ทำการเขียน unit test เพื่อทดสอบ code ที่เขียนขึ้นมา

ส่วนรายละเอียดของ code ตัวอย่างดูเพิ่มเติมได้ที่ Github :: Clean Swift ซึ่งจะนำมาสรุปต่อไป สำหรับ Clean Swift เป็นแหล่งความรู้ที่นักพัฒนาพลาดไม่ได้เลยนะ ลองทำการศึกษาและนำไปใช้งานดูครับ

ปล. ไม่ใช่เพียง iOS app เท่านั้นนะ ระบบงานอื่น ๆ ก็สามารถนำแนวคิดไปใช้งานได้อีกด้วย

สรุปสิ่งที่น่าสนใจในรายงาน State of Agile ครั้งที่ 10  จาก VERSIONONE

May 5, 2016, 7:05 pm

≫ Next: สวัสดีกับ Docker For Mac beta

≪ Previous: ว่าด้วยเรื่อง Clean Swift Architecture

$

0

0

มาดูรายงานเรื่อง State of Agile ครั้งที่ 10 จาก VERSIONONE กัน ซึ่งน่าจะมีประโยชน์สำหรับการนำแนวคิด Agile มาปรับใช้กับองค์กร และ ทีมงานไม่มากก็น้อย รวมทั้งยังช่วยตอบคำถามต่าง ๆ ได้ดีอีกด้วย มาเริ่มกันเลย

มาดูข้อมูลสำหรับคนที่ถูกสำรวจในรายงานครั้งนี้

• 53% บอกว่ามีการนำ Agile มาใช้น้อยกว่าครึ่ง
• มีเพียง 9% เท่านั้นที่บอกว่า ทุกคนในองค์กรนำ Agile มาใช้งาน
• 83% ทำงานแบบ distributed team
• 70% ใช้ outsourcing สำหรับการพัฒนา

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

ประโยชน์ที่ได้จาก Agile มีอะไรบ้าง ?

โดยนำข้อมูลจาก 3 อันดับแรกมาเท่านั้น

1. สามารถปรับเปลี่ยนลำดับความสำคัญของงานได้
2. Team productivity
3. Project visibility

ส่วน Faster time-to-market อยู่ในอันดับที่ 6 และที่น่าสนใจคือ ลดค่าใช้จ่ายในการส่งมอบ ไม่มีอยู่ในรายงานนะครับ !!

วัดความสำเร็จของ Agile ได้อย่างไร ?

1. On-time delivery
2. Product quality
3. Customer satisfaction

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

1. 57% วัดจาก Velocity นั่นคือความเร็วในการทำงานของทีม
2. 51% วัดจาก Iteration burndown
3. 41% วัดจาก Release burndown

ใช้งาน Agile method และ Practice อะไรกันบ้าง ?

1. 58% ใช้ practice จาก Scrum
2. 10% ใช้ practice จาก Scrum และ Extreme Programming
3. 8% ใช้ practice จากหลาย ๆ แนวคิดเข้าด้วยกัน

เทคนิคที่ใช้กันเยอะ ๆ มีดังนี้

1. Daily Standup
2. Prioritised backlogs
3. Short iteration
4. Retrospective
5. Iteration planning
6. Release planning
7. Unit testing
8. Team-based estimation
9. Taskboard
10. Iteration review

สาเหตุอะไรบ้างที่ทำให้การนำ Agile มาใช้ล้มเหลว ?

1. วัฒนธรรมขององค์กรที่ไม่สอดคล้องกับ Agile
2. ขาดประสบการณ์
3. ขาดการสนับสนุนจากฝ่าย management
4. ขาดการสนับสนุนสำหรับการปรับเปลี่ยนวัฒนธรรมขององค์กร
5. ข้อขัดแย้งของ Agile practice และ process

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

จากรายงานนี้ก็มีสิ่งที่แปลก ๆ และ น่าคิดหลายอย่างเหมือนกันนะ !!

ทั้งจากใครบ้างที่มาตอบแบบสอบถามเหล่านี้

แต่ที่น่าคิดมากกว่า คือ มีเพียง 1% เท่านั้น ที่บอกว่าการนำเอา Agile มาใช้ในองค์กรแล้วล้มเหลว !!

มองผ่าน ๆ แล้วน่าจะดีนะ แต่มันแปลก ๆ ไหมนะ หรือว่า คำว่าล้มเหลวของแต่ละคน มีคำจำกัดความที่แตกต่างกันไป (Lack of definition) ซึ่งอาจจะเป็นอีกสาเหตุหนึ่งที่ทำให้ผลการสำรวจผิดแปลกไป ต่อมาเรื่องของเทคนิคต่าง ๆ ที่ใช้งาน แน่นอนว่ามีการใช้งาน Daily Standup และ Prioritized backlog กันเยอะมาก ๆ แต่มีเพียง 54% เท่านั้นที่ทำ Iteration review !! แต่มีเพียง 45% เท่านั้นที่ developer และ tester ทำงานอยู่ทีมเดียวกัน !! มันดูแปลก ๆ ไหม เหมือนว่ายังคงทำงานแบบ Waterfall หรือ Traditional กันอยู่นะ ส่วนเรื่องการวัดความสำเร็จของการนำ Agile มาใช้ จากรายงานจะเขียนว่า เน้นไปที่ความเร็ว หรือ Velocity นั่นหมายความว่า เรากำลังแข่งกันที่ความเร็วกันหรือ ? ตรงนี้ต้องระวังไว้ด้วย เพราะว่า ความเร็วที่ขาดคุณภาพ เพราะว่า ความเร็วที่ขาดความพึงพอใจของลูกค้า มันไม่น่าจะใช่ตัววัดความสำเร็จที่แท้จริง สำหรับ version เต็ม ๆ ก็ลองไป Download มาอ่านกันดูครับ

สวัสดีกับ Docker For Mac beta

May 5, 2016, 9:25 pm

≫ Next: สำหรับ Android App :: จะจัดการกับ Legacy code อย่างไรดี ?

≪ Previous: สรุปสิ่งที่น่าสนใจในรายงาน State of Agile ครั้งที่ 10  จาก VERSIONONE

$

0

0

วันนี้เพิ่งสังเกตุเห็นว่าใน Junk mail นั้นมี access key สำหรับการใช้งาน Docker for Mac beta ส่งมาแล้วว (เกือบลบทิ้งไปเสียแล้ว) ดังนั้นมาลองใช้งานกันดีกว่า ว่ามันเป็นอย่างไรบ้าง ?

เริ่มจากการติดตั้ง

จากนั้นก็จะให้ใส่ Key access และ ถามหา permission ในการติดตั้งบางอย่าง เช่น networking component เป็นต้น ถ้ามีการใช้งาน Docker อยู่แล้ว จะถามว่าต้องการ migrate มาหรือไม่ ? จากนั้นเราก็พร้อมใช้งาน Docker for Mac กันแล้ว ลองดู version ของ Docker หน่อยสิ

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

ในตอนนี้ใช้งาน Docker 1.11.1 อยู่นะ [gist id="a8d6f3bca44e0073291f2dbd25c3ff9c" file="docker-info.txt"] จากนั้นลองติดตั้ง Redis เล่น ๆ กันหน่อยสิ [gist id="a8d6f3bca44e0073291f2dbd25c3ff9c" file="docker-redis.txt"] ลองไปอ่านเอกสารดูพบว่า Docker for Mac มันทำงานอยู่บน xhyve ทำให้เราไม่ต้องติดตั้งพวก VirtulBox, VMWare อีกต่อไป ส่งผลทำให้เร็ว และ เสถียรกว่าเดิมมาก ๆ และไม่จำเป็นต้องใช้งานและมี docker-machine อีกต่อไปแล้ว

แต่ถ้ามีการใช้ environment ที่หลากหลาย และ ต่าง version กัน แถมเรา ๆ ท่าน ๆ ยังใช้บ่อยอีกด้วย แน่นอนว่า docker-machine ยังมีความจำเป็นอยู่นะ !!

ยังไม่พอนะ พวก Docker toolbox ก็เอาทิ้งไปได้เลย เพราะว่า จะใช้อะไรก็ไป download มาเพิ่มเอง เช่น Dashboard ก็ใช้ Kitematic เป็นต้น

ปล. ลองทำการ run app server ทิ้งไว้ ก็กิน batt กันน่าดูเชียวนะ !!

จากการใช้งานในเบื้องต้น

ที่สำคัญคือ ประสบการณ์การใช้งานที่เปลี่ยนไป มันแจ่ม และ ง่ายมาก ๆ สำหรับ Local Docker for development บน Mac เชื่อได้เลยว่า การพัฒนาและการติดตั้งระบบงานต้องเปลี่ยนไปอย่างมากแน่นอน !!

วันนี้นักพัฒนาเริ่มศึกษาเทคโนโลยีเหล่านี้กันหรือยัง ?

สำหรับ Android App :: จะจัดการกับ Legacy code อย่างไรดี ?

May 6, 2016, 7:53 pm

≫ Next: Android :: จะทดสอบการเชื่อมต่อ Network อย่างไรดี ?

≪ Previous: สวัสดีกับ Docker For Mac beta

$

0

0

ระหว่างเตรียมเอกสารสำหรับการแบ่งปันเรื่อง Automated testing for Android app เกิดคำถามที่น่าสนใจว่า เราจะจัดการและรับมือกับ Legacy code ของ Android app อย่างไรดี ? เนื่องจากหลาย ๆ คนน่าจะกำลังเผชิญชะตากรรมนี้อยู่

สำหรับ Android developer ลองให้ความเห็นสิว่า จะทำอย่างไรดี ?

ในการพัฒนาระบบงานต่าง ๆ นั้น

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

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

บางคนบอกว่า เนื่องจากไม่มี Unit test ไงล่ะ ?

หรือมี Unit test น้อยเกินไปไม่เพียงพอ ดังนั้นจึงต้องเขียน Unit test เพิ่มเข้าไปทั้งหมด

คำถามคือ คุณรู้ไหมว่า การเขียน Unit test เข้าไปใน Legacy code มันเป็นเรื่องที่ยากลำบากมาก ๆ ? ดังนั้นอย่าไปเขียนเลย ส่งต่อไปให้ทีม QA/Tester เป็นคนทดสอบเถอะนะ !!

คำถามคือ เราไม่ได้แก้ไขที่ต้นเหตุกันเลยใช่ไหมนะ ? ดังนั้น เรามาแก้ไขปัญหาที่ต้นเหตุกันดีไหม ? ขอแนะนำขั้นตอนดังต่อไปนี้ 1. แนะนำแนวคิดของ Continuous Integration (CI) ให้สมาชิกในทีมรู้และเข้าใจ และทำการสร้าง CI Server เพื่อนำมาใช้ build, test และ packaging ระบบงานแบบอัตโนมัติ 2. ทำการ configuration ของ Andrid project ใน Android Studio เพื่อให้พร้อมสำหรับการนำแนวคิดของ Test-First และ Test-Driven Development (TDD) มาใช้ในการพัฒนาระบบงาน เช่น Unit test ด้วย JUnit 4 และ UI test ด้วย Espresso เป็นต้น 3. ทำการเขียน Unit test เล็ก ๆ สำหรับ Legacy code หรือ code เก่า จากนั้นลองทำการทดสอบ และนำขึ้นไปทำงานบน CI Server 4. ทำการสอน พาทำ และ แสดงตัวอย่างการเขียน Unit test ให้ทีม เพื่อทำให้ทุกคนมีความรู้ความเข้าใจเกี่ยวกับ Unit test และการทำงานของ CI Server ที่สำคัญคือ ให้เห็นประโยชน์ของสิ่งที่กำลังจะทำ 5. ทำการเพิ่ม Code coverage เข้าไปในระบบงาน จากนั้นให้ทีมกำหนดเป้าหมายของ Code coverage ตัวอย่างเช่น 5-10% ก่อน เพื่อเสริมสร้างกำลังใจ 6. เพิ่ม Espresso หรือ UI test เข้ามา เพื่อเพิ่มมิติของการทดสอบเข้าไป เนื่องจาก Unit test ไม่ได้บอกว่า App จะสามารถทำงานได้นะ !! แต่เขียนเท่าที่จำเป็นเท่านั้น เนื่องจากใช้เวลาในการทดสอบนานนั่นเอง และนำขึ้นไปทำงานบน CI Server 7. ทำการเขียน Unit test เฉพาะ feature ใหม่ ๆ หรือ Bug เท่านั้น Code ใหม่ ๆ ก็ให้เขียน Unit test คลุมซะ ยิ่งใช้แนวคิดของ Test-Driven Development (TDD) ไปเลยยิ่งดี แต่ถ้าต้องทำงานร่วมกับ code ชุดเดิม ก็ให้เริ่มนำแนวคิด Test double มาใช้งาน เช่นการ Mock และ Stub เป็นต้น เพื่อแยก code ระหว่างชุดเก่าและชุดใหม่

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

8. พยายามแยก code เก่าออกมาจากระบบงานให้ได้มากที่สุด ตัวอย่างเช่นแยกออกมาเป็น library และ interface เป็นต้น เพื่อลดการแก้ไข code เก่า นั่นคือ ลดผลกระทบจากการเปลี่ยนแปลงนั่นเอง 9. พยายามลบ code ที่ไม่ได้ใช้งานออกไป !! ปล. เราจะรู้ได้อย่างไรล่ะ ? 10. ทำการเขียน Unit test ใน code ที่แยกออกมา และ Refactor code นั่นคือการปรับปรุง code เก่า ๆ เพื่อความมั่นใจ จำเป็นจะต้องเขียน Unit test ให้ครอบคลุม หรือให้มีค่า Code coverage ประมาณ 70-80% ขึ้นไป

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

กฎเหล็ก !! อย่าแก้ไข code เก่า เมื่อทำการเพิ่ม feature ใหม่ โดยเด็ดขาด (Open/Closed Principle) ให้พยายามแยก code เก่าออกมาจาก code ใหม่ ตัวอย่างเช่น การสร้าง interface มากั้นการทำงาน เป็นต้น แต่ถ้าต้องแก้ไขจริง ๆ ให้เขียน Unit test คลุมซะ จากนั้นให้ทำการ Refactor code เก่าซะ ซึ่งจำเป็นต้องมี Code coverage ที่สูงมาก ๆ นะ เพื่อทำให้คุณ และ ทีมมั่นใจต่อการแก้ไข code นั่นเอง

สำหรับ Android developer ลองให้ความเห็นสิว่า จะทำอย่างไรดี ?

Android :: จะทดสอบการเชื่อมต่อ Network อย่างไรดี ?

May 10, 2016, 3:15 am

≫ Next: สรุปสิ่งที่แบ่งปันใน Course Automated testing for Android App

≪ Previous: สำหรับ Android App :: จะจัดการกับ Legacy code อย่างไรดี ?

$

0

0

คำถามที่น่าสนใจคือ ถ้าต้องการทำทดสอบส่วนการติดต่อผ่าน Network เช่นเรียกใช้งาน RESTful API, WebService เป็นต้น ไม่ว่าจะใช้ library ใด ๆ ก็ตาม เช่น HttpURLConnection และ Retrofit เป็นต้น เราจะเขียนชุดการทดสอบอย่างไรดี ? เนื่องจากมีหลายวิธีเหลือเกิน ดังนั้นจึงขอสรุปง่าย ๆ คือ มีการทดสอบ 2 แบบคือ

1. ทำการทดสอบผ่าน Emulator/device
2. ทำการทดสอบโดยไม่ใช้ Emulator/device

แบบที่ 1 ทำการทดสอบผ่าน Emulator/device

มีเป้าหมายเพื่อทดสอบว่า app ยังสามารถทำงานได้จริงบน Emulator/device จริง ซึ่งเป็นการทดสอบมุมมองของผู้ใช้งาน (Customer testing) เนื่องจากต่อให้ app ดีเพียงใด แต่ถ้าผู้ใช้งานไม่สามารถติดตั้งได้ แต่ถ้าผู้ใช้งานไม่สามารถใช้งานได้ มันก็คือ app กาก ๆ เท่านั้นเอง !! แต่ข้อเสียของการทดสอบแบบนี้คือ ใช้เวลาในการทดสอบนาน เนื่องจากต้องทำการติดตั้ง และ ทดสอบผ่าน app จริง ๆ นั่นเอง ดังนั้นจำนวน test case ของ End-to-End test จะต้องไม่เยอะจนเกินไป หรือให้มีเท่าที่ครอบคลุมในระดับ feature นั่นเอง

คำถาม แล้วทดสอบอย่างไร ต้องใช้เครื่องมือ framework และ library อะไรบ้าง ?

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

• ก่อนทำการทดสอบแต่ละ test case ต้องทำการสร้างและ start MockWebServer
• ในแต่ละ test case ทำการจำลองข้อมูลที่ส่งกลับมาจาก server ทั้ง success และ failure
• ทำการทดสอบผ่าน UI ด้วย Espresso
• เมื่อจบการทดสอบในแต่ละ test case จะปิด server ลงไป

เขียน code สำหรับการทดสอบได้แบบนี้ [gist id="76d172c4cb4b50ae9314f53a7054c606" file="MainActivityTest.java"] ข้อดีของวิธีการนี้คือ เราสามารถทดสอบในกรณีต่าง ๆ ได้ง่าย ตาม HTTP Code เช่น 200, 404 และ 501 เป็นต้น รวมทั้ง code ที่เขียนขึ้นมาไม่เยอะเท่าไร แต่ข้อเสียหลักคือ ถ้าต้องการให้ response มันเป็นแบบ dynamic หรือเปลี่ยนแปลงไปตาม parameter ที่ส่งไปให้ จะต้องเขียน code เพิ่มอีกเยอะเลย ยังไม่พอนะ Retrofit ยังมี Retrofit Mock ให้ใช้อีก  ซึ่งสามารถกำหนดพฤติกรรมการทำงานของ network ได้เลย เช่น

• Delay ของระบบ network
• จำนวน error rate ของการทำงาน

แต่ถ้าไม่อยากเขียน code ให้ยุ่งยาก ก็มีเครื่องมืออื่น ๆ ให้ใช้งานสำหรับจำลอง Web Server เช่น WireMock และ Stubby เป็นต้น แนะนำให้ใช้งานร่วมกับ BuildConfig

แบบที่ 2 ทำการทดสอบโดยไม่ใช้ Emulator/device

รวมทั้งไม่ต้อง start server เช่น MockWebServer เนื่องจากใช้เวลาในการทดสอบที่นานเกินไป โดยปกติเราสามารถเขียนการทดสอบโดยใช้ Mocking framework เช่น Mockito ซึ่งเป็นเรื่องที่ยุ่งยากพอสมควร ดังนั้นเราจะทำการทดสอบในระดับ service หรือส่วนการทำงานหลักมากกว่า ตัวอย่างเช่น [gist id="76d172c4cb4b50ae9314f53a7054c606" file="GitHubService.java"] เมื่อแยกส่วนการทำงานต่าง ๆ ออกจากกัน แล้วนำมาเชื่อมด้วย Dependency Injection framework เช่น Dagger หรืออาจจะเขียนเองก็ได้ ส่งผลทำให้โครงสร้างของระบบดูเป็นระเบียบมากยิ่งขึ้น ทำให้มีแนวคิดที่ดีเกิดขึ้นมามากมายเช่น

• MVC
• MVP
• MVVM
• VIPER

สุดท้ายแล้ว

อย่าไปทดสอบ Retrofit แบบตรง ๆ ด้วยการ mock นะ เพราะว่า มันไม่ได้มีคุณค่าอะไรต่อคุณและ app เลย ให้ทดสอบในระดับ service การทำงานของระบบเลยดีกว่า แต่ถ้าต้องการความมั่นใจกว่า ก็แนะนำให้ใช้ตามแบบที่ 1 ซึ่งแน่นอนว่า มีทั้งข้อดีและข้อเสีย

ดังนั้นจึงต้องคิด วิเคราะห์ แยกแยะ ด้วยนะ ว่าสิ่งที่เราทำอยู่นั้น มันมีคุณค่าต่อคุณ และ app หรือไม่ ? ถ้าไม่ หรือ ไม่คุ้มต่อการลงทุน ก็ไม่ควรทำ !!

ปล. อย่าลืมทำหน้า monitoring ของระบบต่าง ๆ ที่เกี่ยวข้องด้วยนะ เช่น RESTful API แต่ละตัวมีสถานะอย่างไรบ้าง ? รวมถึงข้อมูลของการเรียกใช้งานอีกด้วย

สรุปสิ่งที่แบ่งปันใน Course Automated testing for Android App

May 12, 2016, 7:24 am

≫ Next: สรุป Bad Code แบบขำ ๆ กันหน่อย !!

≪ Previous: Android :: จะทดสอบการเชื่อมต่อ Network อย่างไรดี ?

$

0

0

สองวันที่ผ่านมามีโอกาสแบ่งปัน เรื่องการทดสอบแบบอัตโนมัติสำหรับ Android app (Automated testing for Android App) ซึ่งจัดโดยสถาบัน IMC จึงทำการสรุปเนื้อหาต่าง ๆ ไว้ดังต่อไปนี้

วันที่หนึ่ง

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

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

โดยการทดสอบที่แนะนำ และพาทำ workshop ประกอบไปด้วย 1. Unit testing ด้วย JUnit4 สำหรับการทดสอบในส่วนของ business logic รวมทั้งส่วนการทำงานภายในของ Android App โดยขอเรียกว่าเป็น Developer testing ซึ่งการทดสอบไม่จำเป็นต้องใช้งาน Emulator หรือ Device จริง ๆ เลย ส่งผลให้การทดสอบเร็วมาก ๆ ได้นำเอาแนวคิด Test-Driven Development (TDD) เข้ามาใช้งาน ตลอดจนเรื่องของ Code coverage อีกด้วย รวมทั้งแนะนำเทคนิคต่าง ๆ ของ JUnit4 2. User Interface testing (UI) ด้วย Espresso สำหรับการทดสอบในมุมมองของผู้ใช้งาน หรือ Customer testing นั่นคือ ทำการทดสอบผ่าน User Interface ของ App นั่นเอง แน่นอนว่า ต้องทำการทดสอบบน Emulator หรือ Device จริง ๆ เพื่อทำให้มั่นใจว่า App ที่พัฒนาขึ้นมานั้น ติดตั้งได้จริง ทำงานได้จริง ทำให้ใช้เวลาในการทดสอบนานกว่า Unit test อย่างมาก ดังนั้นจำเป็นต้องทดสอบในระดับ feature เท่านั้น 3. Stress testing ด้วย Monkey test เป็นเครื่องมือที่มีมากับ Android SDK อยู่แล้ว จะทำสร้าง event สำหรับการใช้งาน App แบบมั่ว ๆ เพื่อทดสอบว่า App ที่เราพัฒนายังสามารถทำงานได้ ในสถานการณ์ หรือ การใช้งานรูปแบบต่าง ๆ หรือไม่

วันที่สอง

หลังจากที่เราทำการทดสอบในส่วนต่าง ๆ เรียบร้อยแล้ว จากนั้นจึงแนะนำเรื่องของ Continuous Integration(CI) ซึ่งเป็นแนวปฎิบัติเพื่อ

• ทำการ integrate code ในส่วนต่าง ๆ เข้ากันบ่อย
• ทำการทดสอบอยู่อย่างบ่อย ๆ
• ทำให้ได้รับ feedback ต่าง ๆ อย่างรวดเร็ว

โดยให้ทุกคนสร้างระบบ Continuous Integration ด้วย Jenkins รวมทั้งการออกแบบ build pipeline ของการทำงานอีกด้วย ตั้งแต่การดึง source code จาก Version Control System การ compile source code การทดสอบ Unit test การทำสอบ UI test การทำรายงานเรื่อง Code coverage จากนั้นทำการแนะนำเรื่อง Continuous Delivery และ Continuos Deployment ซึ่งทำการแนะนำ Fastlane สำหรับ Android app ทั้ง Supply และ Screengrab เพื่อสร้างระบบการ deploy แบบอัตโนมัติ เป็นเรื่องใหม่แต่อยากขอแนะนำให้ลองนำไปใช้งานดูนะ มันแจ่มมาก ๆ ปิดท้ายด้วยเรื่องของ Mocking หรือ Test double แน่นอนว่ามีเรื่อง Testable code อีกด้วย ในส่วนนี้อาจจะสอนเร็วไปหน่อย !! แต่อยากให้นักพัฒนาทุกคนลองกลับไปศึกษาเพิ่มเติม เนื่องจากเป็นสิ่งที่นักพัฒนาทุกคนต้องเข้าใจ และนำไปประยุกต์ใช้งานได้ เช่น เรื่องของ SOLID, Refactoring และ Clean code เป็นต้น

สุดท้ายแล้ว

หวังว่าความรู้ต่าง ๆ ในสองวันนี้ น่าจะเป็นจุดเริ่มต้นสำหรับการเดินทางเรื่อง Automated testing และนำไปต่อยอดเพื่อประยุกต์ใช้สำหรับการพัฒนา Android App ต่อไป ขอบคุณทั้ง 16 คนที่มาร่วมเดินทางไปกับผม และทางสถาบัน IMC ที่ให้โอกาส ส่วนตัวผมได้ทั้งความรู้ และ ความสนุกสนานอย่างมาก รวมทั้งจะนำ feedback ต่าง ๆ ไปปรับปรุงสำหรับครั้งต่อ ๆ ไปครับ

สรุป Bad Code แบบขำ ๆ กันหน่อย !!

May 12, 2016, 9:45 pm

≫ Next: สรุปการติดตั้ง Local composer repository ด้วย Satis

≪ Previous: สรุปสิ่งที่แบ่งปันใน Course Automated testing for Android App

$

0

0

วันนี้เห็น source code ต่าง ๆ ที่น่าสนใจมาก ๆ จึงลองไปค้นหาข้อมูลเพิ่มเติม ก็เจอการพูดคุยเรื่อง Bad Code จาก Reddit จึงนำ code ที่แย่ ๆ มาให้ดูกันหน่อย หวังว่านักพัฒนาจะไม่ทำ หรือ สร้างมันขึ้นมากันอีกนะ เริ่มต้นจาก code พื้นฐานมาก ๆ if-else หรือ switch-case เยอะ ๆ ( IF in action !! ) จากนั้นเขียน loop ซ้อน ๆ กัน และการตั้งชื่อตัวแปร !! ยังไม่พอนะ !!! จะเขียน code ซับซ้อน และลึกซึ้งกันไปไหน ? หรือว่าคิดเยอะไป !! มาต่อกับ SQL Love Love !! จะซับซ้อนกันไปไหน !! ส่วนอันนี้ ฮา ตรวจสอบกันหน่อยไหม !!! และเขียนน้อยกว่านี้กันดีไหม ? หรือจะ Force array with you !! หรือว่า เขียนอะไรกัน !! หมายความว่าอย่างไร ? สุดท้ายก็โดนทิ้งไว้กลางทาง !! ดังนั้นแนะนำให้นักพัฒนาทุกคน ลด ละ เลิก คิด วิเคราะห์ แยกแยะ กันด้วยนะครับ ทางที่ดีกว่าคือ เมื่อเรารู้แล้วว่า อะไรบ้างที่ไม่ดี ดังนั้นก็อย่าทำ และทำการปรับปรุงใหม่ดีขึ้นอย่างต่อเนื่องครับ มิเช่นนั้นมันจะเป็นภาระต่อทั้งตัวเราเอง ผู้อื่น และคนที่เกี่ยวข้อง !!

---

สรุปการติดตั้ง Local composer repository ด้วย Satis

May 14, 2016, 2:42 am

≫ Next: เรียนรู้การเขียนโปรแกรมด้วยเกมส์กันดีกว่า !!

≪ Previous: สรุป Bad Code แบบขำ ๆ กันหน่อย !!

$

0

0

ปัจจุบันการพัฒนาระบบงานด้วยภาษา PHP น่าจะใช้งาน Composer สำหรับจัดการเรื่อง library หรือ dependency ต่าง ๆ

ปัญหาหลักของ composer คือ ความช้า

เนื่องจาก composer จะทำการ download สิ่งต่าง ๆ มาจาก Packagist :: The PHP Package Repository  ดังนั้นสิ่งที่เราต้องการคือ ปรับปรุงให้เร็วขึ้น ด้วยการติดตั้ง Repository repository เองไปเลย โดยสิ่งที่เราจะใช้งานสำหรับสร้าง Composer repository คือ Satis มาเริ่มกันดีกว่า

ก่อนอื่นมาดูโครงสร้างการทำงานปกติของ Composer

แสดงดังรูป จากนั้นทำการติดตั้ง Satis repository  เพื่อทำการเก็บข้อมูลของ library และ dependency ต่าง ๆ ไว้ ทำให้ไม่ต้องเสียเวลาไปดึงข้อมูลมาจาก Packagist ทำให้ทำงานได้รวดเร็วขึ้น แสดงการทำงานดังรูป หรือถ้าวาดเป็นขั้นตอนการทำงานแสดงดังนี้

ทำการติดตั้งดีกว่า

เริ่มจากติดตั้ง Satis ด้วยคำสั่ง [code] $composer create-project composer/satis --stability=dev --keep-vcs [/code] จากนั้นสร้าง configuration ของ Satis เพื่อกำหนดค่าต่าง ๆ ของ repository เช่น

• ชื่อและ url ของ repository
• รายชื่อของ library ต่าง ๆ ที่ต้องการเก็บไว้ใน local repository

โดยสร้างไฟล์ชื่อว่า satis.conf ดังนี้ [gist id="e7ccef9cde07bdcc93b99853c57c8493" file="satis.conf"]

ทำการสร้าง repository ของ Satis ชื่อว่า packages-mirror

ด้วยคำสั่ง [code] php ./satis/bin/satis build satis.conf packages-mirror [/code]

ทำการ Start Satis ขึ้นมาด้วย PHP Build-in server

ด้วยคำสั่ง [code] php ./satis/bin/satis build satis.conf packages-mirror [/code] ทดสอบเข้าใช้งานผ่าน http://localhost:4680/ แสดงผลดังรูป

นำ Local composer repository มาใช้งานกันได้แล้ว

ให้ทำการแก้ไขไฟล์ composer.json ด้วยการเพิ่ม url ของ repository เข้าไป ดังนี้ [gist id="e7ccef9cde07bdcc93b99853c57c8493" file="composer.json"] ทดสอบด้วยติดตั้ง library ผ่าน composer ซะ [code] $composer install [/code] แนะนำให้ลองปิด internet นะครับ จะพบว่า composer จะทำงานได้รวดเร็วมาก ๆ เพียงเท่านี้ก็สามารถติดตั้ง Local composer repository ไว้ใช้งานได้แล้ว Reference Websites https://getcomposer.org/doc/articles/handling-private-packages-with-satis.md http://labs.qandidate.com/blog/2013/12/05/using-satis-for-fast-and-reliable-software-deployment/ http://blog.servergrove.com/2015/04/29/satis-building-composer-repository/ http://code.tutsplus.com/tutorials/setting-up-a-local-mirror-for-composer-packages-with-satis--net-36726 https://laravelista.com/satis-composer-repository-for-your-private-packages/

เรียนรู้การเขียนโปรแกรมด้วยเกมส์กันดีกว่า !!

May 18, 2016, 7:46 am

≫ Next: ชุดการทดสอบแบบ End-to-End ของ WordPress.com

≪ Previous: สรุปการติดตั้ง Local composer repository ด้วย Satis

$

0

0

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

• การเรียนรู้มันต้องไม่น่าเบื่อ
• การเรียนรู้มันต้องน่าสนใจ
• การเรียนรู้มันต้องไม่ยากเกินไป
• การเรียนรู้ต้องเป็นแบบ step-by-step
• การเรียนรู้ต้องมีความท้าทาย

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

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

• Go koans
• Python koans
• Ruby koans
• Kotlin koans
• Reactjs koans
• Elixir koans

สามารถดูเพิ่มเติมได้ที่นี่ List of koans

แต่ในปัจจุบันก็มีแนวคิดใหม่ ๆ ออกมา ซึ่งคล้ายกับ Gamification

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

ระบบที่ขอแนะนำคือ Coding Game

ซึ่งมีเกมส์เล็ก ๆ ให้เล่น เช่น Batman และ Terminator แทนที่จะเล่นเกมส์ผ่าน mouse หรือ keyboard เปลี่ยนเป็นการเขียน code แทน !! รวมทั้งมีชุดของการทดสอบแบบอัตโนมัติให้อีกด้วย ผู้เล่นสามารถเลือกภาษาโปรแกรมที่ต้องการจะเรียนรู้ได้อีกด้วย ซึ่งมีเยอะมาก ๆ เช่น C, C++, C#, Java, Python, Ruby, Go และ Swift เป็นต้น ยังไม่พอนะ ยังมีส่วนอื่น ๆ อีก เช่น

• Optimization คือการปรับปรุงวิธีการแก้ไขปัญหา ให้ทำงานได้ดีขึ้นกว่าเดิม
• Code Golf คือ การเขียน code ที่สั้นที่สุด สำหรับการแก้ไขปัญหาหนึ่ง ๆ
• Community Puzzles คือส่วนของปัญหาต่าง ๆ จากทาง community นั่นเอง

รวมไปถึง Leaderboard และ ranking ต่าง ๆ และด่านต่าง ๆ รอให้เราเข้าไปจัดการ !! แสดงดังรูป ตัวอย่างของหน้าจอของเกมส์เมื่อเราผ่านด่านนั้น ๆ

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

ชุดการทดสอบแบบ End-to-End ของ WordPress.com

May 19, 2016, 11:29 pm

≫ Next: มาเริ่มใช้งาน Jenkins 2 กับ Docker กันดีกว่า

≪ Previous: เรียนรู้การเขียนโปรแกรมด้วยเกมส์กันดีกว่า !!

$

0

0

ทีมพัฒนาระบบ Wordpress.com ได้เปิดเผย ชุดการทดสอบแบบ End-to-End สำหรับ Calypso project ออกมา เป็นส่วน Front-end ใหม่นั่นเอง โดยชุดการทดสอบพัฒนาด้วยภาษา JavaScript ทั้งหมด จำนวน 786 test cases ใช้เวลาทดสอบ 1 ชั่วโมง !!

โดยที่ CEO ของบริษัท Automattic เขียนอธิบาย

สำหรับการเปิดเผยชุดการทดสอบใน Issue ของ Github ไว้ว่า Default to Open

The quality of our code and our product depend on the amount of feedback we get and on the amount of people who use them. If we’re developing behind closed doors, we are putting artificial limits to both. We have done our best work in the open, let’s continue working this way.

มาดู Library หรือ Dependency ที่ใช้สำหรับสร้างชุดการทดสอบ [gist id="24b65a01cdd36cb4249d3378ebaf4988" file="package.json"] และตัวอย่างของชุดการทดสอบของการ login [gist id="24b65a01cdd36cb4249d3378ebaf4988" file="login-spec.js"]

การพัฒนาชุดการทดสอบ

พัฒนาด้วยภาษา JavaScript ซึ่งมีรูปแบบตาม ES2015 บน NodeJS ทำการทดสอบผ่าน brower ด้วย Selenium Web Driver ส่วน specification ของการทดสอบใช้ Mocha และทำการทดสอบอยู่บนระบบ CircleCI ทำการทดสอบ Responsive website ด้วย โดยทำการทดสอบหน้าจอที่แตกต่างกัน 3 แบบ ส่วนผลการทดสอบจะส่งมายัง Slack พร้อม screenshot หน้าจอของการทดสอบกลับมาอีกด้วย

ของดี ๆ แบบนี้นักพัฒนาต้องไม่พลาด ที่จะนำมาศึกษา และ ใช้งานต่อไป

ปล. ผลการทดสอบของ project ยัง Fail อยู่นะ !! แต่ในขณะเขียน blog อยู่นี้มีกำลังทดสอบกันอยู่ สามารถดูได้ที่ Circle CI Reference Website https://developer.wordpress.com/2016/05/12/automated-e2e-tests/

มาเริ่มใช้งาน Jenkins 2 กับ Docker กันดีกว่า

May 20, 2016, 9:51 pm

≫ Next: [Mac OS X] Other storage มันคืออะไร และ จะลบอย่างไร ?

≪ Previous: ชุดการทดสอบแบบ End-to-End ของ WordPress.com

$

0

0

หลังจากที่แนะนำ Jenkins 2 ไปแล้วใน blog::สวัสดี Jenkins 2 ซึ่งมี feature ใหม่ที่น่าสนใจเช่น

• Pipeline-as-code
• ปรับปรุงเรื่อง User Interface
• ปรับปรุงเรื่องความปลอดภัย
• ปรับปรุงเรื่องของระบบ plugin
• ปรับปรุง website หลักให้ดูดี และ มีข้อมูลต่าง ๆ ครบเครื่อง

ดังนั้นแทนที่จะติดตั้งแบบเดิม ๆ เราลองทำการติดตั้งด้วย Docker กันดีกว่า ซึ่งมันทำให้การติดตั้ง configuration และการ update ง่ายขึ้นมาก ๆ แต่ก็ต้องแลกมาด้วยการเรียนรู้ ศึกษา และลงมือทำจริง ๆ มาเริ่มกันเลย

ปล. ตอนนี้ Jenkins 2.5 แล้วนะ ทีมพัฒนาทำการ update เป็นรายสัปดาห์กันเลย ขยันกันมาก ๆ

ขั้นตอนที่ 1 ใช้งาน Docker image ชื่อว่า jenkinsci/jenkins ใช้ tag latest

ดังนั้นทำการ pull หรือ download image ลงมาที่เครื่องของเราก่อน [code] $docker pull jenkinsci/jenkins:latest [/code]

ขั้นตอนที่ 2 ทำการสร้าง image และ container ที่ต้องการ

โดยต้องการให้มี 2 ตัวคือ

• ตัวที่ 1 คือ Jenkins server หลัก หรือ Jenkins master
• ตัวที่ 2 คือ เก็บข้อมูลต่าง ๆ ของ Jenkins เช่น job และ plugin เพื่อไม่ให้ไปผูกติดกับ Jenkins master เรียกว่า Jenkins Data

ดังนั้นเมื่อเราทำการลบ และ สร้าง container ของ Jenkins master ขึ้นมาใหม่ ก็ยังสามารถใช้งานค่า configuration จาก Jenkins data ได้ ถือว่าเป็นอีกหนึ่งแนวทางในการจัดการ เริ่มด้วยการสร้าง image กันก่อน [code] docker build -t jenkins-data -f data/Dockerfile . docker build -t jenkins2 -f master/Dockerfile . [/code] โดยที่ Dockerfile ของ Jenkins master และ Jenkins data อยู่ที่ Github จากนั้นทำการสร้าง container จาก image ที่สร้างไว้ก่อนหน้า โดย Jenkins master จะต้องทำการกำหนด volume ไปยัง Jenkins data ด้วย [code] $docker run --name=jenkins-data jenkins-data $docker run -p 8080:8080 -p 50000:50000 --name=jenkins-master --volumes-from=jenkins-data -d jenkins2 [/code] เมื่อสร้าง container เสร็จแล้ว ตรวจสอบด้วยคำสั่ง [code] $docker ps -a [/code] แสดงผลการทำงานดังนี้ [gist id="220bdc6ca4a1c8262a7f01179cf48bf6" file="list-container.txt"] โดยสามารถตรวจสอบการทำงานผ่าน browser ด้วย URL = http://localhost:8080 (ผมใช้ Docker for Mac นะ) จะแสดงดังรูป

ขั้นตอนที่ 3 ทำการ configuration ค่าต่าง ๆ ของ Jenkins 2

เริ่มการดึงค่าของ Administrator password ก่อนเลย ด้วยคำสั่ง [code] $docker exec jenkins-master cat /var/jenkins_home/secrets/initialAdminPassword [/code] ทำการติดตั้ง Plugin และ สร้าง Job ที่ต้องการกันได้เลย ซึ่งผมเลือกการติดตั้ง plugin ตามที่ Jenkins 2 แนะนำเลย จากนั้นให้สร้าง user สำหรับจัดการ Jenkins จากนั้นก็มาเริ่มใช้งานกันเลย แสดงดังรูป จากนั้นสร้าง Item ซึ่งผมเลือกสร้าง Pipeline-as-code ขึ้นมา (เป็น plugin ใหม่ของ Jenkins 2) ชื่อว่า My-pipeline แสดงดังรูป เมื่อสร้างเสร็จแล้วก็ทดสอบ run สิ รออะไร แสดงดังรูป เมื่อทุกอย่างเรียบร้อย ให้ลอง stop, ลบ และสร้าง container ของ Jenkins-master จะพบว่าข้อมูลต่าง ๆ ทั้ง plugin และ job ยังคงอยู่ และสามารถใช้งานได้เหมือนเดิม ไม่ต้องมาสร้างใหม่ ซึ่งถ้าเข้ามาที่ Jenkins server จะต้องใส่ username และ password ด้วยนะ

แต่อย่าไปลบ container ชื่อว่า jenkins-data นะ !!

สุดท้ายแล้ว เราก็สามารถเริ่มสร้างระบบ Continuous Integration ด้วย Jenkins อย่างง่ายได้

ต่อไปจะอธิบายการสร้าง Pipeline-as-code เพื่อทำงานร่วมกับ Version Control เช่น git รวมทั้งการสร้าง Jenkins slave และการจัดการผ่าน Docker compose ยังไม่อะไรให้เราเรียนรู้อีกเยอะ !! Reference Websites https://dzone.com/articles/get-started-with-jenkins-20-with-docker http://engineering.riotgames.com/news/putting-jenkins-docker-container https://www.future-processing.pl/blog/building-and-deployment-multi-branch-web-application/ http://www.focusedsupport.com/blog/beyond-builds-combining-jenkins-and-docker-for-continuously-running-instances/ https://www.cloudbees.com/blog/get-ripped-jenkins-docker-industrial-strength-continuous-delivery http://making.meetup.com/post/122890386432/steps-towards-automated-testing-with-docker-and

[Mac OS X] Other storage มันคืออะไร และ จะลบอย่างไร ?

May 22, 2016, 2:50 am

≫ Next: สรุปสิ่งที่แบ่งปันในงาน Test Automation Meetup #1

≪ Previous: มาเริ่มใช้งาน Jenkins 2 กับ Docker กันดีกว่า

$

0

0

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

• Other storage มันคืออะไร ?
• มันประกอบไปด้วยไฟล์อะไรบ้าง ?
• แล้วเราจะทำการลบได้อย่างไร เพื่อจะได้พื้นที่กลับคืนมา ?

แสดงดังรูป (ซื้อ stoage มาเพิ่มไว้ก่อน 64 GB)

Other storage มันมีไฟล์อะไรบ้าง ?

ก่อนจะทำการลบต้องรู้ก่อนว่า Other storage มันมีอะไรบ้าง หลัก ๆ น่าจะมีไฟล์ดังต่อไปนี้

• ไฟล์เอกสารทั่วไป เช่น PDF, Doc, และ PSD เป็นต้น
• ไฟล์ที่ทำการบีบอัด หรือ compression เช่น Zip, Tar, Gz, dmg และ iso เป็นต้น
• พวกไฟล์ temporary ต่าง ๆ ของ Mac OS รวมไปถึง swap ด้วย
• พวกข้อมูล caching ต่าง ๆ เช่น browser caching, local storage เป็นต้น
• พวก Font, plugin ต่าง ๆ ของ application รวมไปถึง extension ต่าง ๆ

ส่วนใหญ่มันคือกลุ่มของไฟล์แปลก ๆ นั่นเอง

จะทำการลบไฟล์ต่าง ๆ เหล่านี้อย่างไรดีล่ะ ?

• ทำการ restart เครื่องดูสิ
• อย่าลืมลบข้อมูลในถังขยะนะ !!
• Application อะไรที่ไม่ค่อยได้ใช้ก็ลบไปซะ
• ลบพวกไฟล์ temporary ต่าง ๆ ออกไปซะ เช่น CCleaner for Mac แต่ระวังนิดนึงแบบว่ามันหายหมดเลยนะ !!
• ลบพวกไฟล์ต่าง ๆ ของ browser ซึ่งได้พื้นที่กลับมามหาศาลอย่างมาก ๆๆๆ
• ลบชุดของภาษาที่เราไม่ได้ใช้ เนื่องจาก Mac OS มันมีหลายภาษามาก ๆ
• ตามไปลบไฟล์ต่าง ๆ จากข้างต้น
• ปิด Swap memory ด้วยนะครับ

ทำเพียงเท่านี้ก็ได้พื้นที่ว่างกลับมาคืนประมาณ 40 GB แบบชิว ๆ ถ้าอยากได้เพิ่มก็ลบเพิ่มกันต่อไป

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

Reference Websites http://www.igeeksblog.com/what-is-other-on-mac-how-to-remove/ http://osxdaily.com/2015/01/15/other-storage-space-mac-os-x/

สรุปสิ่งที่แบ่งปันในงาน Test Automation Meetup #1

May 23, 2016, 9:54 am

≫ Next: [Android] มาดูวิธีการลดขนาดของไฟล์ APK ของ Yelp กัน

≪ Previous: [Mac OS X] Other storage มันคืออะไร และ จะลบอย่างไร ?

$

0

0

วันนี้มีโอกาสไปแบ่งปันเรื่อง Automated testing for Android app ในงาน Test Automation Meetup ครั้งที่ 1 โดยเน้นไปที่แนวคิดสำหรับการทดสอบ Android app ซึ่งในปัจจุบันมีเครื่องมือ และ library ต่าง ๆ เยอะมากมาย หนึ่งในนั้นคือ Android Testing Support Library (ATSL) ประกอบไปด้วย

• UI Automator
• Espresso
• AndroidJUnitRunner
• JUnit 4

แนวคิดหลัก ๆ ในการทดสอบระบบงาน

เพียงตอบ 2 คำถามให้ได้ว่า

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

ถ้าคุณไม่มั่นใจ แสดงว่าต้องหาวิธีการที่เหมาะสม เพื่อทำให้คุณมั่นใจในคำตอบมากยิ่งขึ้น หัวใจคือ Fast feedback นั่นเอง

เครื่องมือ และ Library ที่แนะนำ ประกอบไปด้วย

• Espresso
• Screengrab สำหรับ capture หน้าจอการทำงานของ Android app ซึ่งทำงานร่วมกับ Espresso ซึ่งผมเคยเขียนการใช้งานเบื้องต้นไว้ที่ blog นี้
• Monkey testing สำหรับการทำ Stress testing โดยจะสร้าง event ต่าง ๆ ขึ้นมาแบบอัตโนมัติ

สิ่งที่เน้นมาก ๆ คือ Espresso เป็น Library ที่สร้างจากทีมพัฒนาของ Google นั่นเอง สร้างมาจาก developer เพื่อ developer ทำให้เราสามารถทำ UI Testing ได้ง่ายและสะดวกขึ้นมา แต่ก็มีข้อจำกัดพอสมควรเหมือนกัน โดยที่ UI Testing ใช้สำหรับทดสอบว่า Android app ที่เราพัฒนาขึ้นมานั้น สามารถติดตั้งบน device หรือ emulator ได้ สามารถทำงานได้จริง มิใช่เพียงแค่สวย ดูดีอย่างเดียว

Espresso นั้นประกอบไปด้วย component หลัก 3 ตัวคือ

1. View Matcher สำหรับค้นหา element ต่าง ๆ จาก view
2. View Action สำหรับจำลองการทำงานต่าง ๆ เช่น การกดปุ่ม การกรอกข้อมูล เป็นต้น
3. View Assertion สำหรับการตรวจสอบผลการทำงาน ว่าเป็นไปตามที่คาดหวังหรือไม่

Slide อยู่ที่นี่ http://www.slideshare.net/up1/automation-test-for-android

โดยทั้งหมดนี้เป็นเพียงจุดเริ่มต้น

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

ก้าวแรกสำคัญเสมอครับ จากนั้นก็ก้าวต่อไปเท่านั้นเอง

 

[Android] มาดูวิธีการลดขนาดของไฟล์ APK ของ Yelp กัน

May 24, 2016, 3:04 am

≫ Next: [PHP] เรียนรู้การพัฒนา Web Application ด้วย Laravel framework ตามแนวคิด Test Driven

≪ Previous: สรุปสิ่งที่แบ่งปันในงาน Test Automation Meetup #1

$

0

0

จากบทความเรื่อง Yelp Android App Went On A Diet ซึ่งทีมพัฒนา Android app ของ Yelp ทำการอธิบาย วิธีการลดขนาดของไฟล์ APK (Android Application Package) มันมีความสำคัญมาก ๆ สำหรับ Android developer ทุกคน จึงทำการแปลและสรุปไว้อ่านนิดหน่อย

คำถามที่น่าสนใจคือ เราใส่ใจเรื่องนี้มากน้อยกันเพียงใด ?

ในการพัฒนา Mobile app นั้น มีหลายสิ่งอย่างที่ต้องใส่ใจ

เช่น battery, network, storage เป็นต้น ซึ่งสิ่งต่าง ๆ เหล่านี้มันคือ การใส่ใจเรื่อง resource ของผู้ใช้งานนั่นเอง หนึ่งในเรื่องที่สำคัญคือ ขนาดของไฟล์ APK ลองคิดดูสิว่า ถ้าไฟล์ APK มีขนาดใหญ่ต้องใช้เวลาในการ download นาน ยิ่งถ้าความเร็วของระบบ network ที่ใช้งานช้าอีกล่ะ ไหนจะเป็นเรื่องขนาดของ storage บนเครื่องผู้ใช้งานอีก ดังนั้นมาดูกันว่าทางทีมพัฒนาของ Yelp ทำอย่างไรกันบ้าง ?

อย่างแรกมีระบบแจ้งเกี่ยวกับขนาดของไฟล์ APK ที่ release ออกมาตลอด

ซึ่งทำให้เห็นว่าแนวโน้มของขนาดไฟล์เป็นอย่างไร แสดงดังรูป คำอธิบาย ยิ่งทำการเพิ่ม feature ใหม่ ๆ เข้าในใน App ขนาดของไฟล์ APK ก็ใหญ่ขึ้นเท่านั้น !! แต่ถ้ามีแนวโน้มแบบนี้ต่อไป คงไม่ดีอย่างแน่นอน

ดังนั้นสิ่งที่ต้องเข้าใจต่อไปก็คือ ไฟล์ APK มันประกอบไปด้วยไฟล์อะไรบ้าง ?

เป็นการลงไปในรายละเอียด เพื่อค้นหาว่าปัญหามาจากส่วนไหนบ้าง แต่ก่อนอื่นทำการบีบอัดไฟล์ต่าง ๆ ในกระบวนการสร้างไฟล์ APK ด้วยเครื่องมือ ZipAlign แสดงดังรูป จากภาพจะเห็นได้ว่า ส่วนที่มีจำนวนเยอะมาก ๆ ก็คือ Image หรือ รูปภาพที่ใช้ใน App  เมื่อทีมพัฒนาเข้าไปดูพบว่า รูปต่าง ๆ ไม่ได้ทำการบีบอัดเลย !! โดยใน Android 4.2.1 นั้นสนับสนุนรูปแบบรูปภาพใหม่คือ WebP ซึ่งอ้างว่าเข้ารหัสได้ดีกว่า PNG และ JPEG ที่สำคัญคือ มีขนาดที่เล็กกว่าแถมคุณภาพไม่ได้ต่างกันมาก

ดังนั้นจึงทำการบีดอัดรูปภาพจำนวน 2,000 รูปจาก PNG ไปเป็น WebP

ผลที่ได้ไม่ได้ลดมากตามที่คาดหวัง !! คือมีขนาดลดจาก 27.1 MB เหลือ 23.1 MB โดยไม่สูญเสียคุณภาพ แสดงดังรูป ยังไม่พอนะ สิ่งที่ต้องตรวจสอบเพิ่มเติม คือ เมื่อเปลี่ยนเป็น WebP แล้วต้องดูประสิทธิภาพการทำงานของ App ด้วย ว่าเป็นอย่างไร ดีขึ้น หรือ แย่ลง ? ด้วยการใช้งาน Android performance tool ผลที่ได้คือ ประสิทธิภาพการทำงานไม่ได้แตกต่างกันเลย เพียงเท่านี้ก็สบายใจล่ะ ส่วนขั้นตอนการแปลงรูปภาพนั้นจะทำงานแบบอัตโนมัติ เมื่อทำการ commit หรือ เปลี่ยนแปลงรูปภาพ ซึ่งลดภาระการทำงานลงไปอย่างมาก หลังจากทำการเปลี่ยนไปเป็น WebP พบว่าขนาดของไฟล์ APK เป็นดังนี้ สิ่งที่ต้องระวังในการแปลงรูปภาพ คือ คุณภาพของรูป เนื่องจากรูปขนาดใหญ่ลดคุณภาพไม่ได้เลย มิเช่นนั้นจะกระทบต่อผู้ใช้งานอย่างมาก สามารถอ่านแบบเต็ม ๆ ได้ที่ Yelp Android App Went On A Diet สุดท้ายแล้ว Android developer ควรใส่ใจกับขนาดของไฟล์ APK กันด้วย ในบทความนี้เป็นเพียงหนึ่งวิธีการเท่านั้นนะ

---

[PHP] เรียนรู้การพัฒนา Web Application ด้วย Laravel framework ตามแนวคิด Test Driven

May 25, 2016, 7:19 pm

≫ Next: สรุปการเรียนพื้นฐานของภาษา R

≪ Previous: [Android] มาดูวิธีการลดขนาดของไฟล์ APK ของ Yelp กัน

$

0

0

ถ้าต้องการศึกษา Laravel framework ซึ่งเป็นสิ่งใหม่สำหรับผม คำถามที่น่าสนใจก็คือ จะทำการศึกษา และ เรียนรู้ ฝึกทำอย่างไรดีล่ะ ? คำตอบนั้นมีอยู่หลายแบบ แต่สำหรับผมแล้ว ขอเริ่มจากการเขียน test หรือ ชุดการทดสอบดีกว่า !! ดังนั้นมาเริ่มกันเลย ปล. ไม่พูดถึงการสร้าง project และเตรียม environment นะครับ

มีเป้าหมายหลักเพื่อ

เรียนรู้การพัฒนาระบบด้วย Laravel framework เรียนรู้โครงสร้างการทำงานพื้นฐานของ Laravel framework เช่น

• Factory
• Model ซึ่งมี ORM มาให้
• Database migration
• Routing
• Controller
• View

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

โดยสิ่งที่ต้องการคือ ขั้นตอนการสร้างบัญชีธนาคารของผู้ใช้งาน ดังนั้นการทำงานมีขั้นตอนดังนี้

• สร้างผู้ใช้งาน
• สร้างบัญชีธนาคารใหม่
• ตรวจสอบผลการสร้างบัญชีใหม่ ว่าแสดงผลหมายเลขบัญชีใหม่ถูกต้องหรือไม่

สามารถเขียนชุดการทดสอบด้วย PHPUnit ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="testcase_01.php"] ทำการทดสอบด้วยคำสั่ง [code] $./vendor/bin/phpunit [/code] ผลที่ได้แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ไม่รู้จัก User ใน Factory !!! แต่ประเด็นหลักคือ Factory ของ Model คืออะไร ? และมันอยู่ตรงไหนล่ะ ? ตอบง่าย ๆ คือ โรงงานผลิต Model ไงล่ะ ใครอยากจะจัดการข้อมูลผ่าน database ก็มาหาจากที่นี่ได้เลย เมื่อลองไปค้นหาใน project พบว่าอยู่ในไฟล์ database/factories/ModelFactory.php นั่นเอง แสดงดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="ModelFactory.php"] จาก code ดังกล่าว จะเห็นได้ว่าใน factory มี User อยู่แล้ว แต่ว่า User มันอยู่ใน namspace ชื่อว่า App ดังนั้นสิ่งที่เราควรทำคือ ในชุดการทดสอบ ให้ทำการ import หรือ use App\User สิครับ ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="testcase_02.php"] จากนั้นทำการทดสอบรอบที่สอง จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ไม่สามารถติดต่อ MySQL database ได้ไง แสดงว่า default database ของ Laravel framework คือ MySQL นั่นเอง ได้ความรู้ใหม่กันอีกแล้ว คำถามต่อมาคือ จะทำการแก้ไขอย่างไรดี ? เมื่อไปค้นหาดูพบว่าอยู่ในไฟล์ config/database.php จะพบว่ามีการ configuration ไว้ให้ 3 ตัวคือ SQLite, MySQL และ PostgreSQL ดังนั้นเพื่อความรวดเร็ว ผมจึงเปลี่ยนไปใช้ SQLite ดีกว่า ซึ่งเป็น In-memory database จะได้ไม่ต้องติดตั้ง database อะไรเพิ่มอีก ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="config_database.php"] จากนั้นทำการทดสอบรอบที่สาม จะพบว่าข้อผิดพลาดแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ไม่พบ database ใน SQLite  ทำอย่างไรดี ? ให้ทำการกำหนด environment ชื่อว่า DB_DATABASE ในไฟล์ phpunit.xml สิ กำหนดค่าเป็น :memory: ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="phpunit.xml"] จากนั้นทำการทดสอบรอบที่สี่ จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ไม่พบตาราง users ใน database แล้วเราจะสร้างตาราง users ขึ้นมาอย่างไรดี ? หลังจากที่ไปค้นหาและศึกษาพบว่า Laravel framework มี migration tool ให้ใช้งาน แบบนี้ก็สบายเลย ดังนั้นสั่งให้ทำการ migrate database ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="testcase_03.php"] คำถามคือ แล้ว Laravel framework รู้ได้อย่างไรว่าจะสร้างอะไร ? คำตอบคือ ลองไปดูในไฟล์ database/factories/ModelFactory.php และไฟล์ database/migrations/yyyy_mm_dd_create_users_table.php แล้วจะถึงบางอ้อ จากนั้นทำการทดสอบรอบที่ห้า จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ class Account ไม่มีใน Factory นั่นเอง ดังนั้นให้ทำการเพิ่มเข้าไปซะ ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="ModelFactory_02.php"] จากนั้นทำการทดสอบรอบที่หก จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ หา class Account ไม่เจอ ดังนั้นสร้างซะ แต่ถ้าจะสร้างแบบ manual มันดูไม่งามนัก เนื่องจาก Laravel framework ได้เตรียม command line ในการสร้าง model ได้ให้ ดังนั้นมาใช้กันหน่อยสิ <pre> [code] $php artisan make:model Account [/code] จากนั้นทำการทดสอบรอบที่เจ็ด จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ใน class Users ไม่มี function ชื่อว่า accounts() นั่นเอง ดังนั้นให้ทำการเพิ่มเข้าไปในสิ รออะไร อีกอย่างที่ห้ามลืมก็คือ user แต่ละคนสามารถมา back account ได้มากกว่า 1 account นะ เขียน code ได้ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="User_02.php"] จากนั้นทำการทดสอบรอบที่แปด จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ไม่มีตารางชื่อว่า accounts ใน database ดังนั้นให้ทำการสร้างตารางด้วย migration tool กันเลย ด้วยคำสั่งดังนี้ [code] $php artisan make:migration create_accounts_table --create=accounts [/code] จะทำการสร้างไฟล์ใหม่ใน folder database/migration นะครับ จากนั้นทำการทดสอบรอบที่เก้า จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ไม่มี column ชื่อว่า account_no ในตาราง accounts ด้วยการแก้ไขไฟล์ที่อยู่ใน folder database/migrations ชื่อว่า create_accounts_table.php ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="create_accounts_table_01.php"] จากนั้นทำการทดสอบรอบที่สิบ จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ไม่มี column ชื่อว่า user_id ในตาราง accounts ใช้สำหรับการอ้างอิงไปยังตาราง user นั่นเอง ดังนั้นเพิ่มสิครับ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="create_accounts_table_02.php"] จากนั้นทำการทดสอบรอบที่สิบเอ็ด จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ 404 not found คือหา url ดังกล่าวไปเจอ เห็นไหมว่า ปัญหามันวิ่งไปในส่วนของ View แล้วนะ ก็แน่ล่ะ เพราะว่า เรายังไม่สร้างส่วนการแสดงผล และ url ดังกล่าวก็ยังไม่สร้าง !! คำถามที่น่าสนใจคือ จะสร้างอย่างไรดีล่ะ ? เมื่อไปอ่านเอกสารของ Laravel framework ก็พบว่า ก่อนอื่นให้ทำการสร้าง Routing ของ url ที่เราต้องการขึ้นมาก่อน รวมทั้งต้องระบุไปด้วยว่า จะจับคู่กับ class Controller อะไร และ function อะไร และทำงานผ่าน HTTP GET ด้วย โดยทำการเพิ่มในไฟล์ app/HTTP/route.php ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="route.php"] จากนั้นทำการทดสอบรอบที่สิบสอง จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ถ้าสังเกตจะเห็นว่า class UsersController ไม่มีนั่นเอง ดังนั้นให้ทำการสร้างผ่าน command line อีกแล้ว ดังนี้ [code] $php artisan make:controller UsersController [/code] จากนั้นทำการทดสอบรอบที่สิบสาม จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ใน class UsersController ไม่มี function ชื่อว่า show() ดังนั้นให้ทำการเพิ่มดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="UsersController.php"] จากนั้นทำการทดสอบรอบที่สิบสี่ จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ผลการแสดงผลไม่ตรงตามที่ต้องการ ดังนั้น สิ่งที่ต้องทำต่อไปคือ การสร้างส่วนของ view หรือ การแสดงผล โดยต้องทำการดึงข้อมูลผู้ใช้งานจากตาราง User เพื่อส่งไปแสดงผลใน view ต่อไป ซึ่งต้องไปเปิดเอกสารของ Laravel framework ทำต่อไป ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="UsersController_02.php"] จากนั้นทำการทดสอบรอบที่สิบห้า จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ เห็นไหมว่า Laravel framework หา view ไม่เจอ ดังนั้นทำการสร้าง folder ชื่อง users ใน resources/views โดย view นั้นจะใช้ Blade template ทำการสร้างไฟล์ชื่อ show.blade.php ขึ้นมาดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="show.blade.php"] จากนั้นทำการทดสอบรอบที่สิบหก ผลที่ได้คือ ผ่านแล้ววววววววว แสดงดังรูป

มาถึงตรงนี้ สิ่งที่ต้องถามตัวเราเองก็คือ เราได้เรียนรู้อะไรเกี่ยวกับ Laravel framework กันบ้าง ?

แต่ยังไม่จบนะ ลองกลับไปดู code ใน UsersController ดูสิ มันแย่นะ !! นั่นคือบรรทัดนี้ [code] $user = User::where('name', $name)->first(); [/code] มันอ่านไม่ค่อยรู้เรื่องนะ !! รวมทั้งมันใช่หน้าที่ของ controller ที่ต้องมาทำแบบนี้หรือ ? น่าจะต้องย้ายไปอยู่ใน class User หรือ model นะ ดังนั้นเราจึงเข้าสู่การ refactor code สังเกตไหมว่า จะทำการ refactoring code เมื่อชุดการทดสอบผ่านหมดแล้วเท่านั้น

เริ่มต้นการ Refactor code กันเถอะ

[gist id="6148dee2f9b64255a9d49575e0c1f612" file="UsersController_03.php"] แน่นอนว่าถ้า run ต้องเกิด error อย่างแน่นอน เนื่องจากเรายังไม่เคยมี function findByName() ใน class User เลย ดังนั้นมาเพิ่ม function นี้กันเถอะ

แต่ช้าก่อน !! หยุดคิดหน่อยสิว่า เราพลาดอะไรไป ?

คำตอบคือ เรามาเขียน unit test สำหรับ class User กันดีกว่า เพื่อทำให้มั่นใจว่า สิ่งที่เรากำลังจะสร้างมันถูกต้องตามที่คาดหวัง โดยสร้าง unit test ชื่อว่า UserTest.php ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="UserTest.php"] จากนั้นทำการทดสอบรอบที่สิบเจ็ด ทำการทดสอบเฉพาะ class UserTest.php เท่านั้น [code] $./vendor/bin/phpunit tests/unit/UserTest.php [/code] จะพบว่าข้อผิดพลาดมันแตกต่างออกไป แสดงดังรูป

คำถามคือ ปัญหาของข้อผิดพลาดนี้คืออะไร ?

คำตอบคือ ไม่เจอ function findByName() ใน class User ดังนั้นสร้างสิครับ ดังนี้ [gist id="6148dee2f9b64255a9d49575e0c1f612" file="User.php"] จากนั้นทำการทดสอบรอบที่สิบแปด ทำการทดสอบเฉพาะ class UserTest.php เท่านั้น ผลที่ได้คือ ผ่านอีกแล้วววววว

เมื่อทุกอย่างพร้อมแล้ว เราก็ทำการทดสอบทั้งหมดอีกครั้งสิ

มันคือ Regression testing นั่นเอง ซึ่งเรามีทั้งหมด 2 test case คือ Acceptance test และ Unit test ได้ผลการทดสอบดังนี้

สำหรับใครที่เดินทางมาถึงตรงนี้ คิดอย่างไรกับวิธีการเรียนรู้ Laravel framework แบบนี้บ้าง ?

โดยรวมแล้วโครงสร้างของ Laravel framework มันก็เป็นประมาณนี้ สำหรับ code ตัวอย่างทั้งหมดอยู่ที่ Github::Laravel with TDD Reference Websites http://adamwathan.me/2016/01/11/test-driven-laravel-from-scratch/ https://vimeo.com/152727171?from=outro-embed

สรุปการเรียนพื้นฐานของภาษา R

May 27, 2016, 4:44 am

≫ Next: ความสามารถที่น่าสนใจใน Apache JMeter 3.0

≪ Previous: [PHP] เรียนรู้การพัฒนา Web Application ด้วย Laravel framework ตามแนวคิด Test Driven

$

0

0

วันนี้มาเรียนพื้นฐานของภาษา R ชื่อ course ว่า R programming for (young) Data Scientist เป็นหนึ่งใน course ที่อยู่ในงาน Predictive Analytic and Data Science conference ถือได้ว่า เป็นการเรียนรู้ภาษาใหม่ ๆ อีกครั้งหนึ่ง โดยเนื้อหาต่าง ๆ ใน course นี้จะเป็นฉบับพื้นฐาน แต่ก็ทำให้รู้ และ เข้าใจว่าต้องศึกษาเพิ่มเติมและนำไปใช้อย่างไรบ้าง

เครื่องมือที่ใช้งานประกอบไปด้วย

• R language สามารถ download ได้จาก CRAN repository
• R Studio เป็น IDE สำหรับเขียนโปรแกรมด้วยภาษา R

หรือถ้าไม่อยากใช้งาน IDE ก็สามารถใช้งานผ่าน R Interactive ก็ได้ คือเข้าไปที่ command line แล้วพิมพ์ R จะเข้าสู่ mode ของ R interactive แต่ใช้ R Studio ชีวิตจะง่ายกว่านะ มาเริ่มเขียน code กันเลย

พื้นฐานมันสำคัญมาก ๆ

เริ่มจากการประกาศตัวแปร การ assign ค่าลงในตัวแปร ซึ่งสามารถทำได้ 2 แบบคือ [code] a = 2 2 -> a [/code] ถ้าต้องการให้แสดงผลลัพธ์จากการทำงานตลอด โดยไม่ต้อง print ค่าออกมาดูเอง ให้ทำการเขียนดังนี้ [code] (a = 2) (2 -> a) [/code]

จากนั้นทำการกำหนด Working directory

ซึ่งทำได้หลายแบบ แต่ถ้าไม่อยากผูกติดกับเครื่องมือ ก็ใช้คำสั่ง [code] getwd() setwd('<your working directory>') [/code] ผู้สอนแนะนำให้ศึกษาแต่ละคำสั่งหรือ function จาก help() ซึ่งมันมีความสำคัญอย่างมาก และ มันอยู่ใกล้เรามาก ๆ เช่น ถ้าต้องการอยากรู้ว่า setwd คืออะไร และ ใช้งานอย่างไร ? สามารถพิมพ์ว่า help(setwd) เพื่อดูรายละเอียดได้เลย เป็นสิ่งที่นักพัฒนาต้องไม่พลาด !!

ต่อมาแนะนำให้ลองดู demo project หรือ code ที่มากับ R

ซึ่งมีประโยชน์อย่างมากต่อผู้เริ่มต้นศึกษา เพราะว่า ตัวอย่างมีทั้ง code และแสดงผลการทำงานให้เห็นเลย สามารถดู demo ด้วยคำสั่ง [code] demo() #ดูว่ามี demo เรื่องอะไรบ้าง demo(graphics) #ดู demo ของ package graphics [/code] ผลการทำงานจาก demo

จากนั้นเข้าเรื่องของ Data type หรือชนิดของข้อมูล

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

• Scala
• Vector
• Matrix
• Data frame
• List

โดยในแต่ละ Data type สามารถใช้งาน function พื้นฐานต่าง ๆ ได้อีก ประกอบไปด้วย

• Mean
• Max
• Min
• Average
• Sum
• Exp
• Log
• Sqrt

และอื่น ๆ อีกมากมายรวมทั้ง operator ต่าง ๆ เช่น +, -, *, / และ ^ เป็นต้น

ยกตัวอย่างการใช้งาน Vector

เริ่มจากการสร้าง Vector [code] vector1 = c(1, 2, 3 ,4 ,5) vector2 = c(1:5) vector3 = seq(from=1, to=5, by=1) random_vector = rnorm(5) empty_vector = c() [/code] สิ่งที่น่าสนใจคือ c มันคืออะไร ? แนะนำให้ใช้ help(c) จะพบว่า c มันคือ Combine values into Vector or List พร้อมยกตัวอย่างการใช้งาน เห็นไหมว่า help มันช่วยเหลือเราได้มากเลยนะ

ยกตัวอย่างการใช้งาน Matrix

เป็นชนิดข้อข้อมูลอีกแบบที่ถูกใช้งานเยอะ เราสามารถสร้างได้ดังนี้ [code] vector1 = c(1, 2, 3 ,4 ,5, 6) matrix1 = matrix( vector1, nrow=3 ) #กำหนดให้มี 3 row matrix2 = matrix( vector1, ncol=2 ) #กำหนดให้มี 2 column [/code] สามารถนำ matrix มาบวก ลบ คูณหารกันได้ รวมไปถึงการหา invert matrix และ Diagonal matrix ได้แบบสบาย ๆ ถึงตรงนี้ต้องไปเปิดตำราเรียนกันใหม่เลยทีเดียว !!

แต่สิ่งที่มีประโยชน์ และ ใช้งานมาก ๆ คือ Data frame

มันคือข้อมูลที่เราสามารถกำหนดชื่อ column ของข้อมูลได้ และเราสามารถดึงข้อมูลมาใช้งานง่าย ๆ มาก ทำการสร้าง Data frame โดยสร้างจาก vector นั่นเอง ดังนี้ ทำการสร้างข้อมูล 3 column ขึ้นมา คือ a, b, c [code] x = c(1,2,3) y = c(10,20, 30) z = c(100,200,300) t = data.frame(a=x, b=y, c=z) [/code] จากนั้นถ้าต้องการดึงข้อมูลในแต่ละ column มาใช้งาน สามารถทำได้ดังนี้ [code] t$a t[['a']] t[, 'a' ] t[, c('b', 'a')] #ดึงหลาย ๆ column [/code]

มาทำ workshop เรื่อง Data frame กันนิดหน่อย

โดยให้ทำการ random ข้อมูลขึ้นมา 3 ชุด จากนั้นทำการสร้าง Data frame และ แสดงผลในรูปแบบ graph ด้วย plot สามารถเขียน code ได้ดังนี้ [code] x1 = rnorm(100) x2 = rnorm(100) x3 = rnorm(100) t3 = data.frame(a=x1, b=x1+x2, c=x1+x2+x3) t3 plot(t3) [/code] แสดงผลการทำงานดังนี้

จากนั้นก็ทำการเรียนเกี่ยวกับเรื่องการวาด graph เพิ่มเติม

เช่น

• plot
• line
• points

ซึ่งทางผู้สอนแนะนำให้ใช้งาน ggplot2 package เนื่องจากมันแจ่มมาก ๆ สามารถ Download เอกสารการใช้งานได้จาก ggplot2 cheatsheet

มาถึง Package ที่แจ่มมาก ๆ คือ dplyr

ใช้สำหรับการจัดการข้อมูล ก่อนนำไปวิเคราะห์ต่อไปนั่นเอง ซึ่งเราต้องติดตั้งเพิ่มเติม ด้วยคำสั่ง [code] install.packages("dplyr") [/code] ส่วนการใช้งานขั้นพื้นฐานก็มีหลายอย่างเช่น

• การแสดงข้อมูลในรูปแบบต่าง ๆ เช่นแบบตารางใน console หรือ ใน R Studio
• การกรองข้อมูล ซึ่งในส่วนนี้สนุกมาก ๆ นำเอาหลักการของ data pipeline มาใช้
• การลบข้อมูลที่ซ้ำซ้อนออกไป
• การดึงเฉพาะข้อมูลที่ต้องการมาใช้งาน หรือ การ slice data
• ถ้าต้องการดูเพิ่มเติมไปที่ help ได้เลย

โดยรวมแล้วข้อมูลมันอยู่ในรูปแบบของ Data frame นั่นเอง

มาดูตัวอย่างจากการทำ workshop แบบ step-by-step

โดยใช้ข้อมูลตัวอย่างชื่อว่า iris flower dataset ถ้าลอง plot ออกมาเป็นดังนี้ หรือแสดงข้อมูลในรูปแบบอื่น ๆ ได้เช่น [code] install.packages("dplyr") (table_iris = tbl_df(iris)) #Table in console View(iris) #Table in R Studio glimpse(iris) [/code]

จากนั้นมาดูเรื่องของการ Filter ข้อมูลแบบใช้ Data pipeline เข้ามาช่วยเหลือ

สิ่งที่ต้องการคือ

• ทำการกรองข้อมูล iris ที่มีค่าของ column Sepal.Length > 7 ขึ้นไป
• เลือกเอาเฉพาะ column Sepal.Length, Sepal.Width และ Species เท่านั้น

สามารถเขียน code ได้ดังนี้ [code] iris %>% filter(Sepal.Length>7) %>% select(Sepal.Length, Sepal.Width, Species) [/code] คำถามต่อมาคือ ถ้าต้องเก็บผลการทำงานไว้ในตัวแปรล่ะต้องทำอย่างไรดี ? ซึ่งสามารถทำได้ 2 แบบ คือ [code] result = iris %>% filter(Sepal.Length>7) %>% select(Sepal.Length, Sepal.Width, Species) iris %>% filter(Sepal.Length>7) %>% select(Sepal.Length, Sepal.Width, Species) -> result [/code] สำหรับผมชอบแบบที่ 2 เพราะว่ามันดูสวยงามและต่อเนื่องดี ที่สำคัญมันอ่านจากซ้ายไปขวาอีกด้วย และยังมี Package อื่น ๆ ที่ทางผู้สอนแนะนำให้ศึกษาเพิ่มเติม เช่น

• dplyr สำหรับจัดการข้อมูล ซึ่งมันมีวิธีการอีกเยอะมาก ๆ
• Forecast สำหรับการทำนายผลจากข้อมูล
• ggplot2 สำหรับการแสดงผลในรูปแบบ graphic

ผมเขียนบันทึกและ source code ต่าง ๆ ไว้ที่ Github :: Learn R programming

โดยรวมแล้วเป็นภาษาที่สนุกมาก ๆ

แถมมี package ต่าง ๆ เยอะมาก ๆๆๆๆๆ ดังนั้นนักพัฒนาไม่ควรหยุดศึกษา ยิ่งเรื่องของสถิติ คณิตศาสตร์ ไปจนถึงพวก Data Mining, Machine Learning แล้ว เป็นสิ่งที่ขาด หรือ พลาดไม่ได้เลยนะ ขอตัวไปศึกษาต่อก่อน !!

ความสามารถที่น่าสนใจใน Apache JMeter 3.0

May 29, 2016, 2:20 am

≫ Next: จากงาน Google I/O 2016 มีอะไรที่น่าสนใจสำหรับนักพัฒนา Android บ้าง ?

≪ Previous: สรุปการเรียนพื้นฐานของภาษา R

$

0

0

Apache JMeter นั้นไม่ได้ปล่อย major release มาถึง 12 ปี นั่นหมายความว่าเราใช้งานเวอร์ชัน 2.0 มานานมาก !! แต่ตอนนี้ปล่อยเวอร์ชัน 3.0 ออกมาแล้ว ซึ่งแน่นอนว่า ต้องมีความสามารถใหม่ ๆ ออกมาแน่นอน ดังนั้นมาดูกันว่ามีอะไรที่น่าสนใจบ้าง ?

เปลี่ยน User Interface และ User Experience ใหม่

เริ่มกันตั้งแต่ Logo เลย ส่วนในตัวโปรแกรมก็เปลี่ยนแปลงทั้ง toolbar icon และเพิ่มบางอย่างเข้ามา เช่น เพิ่มเวลาในการทดสอบเข้ามา รวมทั้งหน้าตามของ tree ใน Test Plan ก็เปลี่ยนไป น่าใช้ขึ้นเยอะเลยนะ รวมทั้งมีการแก้ bugs เกี่ยวกับ User Interface มากกว่า 40 ตัว

เพิ่มส่วนการจัดการข้อมูลรูปแบบ JSON มาให้เลย

เนื่องจากในปัจจุบันระบบส่วนใหญ่ มักจะทำการแลกเปลี่ยนข้อมูลในรูปแบบ JSON กันมาก การที่จะทำการตรวจสอบผลการทำงานของ JSON ใน Apache JMeter ไม่ใช่เรื่องง่ายเลย บ่อยครั้งต้องนำพวก 3-party library เข้ามาใช้งาน แต่ใน Apache JMeter 3.0 นั้นได้เพิ่ม JSON-PATH Post Processor เข้ามา ทำให้ชีวิตง่ายขึ้นอีกเยอะ

สิ่งที่ชอบมาก ๆ คือ การปรับปรุงเรื่องรายงานของผลการทดสอบ

ในเวอร์ชัน 2 นั้นผลการทดสอบจะอยู่ในรูปแบบ CSV และ XML จากนั้นเราก็นำไฟล์เหล่านี้มาเปิดดูด้วยเครื่องมือต่าง ๆ โดยในเวอร์ชัน 3 นั้นเพิ่มรายงานในรูปแบบ HTML เข้ามา เป็นความสามารถที่น่าจะมีมานานแล้วนะ !! ทั้งในรูปแบบของตาราง และ chart ต่าง ๆ ถ้าใครใช้เครื่องมืออื่น ๆ เช่น Tsung และ Gatling จะทำการสร้างผลการทดสอบในรูปแบบ HTML ได้อยู่แล้ว แต่ Apache JMeter นั้นไม่มี !! โดยใน Apache JMeter 3 ปรับปรุงความสามารถของการสร้างรายงานเยอะเลย ไม่ว่าจะเป็น Dashboard และ APDEX (Application Performance Index)ให้อีกด้วย  

จะเห็นได้ว่า Apache JMeter 3.0 มีการเปลี่ยนแปลงเยอะมาก ๆ

สำหรับใครที่ใช้งานอยู่แล้วก็ลอง migrate กันดู ว่าสิ่งที่ใช้อยู่นั้น มันยังทำงานได้อยู่หรือไม่ ? แต่ส่งหลัก ๆ ที่ต้องเปลี่ยนก็คือ ใช้งานได้กับ Java 7 ขึ้นไปเท่านั้นนะ สามารถดูการเปลี่ยนแปลงเพิ่มเติมได้ที่ Apache JMeter 3.0 ทำการ Download ไปใช้งานกันเถอะ

จากงาน Google I/O 2016 มีอะไรที่น่าสนใจสำหรับนักพัฒนา Android บ้าง ?

May 29, 2016, 7:58 pm

≫ Next: สวัสดี Blue Ocean รูปโฉมใหม่ของ Jenkins

≪ Previous: ความสามารถที่น่าสนใจใน Apache JMeter 3.0

$

0

0

หลังจากงาน Google I/O 2016 จบไป อ่านบทความต่าง ๆ พบว่ามันเรื่องที่น่าสนใจมากมาย โดยเฉพาะเรื่องที่เกี่ยวข้องกับการพัฒนา Android app ไม่ว่าจะเป็น

• Android Studio 2.2
• Android N
• Instant App
• Virtual Reality Daydream
• Android Wear 2.0
• Android Auto
• Firebase
• เปิดให้ตั้งชื่อ Android N กัน

ดังนั้นจึงนำสิ่งที่น่าสนใจ และ ที่ผมสนใจ มาสรุปไว้นิดหน่อย

เรื่องแรกคือ Android Studio 2.2

ผมเชื่อว่านักพัฒนา Android app น่าจะ download มาใช้งานกันหมดแล้ว เพราะว่าไม่สามารถ update ได้เหมือนเดิม เนื่องจากมีการเปลี่ยนแปลงมากมาย ทั้งส่วนของ User Interface และ IntelliJ เป็น 2016

ถ้าใครสังเกตจะเห็นว่ามีขนาดใหญ่ขึ้นกว่าเดิมประมาณ 300 MB !! แถมในการ update จาก Preview 1 มา Preview 2 ยังต้องทำการ Download ใหม่อีกด้วย !!

โดยจะมีความสามารถที่น่าสนใจดังนี้ เริ่มจากเรื่องความเร็วทั้งตัว Android Studio เอง ที่บอกว่าเร็วขึ้นจากเดิมมากกว่า 10 เท่า รวมทั้ง Emulator ก็บอกด้วยว่า เร็วกว่า device จริงบางเครื่องอีกด้วย ต่อมาเรื่องของ Espresso Test Recorder เราสามารถ Record and Playback การทดสอบ App ได้เลย โดยจะทำการสร้าง code ของ Espresso ให้เอง และสามารถสามารถแก้ไขเพิ่มเติมได้อีกด้วย มันคล้าย ๆ กับ UI Test ใน XCode เลยนะ ตัวนี้ผมตั้งตารอคอยเลย แต่ในปัจจุบันมันก็ยังไม่ถูกปล่อยออกมา ยังไม่มีกำหนดการที่จะปล่อยออกมาให้ใช้อย่างชัดเจน ซึ่งใน Preview 2 บอกไว้เพียงเท่านี้

Unfortunately the Espresso Test Recorder is still not in this build; we're addressing a few more issues and then hope to have it ready in the next build!

จากนั้นเรื่องของกระบวนการ Build ที่ดีขึ้น เนื่องจากเราสามารถเขียนภาษา C++ ร่วมกับภาษา Java ได้แล้วนะ รวมทั้งความสามารถของ Java 8 อีกด้วย เนื่องจาก Android Studio ได้นำเอา CMake และ NDK build tool เข้ามานั่นเอง เรื่องของ Layout Editor ที่ดีขึ้นมาก เนื่องจากถ้านำไปเทียบกับ XCode พบว่า Android Studio มันล้าหลังอยู่มาก ดังนั้นในเวอร์ชันใหม่นี้จึงทำการเปลี่ยนแปลง และ ปรับปรุงให้ดีขึ้นจากเดิมมากเลย ซึ่งน่าจะทำให้เรื่องของการจัดการ Layout ง่ายกว่าเดิมมาก !! เพิ่ม feature สำหรับการวิเคราะห์ APK เข้ามา (APK Analyzer) ทำให้เราเห็นว่าควรเพิ่ม ลด และ ปรับปรุงอะไรบ้างนั่นเอง เช่นจำนวน method และ ขนาดของไฟล์ต่าง ๆ เป็นต้น ชีวิตนักพัฒนาน่าจะดีขึ้นมานะ โดยเข้าไปที่เมนู Build -> Analyze APK สามารถดู VDO เพิ่มเติมได้จาก What’s new in Android Development Tools

ปล. ความสามารถต่าง ๆ ก็แลกมาด้วยการบริโภค Memory ของเครื่องอย่างหนักเช่นกัน อย่าลืมไปเพิ่ม Memory กันนะ !!

ต่อมาคือเรื่อง Instant Apps ?

ซึ่งผู้ใช้งานสามารถใช้งาน Android app โดยไม่ต้องทำการติดตั้ง !! มันเป็นความสามารถที่น่าสนใจ และ ทำให้งง ๆ อยู่นะ แบบนี้ต้องลองไปใช้งานก่อน ว่ามันส่งผลกระทบอะไรบ้าง เช่น จำนวนการ install/download รวมทั้ง data usage ต่าง ๆ อีกด้วย ลองอ่านเพิ่มเติ่มได้ที่ Introducing Android Instant App และดู VDO ได้ที่ Google I/O Instant Apps

อีกเรื่องที่ขาดไม่ได้เลยคือ Firebase

เนื่องจากในงาน Google I/O เห็นว่ามี session เกี่ยวกับ Firebase เยอะมาก ๆ โดย Firebase นั้นถูกรวมเข้ามาทำงานร่วมกับ Ecosystem ของ Google ได้อย่างดีเลย ถ้าใครเคยใช้ Parse ที่ถูก Facebook ปิดไปแล้วนั้น จะพบว่า Firebase มันสามารถเข้ามาเติมเต็มได้เลย !! ของแบบนี้มันต้องลอง ที่สำคัญ Android Studio 2.2 นำ Firebase เข้ามารวมแล้วนะ สุดท้ายแล้วไปศึกษา เรียนรู้ และ นำมาใช้งานกันต่อไปนะครับ ชีวิตของนักพัฒนาไม่ง่ายเลย Reference Websites http://android-developers.blogspot.com/2016/05/android-studio-22-preview-new-ui.html https://www.sitepoint.com/8-key-announcements-for-android-developers-at-google-io https://www.sitepoint.com/what-can-developers-expect-in-android-n/

สวัสดี Blue Ocean รูปโฉมใหม่ของ Jenkins

May 30, 2016, 10:17 pm

≫ Next: VDO อธิบายเรื่อง Unit Test แบบขำ ๆ 15 นาที

≪ Previous: จากงาน Google I/O 2016 มีอะไรที่น่าสนใจสำหรับนักพัฒนา Android บ้าง ?

$

0

0

สำหรับผู้ใช้งาน Jenkins น่าจะเห็นข่าวเกี่ยวกับ Blue Ocean จาก blog เรื่อง Introduction Blue Ocean : a new user experience for Jenkins ซึ่งพัฒนาโดย comunitity ของผู้ใช้งาน Jenkins นั่นเอง โดยตัวตั้งตัวตีหลักคือทีมพัฒนาของ CloudBees นั่นเอง

Blue Ocean Project นั้นทำการเปลี่ยนทั้ง UX และ UI ของ Jenkins ใหม่ทั้งหมด

เพื่อให้สอดคล้อง และ อำนวยความสะดวก สำหรับจัดการระบบต่าง ๆ ของการพัฒนา software ตั้งแต่การ compile จนไปถึงการติดตั้ง นั่นคือ Delivery process โดย project นี้ยังอยู่ในช่วงของ Alpha development เท่านั้น แสดงว่าความสามารถต่าง ๆ อาจจะเปลี่ยนแปลงไปอีกมากมาย ซึ่งสามารถทำการติดตั้งบน Jenkins ผ่าน plugin นั่นเอง

ว่าแล้วทำการติดตั้งดีกว่า โดยทำการ Download code มาจาก Github :: Blue Ocean

จากนั้นก็ทำการ build จาก code เลยด้วยคำสั่ง [code] mvn clean install [/code]

ขอบอกเลยว่าใช้เวลาในการ build นานมาก ๆๆๆๆๆๆๆ แนะนำให้ไปทำอย่างอื่นเลย ไม่ต้องมานั่งรอ

เมื่อเสร็จแล้วทำการ run Blue Ocean ขึ้นมาด้วยคำสั่ง [code] cd blueocean-plugin mvn hpi:run [/code] จากนั้นเข้าใช้งานที่ URL = http://localhost:8080/jenkins/blue ทำการสร้าง pipeline ชื่อว่า Hello ขึ้นมา หน้าตาดูดีมีสกุลอย่างมาก โดยพัฒนาด้วย JavaScript นั่นเอง ประกอบไปด้วย ES6 และ React ส่วนการทำงานภายในก็เป็น Java นั่นแหละ แสดงผลการทำงานดังรูป จากนั้นทำการ build และดูผลการทำงานหน่อยสิ แต่ละการ build เป็นอย่างไรบ้าง ซึ่งจะแสดงเป็น Build pipeline ให้เลย ดูดีมาก ๆ

ที่สำคัญยังมี Blue Ocean REST APIs ไว้ให้ใช้อีกนะ

เพื่อทำให้ผู้ใช้งานสามารถปรับปรุง User Interface ได้เองตามความต้องการ และมีตัวอย่าง project สำหรับเปลี่ยนแปลงการทำงานของ Build Pipeline ให้ดูด้วย

ดังนั้นว่าง ๆ ลองเล่นดูได้ครับ มันแจ่มมาก ๆ ไม่เช่นนั้นเดี๋ยวจะคุยกับคนอื่นไม่รู้เรื่องนะครับ