ทีมพัฒนา Software ที่ดีมันเป็นอย่างไร ?

November 22, 2015, 11:51 pm

≫ Next: เพิ่งรู้ว่า Integer ใน Java นั้น 100 เท่ากับ 100 แต่ 1000 ไม่เท่ากับ 1000

≪ Previous: Elasticsearch :: แนะนำการสร้าง mapping ของข้อมูลที่ดี

$

0

0

วันนี้ได้อ่านบทความเกี่ยวกับ Modern Software Devlopment ซึ่งเขียนไว้ตั้งแต่ปี 2006 แล้ว แต่เมื่อได้อ่านทำให้เห็นว่า ทีมที่ดีควรเป็นอย่างไรบ้างนะ ? แน่นอนว่าจะประกอบไปด้วยคน หรือ สมาชิกในทีมที่ดีสิ แต่ละคนต้องมีความรู้ความสามารถ แต่ละคนต้องทำงานร่วมกันได้ดี ตรงนั้นเราไม่พูดถึงก็แล้วกัน มาดู checklist กันดีกว่า ว่าทีมของเรามีไหม ?

เริ่มจาก checklist ของ The Joel Test: 12 Steps to Better Code

เขียนไว้ตั้งแต่ปี 2000 แล้วแต่ผมว่ายังคงใช้ได้เลยนะ ประกอบไปด้วย

1. Do you use source control ?
2. Can you make a build in one step ?
3. Do you make daily builds ? (ปัจจุบันต้องเปลี่ยนเป็นทุก ๆ การเปลี่ยนแปลง)
4. Do you have a bug database ?
5. Do you fix bugs before writing new code ?
6. Do you have an up-to-date schedule ?
7. Do you have a spec ?
8. Do programmers have quiet working conditions ?
9. Do you use the best tools money can buy ?
10. Do you have testers ?
11. Do new candidates write code during their interview ?
12. Do you do hallway usability testing ?

ลองกลับไปดูทีมของทุก ๆ คน สิว่า ยังขาดข้อไหนบ้าง ? เน้นย้ำว่าทีมพัฒนานะ ที่ทำงานร่วมกันเป็น TEAM

โดยสิ่งที่น่าจะเพิ่มเข้าไปก็คือ เรื่อง Quality Assurance plan

เพื่อช่วยให้ software ที่สร้างมีคุณภาพมากยิ่งขึ้น ประกอบไปด้วย

• Unit testing
• Integration testing
• System testing
• Continuous Integration

และมีอีก checklist ที่น่าสนใจไม่แพ้กัน

มันอาจจะแสบ ๆ คัน ๆ นิดหน่อย ประกอบไปด้วย

• Do you write unit tests for most of the code?
• Do you use unit test coverage analyzer?
• Do you use automated code analyzers?
• Do you conduct code reviews on the regular basis?
• Do you use version control for all documentation?
• Does your development lead/architect write code?
• Do you refactor existing code?
• Do you follow a Coding Standard?
• Does anyone on the team fully understand the problem?

สุดท้ายแล้ว ในความคิดเห็นของคุณ

คิดว่าทีมพัฒนา software ที่ดีเป็นอย่างไร ? คิดว่าทีมพัฒนา software ที่ดีต้องประกอบไปด้วยอะไรบ้าง ?

---

เพิ่งรู้ว่า Integer ใน Java นั้น 100 เท่ากับ 100 แต่ 1000 ไม่เท่ากับ 1000

November 23, 2015, 6:40 pm

≫ Next: Android Studio 2.0 :: ทำความรู้จักกับ Instant Run เร็วฟ้าผ่ากัน

≪ Previous: ทีมพัฒนา Software ที่ดีมันเป็นอย่างไร ?

$

0

0

เพิ่งอ่าน blog เรื่อง Why 1000 == 1000 Returns False, but 100 == 100 Returns True in Java ? แค่เห็นชื่อเรื่องก็งง แต่แอบน่าสนใจ สำหรับ Java Puzzle โดยใน blog อธิบายที่มาที่ไปได้อย่างน่าสนใจ ซึ่งน่าจะทำให้เราเข้าใน Java ดีขึ้นมาอีกนิดนึง ดังนั้นมาดูกันหน่อย ว่าทำไมถึงเป็นเช่นนั้น มีการพูดคุยใน Facebook ที่นี่ [fb_embed_post href="https://www.facebook.com/somkiatspns/posts/10153769789653588/" width="550"/]

ปัญหามันเกิดจาก code ชุดนี้

เป็น code ที่น่าสนใจ และ น่าค้นหาอย่างมากมาย [gist id="1b8b815ea6b3711e34b8" file="Aha.java"]

ลองคิดเล่น ๆ ว่า ผลการทำงานจะเป็นอย่างไร ?

  ... ผลการทำงาน คือ false true มาถึงตรงนี้เล่นเอางงไปเลย !! ทำไม 100 == 100 แล้ว ทำไม 1000 != 1000 ล่ะ แบบนี้มันลำเอียง หรือ ทำงานไม่ถูกต้องหรือเปล่า ?

โดยพื้นฐานของภาษา Java สำหรับการใช้งาน ==

จะเท่ากัน หรือ ผลที่ได้คือ true ก็ต่อเมื่อทั้งสอง object ชี้ไปยังตำแหน่งเดียวกัน และมีค่าเท่ากัน ดังนั้น จากความรู้นี้ ผลที่ควรได้คือ false false

แต่การทำงานจริง ๆ มันไม่ตามทฤษฎีเลยนะ

ซึ่งเป็นสิ่งที่น่าสนใจอย่างมาก ดังนั้นมาหาเหตุผลกันดีกว่า ด้วยการเปิดดู source code ของ Integer.java กัน ซึ่งเราจะดูที่ method valueOf() [gist id="1b8b815ea6b3711e34b8" file="Integer.java"] จาก code จะเห็นว่ามีการเรียกใช้งาน property จาก class IntegerCache ด้วย คำถามที่เกิดขึ้นมา ก็คือ

• IntegerCache.high มีค่าเท่าไร ?
• IntegerCache.low มีค่าเท่าไร ?

เมื่อเข้าไปดูมันคือ inner private class อยู่ใน Integer.java นั่นเอง [gist id="1b8b815ea6b3711e34b8" file="IntegerCache.java"] ซึ่งได้ความว่าค่า default ของแต่ละ property เป็นดังนี้

• IntegerCache.high =127
• IntegerCache.low = -128

ซึ่งตรงนี้นี่เอง เป็นเหตุผลที่ว่า ทำไม Integer c = 100, d = 100; จึงเป็น object ที่อ้างถึงตำแหน่งเดียวกัน ทำให้ผลที่ได้จาก c == d เป็น true

คำถาม ทำต้องทำ Caching ด้วยล่ะ ?

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

Android Studio 2.0 :: ทำความรู้จักกับ Instant Run เร็วฟ้าผ่ากัน

November 23, 2015, 11:48 pm

≫ Next: คิดอย่างไรกับการทำ Code Review

≪ Previous: เพิ่งรู้ว่า Integer ใน Java นั้น 100 เท่ากับ 100 แต่ 1000 ไม่เท่ากับ 1000

$

0

0

ทางทีมพัฒนา Android ได้ปล่อย Android Studio 2.0 Preview ออกมา ซึ่งมีความสามารถที่น่าสนใจหลาย ๆ ตัว ลองไปอ่านดูนะครับ แต่ตัวที่น่าสนใจมาก ๆ คือ Instant Run หรือ Run เร็วฟ้าผ่า !! ซึ่งน่าจะเป็นสิ่งที่ Android Developer ต้องการ เนื่องจากมันทำให้การพัฒนารวดเร็วขึ้น มาดูกันว่าเป็นอย่างไร ?

Instant Run คืออะไร ?

เป็น feature ใหม่ไงล่ะ !! มันคือสิ่งที่เข้ามาปรับปรุง workflow ในการพัฒนาให้เร็วขึ้น ตั้งแต่การ build ไปจนถึงการ deploy นั่นคือเรื่องของ Fast Feedback นั่นเอง เป็น feature ที่บรรดา Android developer คงร้องขอ และ รอคอยมานาน ตัวอย่างการใช้งานง่าย ๆ เมื่อเราทำการแก้ไข code นิดหน่อย เราต้องใช้เวลาใน build และ deploy ไปยัง Emulator หรือ Device จริงๆ นานมากมาย ซึ่งเป็นปัญหาอันดับต้น ๆ ของการพัฒนา Android app ดังนั้น ถ้าเราสามารถ build และ deploy ได้เร็วขึ้น มันน่าจะทำให้เรารู้ผลการทำงานได้เร็วขึ้น แน่นอนว่า ส่งผลต่อการพัฒนาที่เร็วขึ้นตาม

มาดูกันว่า Instant Run มันทำงานเมื่อแก้ไข code อะไรบ้าง ?

• ทำการเปลี่ยนแปลง code ภายใน instance method
• ทำการเปลี่ยนแปลง code ภายใน static method
• ทำการเพิ่ม หรือ ลบ class
• ทำการเพิ่ม ลบ แก้ไข ข้อมูลในไฟล์ String resource แต่ต้องทำการ restart activity ก่อน

อาจจะดูน้อย แต่ถือว่าน่าเป็นส่วนหลัก ๆ ของการทำงานล่ะ แน่นอนว่า ต้องมีการเพิ่มการแก้ไขส่วนอื่น ๆ มาอีกแน่นอน รายละเอียดเพิ่มเติมสำหรับ Instant Run

มาลองใช้งานกันดูดีกว่า

แน่นอนว่า ติดตั้ง Android Studio 2.0 Preview ก่อนนะ จาก Canary Channel ให้ทำการสร้าง project ใหม่ จะพบว่า Instant Run มันเปิดให้เป็นค่า default อยู่แล้ว แสดงดังรูป ส่วนถ้าเป็น Project เก่า ๆ เข้าไปเปิด Instant Run ให้กับ Project ก่อนนะ แสดงดังรูป จากนั้นให้ทำการ Run project ของเราแบบปกติ ซึ่งในครั้งแรกจะใช้เวลานานเช่นเดิม แต่เมื่อทำการแก้ไข code และ Run ใหม่ ด้วย Instant Run แสดงดังรูป เห็นรูป Run ฟ้าผ่าหรือเปล่าล่ะ ? ผลการทำงานจะเร็วขึ้น ดังรูป ปล. เครื่องทดสอบทำงานช้านะ !!

เพียงเท่านี้ Android Developer น่าจะมีความสุขในการพัฒนามากขึ้นแล้วนะครับ จะมัวมาอ่านอยู่ทำไม ไป Download และใช้งานกันสิครับ !!

ปล. ตามจริง feature พวกนี้มันควรมีมาตั้งแต่แรกนะ !! ใคร ๆ เข้าก็ทำกันได้นานล่ะ ไม่รู้จะตกใจ หรือ ดีใจอะไรขนาดนั้น ปล. หรือว่า Google ไปซื้อ JRebel มาแล้วนะ !!

คิดอย่างไรกับการทำ Code Review

November 24, 2015, 9:40 pm

≫ Next: Lava flow มันคืออะไร  เกี่ยวข้องกับการพัฒนา Software อย่างไร ?

≪ Previous: Android Studio 2.0 :: ทำความรู้จักกับ Instant Run เร็วฟ้าผ่ากัน

$

0

0

ไม่ว่าจะเป็น Code review, Test-Driven Development และ Continuous Integration ล้วนเป็นแนวปฏิบัติที่เกิดขึ้นมา เพื่อทำให้มั่นใจว่า code ที่ถูกสร้างขึ้นมาในแต่ละวัน มันมีคุณภาพที่ดีขึ้น โดยหลายทีม หลายองค์กร ได้นำไปใช้ในการพัฒนา software แต่หลาย ๆ ที่ก็ไม่นำแนวปฏิบัติเหล่านี้ไปใช้งาน หรือนำไปใช้แล้วกลับก่อให้เกิดปัญหาแทน ดังนั้นมาดูเหตุผลหลัก ๆ ว่ามันคืออะไร ?

Code review มันใช้เวลานานมาก ๆ

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

ดังนั้นแทนที่จะทำ Code review ก็ให้ programmer ทำการพัฒนา code ให้เร็วที่สุด ทดสอบเอง ซึ่งไม่รู้ว่าทดสอบแบบไหน แต่จะบอกว่า งานเสร็จแล้ว โดยไม่ได้สนใจโครงสร้างของ code และ ระบบเลย

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

คนที่ Review code มองเพียงแต่ภาพใหญ่ และ กลายเป็นคอขวด !!

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

ดังนั้นขอแนะนำการทำ Code Review นิดหน่อย

ให้ทำ Code review เหมือนกับการ hack เข้าไปยังคนคนนั้น ว่าเขาคิดอย่างไร ? ว่าทำไมเขาคิดอย่างนั้น ? มันง่ายมากที่หาจุดที่ไม่ดีใน code มันง่ายพอ ๆ กับการแก้ไข ( แต่ก็ไม่ค่อยแก้ไข เพราะว่า ไม่มีเวลา !! ) ในแต่ละวัน programmer แต่ละคนสามารถที่ ทำการ rename ชื่อตัวแปร ชื่อ method ได้จำนวนมาก ๆ สามารถทำการ extract code ไปยัง method ใหม่ ๆ ได้จำนวนมาก ๆ สามารถแก้ไขรูปแบบ code ที่ไม่ดี ได้จำนวนมาก ๆ สามารถแก้ไข Bug ได้ จำนวนมาก ๆ ปล. ถ้ามีเครื่องมือดี ๆ นะ แต่ว่าไม่สามารถ แก้ไขโครงสร้าง และ สถาปัตยกรรมของระบบได้ แก้ไขปัญหาเรื่อง performance ของระบบได้ แก้ไขข้อมูลที่ไม่ถูกต้องบน production ได้ เพราะว่า ระบบยังทำงานอยู่

มาถึงตรงนี้ สิ่งที่ควรทำคืออะไรล่ะ ?

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

จะทำ Code Review ให้ดี

แนะนำให้ทำบ่อย ๆ ซึ่งนั่นหมายถึง การทำ peer review และ pair programming แทนซะ รวมทั้งอย่าให้ Code Review กลายเป็นคอขวด หรือ ปัญหานะ เนื่องจากเป้าหมายของมัน เพื่อช่วยให้ระบบที่ทำการพัฒนาดีขึ้นอย่างต่อเนื่อง

Lava flow มันคืออะไร  เกี่ยวข้องกับการพัฒนา Software อย่างไร ?

November 25, 2015, 3:42 am

≫ Next: ว่าด้วยเรื่อง Android Application Architecture ที่ดี

≪ Previous: คิดอย่างไรกับการทำ Code Review

$

0

0

วันนี้นั่งดู VDO จากงาน Android Dev Summit เจอคำหนึ่งที่น่าสนใจคือ Lava Flow เกิดความสงสัยว่ามันคืออะไร ? จึงได้ลองหาข้อมูลเพิ่มเติม ทำให้รู้ว่า มันคือรูปแบบของปัญหาอย่างหนึ่ง ซึ่ง developer ทุก ๆ คนน่าจะเคยเจอ และ เคยทำกันมาบ้าง

Lava flow คืออะไร ?

หรือเรียกว่า Lava Layer หรือเรียกว่า Dead code หรือเรียกว่า Vendor lock-in คือ anti-pattern สำหรับการพัฒนา software คือ คำที่ใช้อธิบายรูปแบบของปัญหาที่พบมากในการพัฒนา software มันเป็นอาการของ code ที่ทำงานซ้ำ ๆ ที่กระจายอยู่ทั่วไป หลายที่ในระบบ มันเป็นอาการของทีมพัฒนาที่ไม่รู้ และ ไม่เข้าใจ ว่า code ทำงานอย่างไรกันแน่ ? ว่า code มีรูปแบบอย่างไร ? ว่าใช้เทคโนโลยีอะไรบ้าง ? ว่าเทคโนโลยีที่ใช้อยู่มันแก้ไขปัญหาเดิมซ้ำ ๆ หลายที่

โดยรูปแบบนี้จะพบได้มาก จากระบบที่เรียกว่า Enterprise

และจาก

• ระบบมีขนาดที่ใหญ่
• ระบบมีความเป็นความตายรออยู่
• ระบบที่ใช้งานมานาน ๆ ซึ่งมักเรียกว่า Legacy system
• ทีมพัฒนามีอัตราการ turn-over ที่สูงมาก ๆ

ดังนั้นจากรูปแบบเหล่านี้ทำให้ ความรู้ต่าง ๆ เกี่ยวกับระบบ หายไปกับคนเสมอ ถึงแม้จะมีเอกสารก็ตาม ผมคิดว่าทุกคนคงรู้ดีว่า เอกสารส่วนใหญ่มันไม่ได้ช่วยอะไรเลย !! เมื่อมีการเพิ่ม แก้ไข feature ต่างๆ คนทำไว้ก็ไม่อยู่ คนอยู่ทำก็ไม่รู้เรื่อง สิ่งที่เลือกทำถ้าต้องแก้ไขของเดิมคือ Work around ไป เพื่อให้มันทำงานได้ แต่ถ้าหาไม่เจอก็เขียนใหม่มันไปเลย แทนที่จะทำการแก้ไข code ให้ดีขึ้นก่อนแก้ไข !! บ่อยครั้งจะทำการเขียน comment ใน code ไว้ เช่น Do not delete this code เป็นต้น บ่อยครั้งจะเขียน code เพิ่มเข้าไป ไม่อยู่บนสุดของ method ก็อยู่ล่างสุดของ method โดยไม่ทำการลบ code เก่า

ตัวอย่างของ code ส่วนของ Data Access Layer ของระบบ

แสดงดังรูป คำอธิบาย จะเห็นได้ว่า แต่ละ version ก็มีรูปแบบที่ต่างกันไป ทั้งการออกแบบ และ เทคโนโลยีที่ใช้ แต่ทุก ๆ version ยังคงอยู่ และ ถูก deploy ขึ้น production เสมอ สังเกตไหมว่า ใน version ที่ 4 นั้น มี 4 วิธีในการแก้ไขปัญหาเดียวกัน !! ผลที่ตามมา คืออะไรล่ะ ? ยิ่งนับวันระบบมีความซับซ้อนมากขึ้น ยิ่งนับวันระบบมีความยุ่งเหยิงมากขึ้น นั่นคือ โครงสร้าง และ architecture ของระบบยิ่งแย่ลงไปเรื่อย ๆ

นี่แหละที่เราเรียกว่า ระบบปะผุ

code ที่มีอยู่แล้วกลายเป็นเพียง history เท่านั้น ถ้าต้องการแก้ไข หรือ เพิ่มอะไรเข้าไป เราจะเขียน ontop อย่างเดียว ไม่ไปยุ่งกับของเก่า แล้วในที่สุดมันจะกลายเป็น spaghetti code + dead code นั่นหมายถึง Developer ชอบเขียนใหม่มากกว่าปรับปรุงให้ดีขึ้น หรือรู้ว่าต้องปรับปรุง แต่ไม่สามารถหาเหตุผลเพื่ออธิบายให้ฝ่าย business เข้าใจได้ หรือว่าคุยกับฝั่ง business แล้วไม่รู้เรื่อง หรือมีปัญหาเรื่องพูดคุย และ สื่อสารกัน

มี Developer คนไหน เผชิญกับ Lava flow อยู่บ้าง ? หรือว่ากำลังสร้างมันขึ้นมา !!

Reference Websites http://www.antipatterns.com/lavaflow.htm http://mikehadlow.blogspot.no/2014/12/the-lava-layer-anti-pattern.html?m=1 http://perldesignpatterns.com/?LavaFlow http://mikehadlow.blogspot.com/2014/12/the-lava-layer-anti-pattern.html http://www.infoq.com/news/2015/01/lava-layer-antipattern http://robkent.com/blog/?p=88

ว่าด้วยเรื่อง Android Application Architecture ที่ดี

November 25, 2015, 9:46 pm

≫ Next: เรื่องน่าสนใจสำหรับการสมัครงาน Programmer

≪ Previous: Lava flow มันคืออะไร  เกี่ยวข้องกับการพัฒนา Software อย่างไร ?

$

0

0

จากงาน Android Dev Summit 2015 นั้น มีหัวข้อที่น่าสนใจเยอะเลย หนึ่งในนั้นคือ Android Application Architecture ได้อธิบายสิ่งต่าง ๆ ที่น่าสนใจสำหรับการพัฒนา Android application แต่หัวข้อที่ชอบมาก ๆ คือ โครงสร้างการทำงานของระบบ มาดูกันว่าเป็นอย่างไร

เริ่มต้นได้อย่างน่าคิด

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

• MVC
• MVP
• MVP-I
• MVVM
• MVVM-I
• VIPER
• Clean Architecture
• Reactive
• Flux
• ...

พบว่ามันมีหลายแนวทางมาก ๆ !! (Paradox of choices) แต่แนะนำว่า อย่าไปยึดติดกับ desing pattern อย่าไปยึดติดกับ Library อย่าไปยึดติดกับ Framework เพราะว่ามันจะจำกัดกรอบความคิดของเรามากเกินไป ให้เน้นไปที่การแก้ไขปัญหาดีกว่า ทุกแนวทางนั้น ล้วนมีเป้าหมายเดียวกัน คือ สามารถเปลี่ยนแปลงได้รวดเร็ว นั่นคือ สามารถ refactoring ได้ง่าย รวมไปถึงทดสอบการทำงานแต่ละส่วนได้ง่าย เพื่อป้องกันไม่ให้เกิดสิ่งที่เรียกว่า Lava flow

สิ่งที่แนะนำในการออกแบบ คือ Architect for UX (User Experience)

มันเป็นอย่างไรล่ะ ? ตัวอย่าง App ต้องทำการส่งข้อมูลไปยัง server คำถามคือ จะขึ้นรูป loading ทำไม ? แถมบางครั้งถ้า network มีปัญหา รูป loading มันไม่หายไปด้วย ทำให้ app ปิดตัวเองอีก ซึ่งเป็นประสบการณ์การใช้งานที่ไม่ดีเลยใช่ไหม ? แสดงการทำงานดังรูป ปัญหาจากรูปแบบการทำงานนี้ คือ View จะรอไปจนกว่าจะได้ข้อมูลจาก ViewController และ Network นั่นคือ ViewController มันผูกติดกับ Network อย่างมาก !! สามารถแก้ไขด้วยการแยก ViewController ออกจาก Network ซะ ด้วยการเพิ่มอีกหนึ่งส่วน หรือ อีกหนึ่ง layer นั่นคือ Model เนื่องจาก ViewController นั้นต้องการเพียงข้อมูลเพื่อส่งไปแสดงผลที่ View เท่านั้น ไม่ได้ต้องการ Network เลย แสดงการทำงานดังรูป แต่จากรูปแบบนี้ก็ยังคงมีปัญหากับ Network อยู่ใช่ไหม ? เนื่องจากเราเพียงย้ายให้ Network ไปทำงานกับ Model เท่านั้นเอง ดังนั้น จะแก้ไขปัญหานี้อย่างไรดีล่ะ ? สิ่งที่ต้องทำก็คือ Model นั้นให้เป็น Persistent model ที่อยู่บนเครื่อง หรือ Local ซะ และเพิ่มส่วนของ Application Logic ขึ้นมา เพื่อทำงานร่วมกับ Network แทน โดยแบ่งการทำงานเป็นส่วน ๆ ดังนี้ ส่วนที่ 1 เมื่อ Application logic ได้ข้อมูลจาก Network หรือ sync data เรียบร้อยแล้ว จะทำการส่ง หรือ จัดเก็บไปที่ Persistent Model แสดงการทำงานดังรูป ส่วนที่ 2 ส่วนของ ViewController เมื่อต้องการข้อมูลไปแสดงผลที่ View ก็ให้ทำการดึงข้อมูลจาก Persistent Model แทน ซึ่งไม่ต้องรออะไรเลย แสดงการทำงานดังรูป ส่วนที่ 3 เมื่อมีการร้องขอ หรือ ส่งข้อมูลมาจากผู้ใช้งานผ่าน View จะทำการส่งการร้องขอมายัง ViewController จากนั้นจะส่งการร้องขอไปยัง Application Logic เพื่อทำงาน ซึ่งจะทำงาน 2 อย่าง คือ

1. ทำการ update ข้อมูลที่ Persistent Model
2. ทำการส่งข้อมูลไปยัง Network

จากนั้นเมื่อฝั่ง Network ส่งข้อมูลกลับมายัง Application Logic แล้ว จะทำการ update ข้อมูลที่ Persistent Model และแจ้งกลับไปยัง ViewController ว่าคำร้องขอเสร็จเรียบร้อยแล้ว แสดงการทำงานดังรูป

มาถึงตรงนี้อาจจะงงอีกว่า จะแจ้งกลับไปยัง ViewController ยังไงว่าทำงานเสร็จแล้ว ?

น่าคิดมาก ๆ ดังนั้นในขั้นตอนการส่งคำร้องขอตั้งแต่แรก ต้องมีการจัดการ event หรือ เหตุการณ์ต่าง ๆ ไว้ก่อนนะ นั่นคือมีการ register event และ subscribe ไว้ เมื่อมีการทำการเสร็จสิ้นก็ให้ทำการส่ง notify ไปยัง subscribe นั้น ๆ จากนั้นก็ทำการ unsubscribe ซะ เป็นอันพบขั้นตอนการทำงาน แนวคิดพวกนี้มันคือ EventBus นั่นเอง แต่ทำมาเยอะขนาดนี้ มันก็ยังไม่ปัญหาตามมาอีก นั่นคือ เรื่องของ Background process ถ้า queue การทำงานมันค้าง และ เต็ม ทำให้ process อื่น ๆ ที่อยู่ใน queue รอไปเรื่อย ๆ จะส่งผลให้ app ค้าง หรือ ปิดตัวไปอีก แสดงการทำงานดังรูป การแก้ไขปัญหานี้คือ ก็ให้แยก queue ของการทำงานให้ทำงานคนละ Thread ไป นั่นคือ

• Network task queue
• Local task queue

ส่งผลให้ app ของเราทำงานได้รวดเร็ว (Responsive) แสดงการทำงานดังรูป

สามารถสรุปการทำงานในส่วนของ Activity สำหรับการ Notify ได้ดังนี้ ( Activity State Machine )

• onCreate() ทำการ setup พวก User Interface ต่าง ๆ
• onStart() ทำการ register event เช่น การดึงข้อมูล
• เมื่อเกิด event ขึ้นมา หรือ onEvent() หรือ ดึงข้อมูลเสร็จแล้ว จะทำการ refesh ข้อมูลใหม่
• onStop() ทำการ unregister event

ซึ่งจะเห็นได้ว่ามันเรียบง่าย และง่ายต่อการทำความเข้าใจอย่างมาก

Key Takeaway มีดังนี้

• Design for offline เนื่องจากเรื่องของ network มันไม่เคยเป็นมิตรกับใครเลย
  • ให้ส่วนของ User Interface ใช้ข้อมูลจาก model
  • ส่วนของ network และการ update model ให้ Application Logic จัดการ
  • ให้แต่ละส่วนทำงานเป็นอิสระจากกัน อาจจะใช้งาน Event, Callback หรืออะไรก็ได้ที่จำเป็น
• Decoupling แต่ละส่วนแยกกันทำงาน
  • สามารถนำ Dependency Injection มาใช้งานได้
  • มันมีทั้งข้อดีและข้อเสีย ต้องทำความเข้าใจก่อน ไม่ใช่ทำตาม ๆ กันไป
  • อย่าใช้ Reflection API โดยเด็ดขาด เพราะว่ามันทำให้ performance ต่ำลงไปมาก ดังนั้นเลือก library ให้ระวังกันด้วย
• Design API
  • ออกแบบ API เพื่อฝั่ง client หรือ ผู้ใช้งานนะ
  • ให้ฝั่ง client ทำงานน้อยที่สุด
  • ให้ฝั่ง server ทำงานมากที่สุด
• Act locally, Sync Globally !!

และยังมีเรื่องอื่น ๆ อีกมากมาย ลองดูต่อจาก VDO ข้างต้นได้เลยครับ มีสิ่งที่น่าสนใจให้เราเรียนรู้อีกมากมาย

เรื่องน่าสนใจสำหรับการสมัครงาน Programmer

November 26, 2015, 8:46 pm

≫ Next: ทำงานกับ Legacy code  มันสนุกไหม ?

≪ Previous: ว่าด้วยเรื่อง Android Application Architecture ที่ดี

$

0

0

ได้อ่านบทสัมภาษณ์ของคุณ David Heinemeier Hansson หรือ DHH ผู้สร้าง Ruby On Rails (RoR) และ CTO ของ Basecamp เป็นเรื่องเกี่ยวกับรับ Software Engineer เข้ามาทำงาน ซึ่งเป็นมุมมองที่น่าสนใจอย่างมาก จึงนำมาสรุปไว้นิดหน่อยดังนี้ อธิบายไว้ว่า

• 80% ของผู้สมัครเข้ามา จะโยนทิ้งไปเพราะข้อมูลในใบสมัคร หรือ ใน resume มันแย่!!
• 20% ถูกตัดออกไปอีก ด้วยเหตุผลที่น่าสนใจอย่างมาก !!

แล้วจะมีใครผ่าน และ เข้าไปทำงานไหมเนี่ย ?

มาดูขั้นตอนการรับคนเข้าทำงานของ Basecamp กัน

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

ขั้นตอนที่ 1 ดู resume และ ใบสมัครงาน

ซึ่งประมาณ 80% จะโดนตัดออก และ ทิ้งไป เนื่องจากมักจะมีข้อมูลต่าง ๆ เหล่านี้

• ข้อมูลการศึกษา
• ข้อมูล GPA
• ข้อมูลบริษัทที่ทำงานมา

แต่ถ้าคุณต้องการทำงานที่ Basecamp อย่าเขียนพวกนี้มาโดยเด็ดขาด เนื่องจากผลการเรียน และ เคยทำงานกับใคร ที่ไหน มันไม่ได้ช่วย ไม่เกี่ยวอะไรเลย สำหรับการรับสมัครตำแหน่ง programmer

โดยข้อมูล resume มันไม่ได้บ่งบอกว่า คุณมีความสนใจ ใส่ใจในบริษัทที่จะสมัครมาทำงานเลย เป็นเพียง template ที่หาได้ทั่วไปในโลก internet

ลองคิดดูสิว่า บริษัทจะรับสมัครคนที่ไม่มีความสนใจในบริษัทหรือ ?

ขั้นตอนที่ 2 ทำการ review code ของผู้สมัคร

คือ 20% ที่เหลือรอดมานั่นเอง โดยจะพิจารณาเกี่ยวกับ code เพราะว่า มันคือสิ่งที่ต้องทำ ประกอบไปด้วย

• คุณให้ความสนใจ ใส่ใจกับ code มากเท่าไร ?
• คุณให้ความสนใจ ใส่ใจกับ คุณภาพของ code มากไหม ?

ส่วนใหญ่จะไม่ผ่านเพราะว่า code แย่ ทั้งรูปแบบของ code ทั้งการตั้งชื่อที่แย่ ทั้ง code ที่ไม่ถูกใช้งาน ทั้ง scope การทำงานของ code ที่แย่ ทั้ง comment ที่ไม่เป็นประโยชน์ใน code อีก ดังนั้น คุณในฐานะ programmer ต้องให้ความสนใจ ใส่ใจใน code ต้องทำความสะอาด code เหมือนกันบ้านที่อยู่นั่นแหละ ต้องทำความสะอาดอยู่สม่ำเสมอ (ต้องบอกตัวเองด้วย) ไม่เช่นนั้น code มันจะแย่ลงไปเรื่อย ๆ นั่นคือ ส่งผลต่อกับระบบโดยรวมอีกด้วย

สิ่งที่น่าสนใจมาก ๆ คือ Your Code is Clean, But Not Great

เพราะว่า เราต้องทำการปรับปรุง code ให้ดีขึ้นอย่างต่อเนื่อง มาดูรูปแบบ code ที่มันแย่ ๆ มักพบเจอบ่อย ๆ

• แต่ละ method เกิน 15 บรรทัด
• แต่ละ method ทำงานเยอะมาก
• ใช้งาน global variable เยอะมาก ๆ
• ตั้งชื่อตัวแปรได้แย่มาก ๆ
• ทำการ comment ที่แย่ และ ไร้ประโยชน์

คำถาม แล้วเราจะทำการปรับปรุง code ให้ดีขึ้นได้อย่างไร ? คำตอบ Practice, practice, practice. And read. แนะนำให้อ่านหนังสือต่าง ๆ เหล่านี้

• Smalltalk: Best Practice Patterns
• Clean Code by Robert C. Martin
• Refactoring: Improving the Design of Existing Code
• Practical Object-Oriented Design in Ruby by Sandi Metz

สุดท้ายแล้ว ก่อนจะส่ง Resume

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

ทำงานกับ Legacy code  มันสนุกไหม ?

November 27, 2015, 11:35 pm

≫ Next: ข้อดีและข้อเสียของ NoSQL ที่ต้องรู้ !!

≪ Previous: เรื่องน่าสนใจสำหรับการสมัครงาน Programmer

$

0

0

จากหนังสือ Lean from the Trenches บทที่ 18 เรื่อง Reducing the Test Automation Backlog ทำการอธิบายเกี่ยวกับ การทำงานร่วมกับ Legacy code ได้อย่างน่าสนใจ ซึ่งคิดว่า น่าจะมีประโยชน์สำหรับใครก็ตามที่เผชิญกับมันอยู่ ว่าจะคิด และ ลงมือจัดการอย่างไรดี ?

หลาย ๆ บริษัท และ ทีม ที่ยังคงทำงานกับ Legacy code เป็นหลักนั้น

มักจะประสบปัญหาอย่างแรง เมื่อต้องการปรับเปลี่ยน แก้ไข ทั้งระบบงาน และ ขั้นตอนการทำงาน ปัญหามันเกิดมาจาก "Lack of test automation" หรือขาดชุดการทดสอบแบบอัตโนมัติ !! ผลที่ตามมาประกอบไปด้วย การแก้ไข code เป็นไปได้ยากมาก ๆ เพราะว่า แก้ที่หนึ่งอาจจะไปกระทบส่วนอื่น ๆ โดยที่เราไม่รู้เลย เมื่อทำการ deploy และ release ขึ้น production server แล้ว คนที่เจอ defect คือ ผู้ใช้ หรือ ลูกค้า สิ่งเหล่านี้มันสร้างความไม่พอใจให้กับลูกค้า สิ่งเหล่านี้มันสร้างความวิตกกังวลให้กับทีมพัฒนา และ ฝั่ง business เสียทั้งเวลา และ ค่าใช้จ่าย สำหรับการแก้ไขความผิดพลาดบน production server (Hotfix) บ่อยครั้งพบว่า เมื่อแก้ไขปัญหาหนึ่ง ๆ จะมีอีกหลาย ๆ ปัญหาตามมาอีกเพียบ แม้แต่ปัญหาที่เคยแก้ไขไปแล้ว ยังกลับมา

สิ่งเหล่านี้มันทำให้ทีมพัฒนา กลัวการแก้ไข Legacy code

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

คำถาม คือ เราไม่คิดจะทำอะไรให้ Legacy code มันดีขึ้นบ้างหรือไง ?

ประเด็นหลัก คือ แล้วมันมีทางเลือกอะไรบ้างล่ะ ?

1. ไม่ต้องไปสนใจมัน และหวังว่าเดี๋ยวก็เลิกใช้กันไปเอง
2. สร้างใหม่กันดีกว่า พร้อมกับใช้ Test-Driven Development (TDD) เพื่อทำให้มั่นใจว่าการทดสอบมันครอบคลุมระบบทั้งหมด
3. สร้าง project สำหรับ test automation แยกออกมา สร้างทีมใหม่ขึ้นมา เพื่อดูแลโดยเฉพาะ เพื่อปรับปรุง test coverage ให้ดีขึ้น และ เพียงพอต่อการใช้งาน
4. ให้ทีมทำการปรับปรุง code และ test coverage ให้ดี ให้เยอะขึ้นเรื่อย ๆ เป็นรอบการทำงานไป (Iteration)

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

1. เขียน test case ทั้งหมดออกมา
2. แบ่งกลุ่มของ test case ตามความเสี่ยง ตามค่าใช้จ่ายในการทำ manual test และค่าใช้จ่ายในการทำ test automation
3. จัดเรียงลำดับตามความสำคัญของ test case​ ซะ
4. เริ่มเขียน test case ที่ทำงานแบบอัตโนมัติแบบ iteration ไป จากความสำคัญมากไปน้อย ซึ่งให้แบ่งการทำงานเป็นงานหลัก 80% และ test automation อีก 20% ส่วนงานใหม่ ๆ ก็ให้มี test automation ซะ

ส่วน 3 แนวทางแรกนั้น น่าจะเป็นแนวทางที่หลาย ๆ คนชอบทำ !!

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

คำถามที่ตามมาก็คือ แล้วเมื่อไรที่จะเขียน test automation เสร็จล่ะ ? อะไรคือตัวชี้วัดว่าเสร็จนะ ?

แต่ว่ามันขึ้นอยู่กับระบบงานด้วยเช่นกัน ว่าจะเลือกแนวทางไหน !!

ยกตัวอย่างเช่น ถ้า Legacy code เป็นระบบที่ทำงานอยู่บน framework และ platform ที่เก่ามาก ๆ ไม่มีใครที่รู้เรื่อง หรือ มีประสบการณ์เลย เช่น Visual Basic 6, Visual FoxPro ปัญหาที่พบเจอคือ ขาดคน ที่จะทำ !! ดังนั้น แนวทางที่เหมาะสมน่าจะเป็น แนวทางที่สอง คือ การเขียนใหม่ กับ TDD

Legacy code มันคือปัญหาที่แท้จริง

แต่มีสิ่งหนึ่งที่น่าคิด คือ code ที่เราเขียนกันขึ้นมานั้น มันอาจจะเป็น Eventually Legacy code ก็เป็นได้ ดังนั้นเลือกแนวทางที่เหมาะสม ในการจัดการดูครับ

คำถาม แล้วคุณล่ะ เลือกทางไหนกัน เพื่อจัดการกับ Legacy Code ?

---

ข้อดีและข้อเสียของ NoSQL ที่ต้องรู้ !!

November 28, 2015, 9:40 pm

≫ Next: มาดูข้อมูลสถิติต่าง ๆ จาก StackOverflow กันหน่อย

≪ Previous: ทำงานกับ Legacy code  มันสนุกไหม ?

$

0

0

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

เริ่มที่ข้อเสียของ NoSQL เมื่อเทียบกับ RDBMS

1. Less mature RDBMS นั้นเกิดมากว่า 25 ปีแล้ว ส่วน NoSQL นั้นเพิ่งเกิดมา และ เพิ่งได้รับความนิยม 2-3 ปี เท่านั้น ดังนั้น เรื่องความสามารถที่ครบถ้วน เรื่องความเสถียร และ ความน่าเชื่อถือของ RDBMS จึงสูงกว่ามาก ส่วน NoSQL นั่นมีให้เลือกใช้งานเยอะมาก ๆ แถมความสามารถก็ยังไม่ครบอีก รวมทั้งความน่าเชื่อถือที่ยังน้อยอีกด้วย ทำให้องค์กร หรือ ทีม ใด ๆ ที่จะนำไปใช้งาน มักจะมีข้อโต้แย้งกับส่วนอื่น ๆ ไม่ว่าจะเป็น System Admin, Operation, Business และ Management เป็นต้น 2. Less support องค์กรใหญ่ ๆ หรือระบบ Enterprise จำเป็นต้องการความแน่ใจ มั่นใจ ว่า จะไม่ถูกทอดทิ้ง หรือ มีคนช่วยเหลือยามเกิดปัญหา หรือ สามารถโยนงานให้ไปทำได้ ซึ่งทำให้รู้สึกปลอดภัย และ วางใจมากขึ้น แน่นอนว่า RDBMS เจ้าใหญ่ ๆ ล้วนมี service เหล่านี้ให้ใช้บริการมากมาย ทั้ง support 24x7 พร้อมกับ remote service เป็นต้น ส่วน NoSQL มันตรงข้ามเลย เพราะว่า ส่วนใหญ่มันเป็น open-source ไม่มีใครมา support หรอกนะ มีปัญหากรุณาช่วยตัวเอง หรือ หาข้อมูลจาก community ก็แล้วกัน แต่ช่วงหลัง ๆ มาพบว่า NoSQL หลาย ๆ ตัว มี service ต่าง ๆ เหล่านี้ให้ใช้แล้วเช่นกัน 3. Administration ส่วนใหญ่ NoSQL มันถูกสร้างขึ้นมาเพื่อแก้ไขปัญหา ดังนั้น จึงไม่ค่อยมีหน้าจัดการ หรือ Administrator มาให้ด้วย ทั้งการติดตั้ง และ การจัดการ ทำให้ผู้ที่ใช้งานต้องมีความรู้ในเรื่องของ technical รวมทั้งรู้ และ เข้าใจวิธีการติดตั้ง และ ดูแลรักษาด้วย ซึ่งมันขัดแย้งกับ RDBMS และในระบบ Enterprise ที่ทุก ๆ อย่างจะมีหน้า User Interface สวย ๆ ให้ใช้งาน ดังนั้นการจะปรับเปลี่ยนมันไม่ใช่เรื่องง่ายเลย 4. No advance expertise เนื่องจาก NoSQL มันเพิ่งเกิดได้ไม่นาน จะหาผู้เชี่ยวชาญจริง ๆ มันไม่ใช่เรื่องง่ายเลย ส่วนผู้เชี่ยวชาญฝั่ง RDBMS นั้นมีเยอะมาก ๆ ซึ่งตรงส่วนนี้ถือว่า เป็นเรื่องที่มีความเสี่ยงสูงมาก ๆ ดังนั้นควรระวังในการนำมาใช้งาน รวมทั้งต้องเข้าใจด้วยว่า เรานำเอา NoSQL มาใช้เพื่ออะไร ? เรานำเอา NoSQL มาใช้เพื่อแก้ไขปัญหาอะไรของ RDBMS ?

มาดูข้อดีของ NoSQL เมื่อเทียบกับ RDBMS

มีข้อเสีย มันก็ต้องมีข้อดีกันบ้าง ไม่เช่นนั้นหลาย ๆ องค์กร คงไม่นำมาใช้งานกันหรอกนะ 1. Elastic scalability ในการที่จะขยาย database เช่นเพิ่มเครื่อง และ ทำ cluster นั้น สำหรับ RDBMS มันไม่ใช่เรื่องง่ายเลย แต่ NoSQL มันถูกสร้างมาเพื่อให้ scale out โดยธรรมชาติ 2. Big data application มันถูกสร้างมาเพื่อรองรับข้อมูลขนาดใหญ่ ที่เกิดขึ้นมาอย่างรวดเร็ว ซึ่ง RDBMS ไม่ได้ถูกสร้างมาเพื่อรองรับ ข้อมูลที่เกิดขึ้นมารวดเร็ว และ ใหญ่ขนาดนี้ รวมทั้งเรื่องของการประมวลผลอีกด้วย ดังนั้น NoSQL จึงเป็นคำตอบที่ดีกว่านั่นเอง จะสังเกตุได้ว่า ในปัจจุบัน RDBMS หลาย ๆ ตัวเริ่มนำเอาความสามารถของ NoSQL เข้าไปด้วย หรือไม่เช่นนั้น ก็สร้าง NoSQL ของตังเองขึ้นมา 3. Economy ในการติดตั้ง RDBMS นั้นต้องการ server และ storage ที่สูง หรือ แพงนั่นเอง ส่วน NoSQL ไม่ต้องการ server ที่แพง และ แรงมาก เนื่องจากถ้าต้องการขยายก็เพียงเพิ่มเครื่องใหม่เข้าไป นั่นหมายถึง เราสามารถขยายความสามารถของระบบ ด้วยต้นทุน และ ค่าใช้จ่ายที่ต่ำลงนั่นเอง

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

Reference Websites http://www.hadoop360.com/blog/advantages-and-disadvantages-of-nosql-databases-what-you-should-k https://speakerdeck.com/abchaudhri/considerations-for-using-nosql-technology-on-your-next-it-project-1

มาดูข้อมูลสถิติต่าง ๆ จาก StackOverflow กันหน่อย

November 29, 2015, 8:54 pm

≫ Next: สิ่งที่ควรทำสำหรับ Automated Acceptance Testing

≪ Previous: ข้อดีและข้อเสียของ NoSQL ที่ต้องรู้ !!

$

0

0

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

Stack Overflow คืออะไร ?

เผื่อใครไม่รู้จักนะครับ เปิดให้บริการตั้งแต่ปี 2008 ต่อวันมีผู้เข้ามาใช้งานกว่า 7.6 ล้าน เป็น website ที่มีเข้าใช้งานทั้งโลกอันดับที่ 57 จาก Alexa คือ website เพื่อถามและตอบปัญหาของชาว programmer/developer ถ้าตั้งคำถาม และ อธิบายปัญหาอย่างละเอียดชัดเจน อาจจะได้คำตอบ และ วิธีการแก้ไขปัญหาภายในเวลาไม่ถึงชั่วโมง 11 ล้าน คือ จำนวนคำถาม 17 ล้าน คือ จำนวนคำตอบ มีคำถามประมาณ 27% ที่ไม่ถูกตอบเลย แต่ผู้ใช้งานที่ตอบคำถามนั้นมีเพียง 8% จากผู้ใช้งานทั้งหมด (ตอบมากกว่า 5 ครั้ง) ซึ่งผู้ใช้งานกลุ่มนี้ คือ หัวใจของ web นี้เลยนะ ตัวอย่างข้อมูลของผู้ตอบคำถามในวันที่ 28 เดือนพฤจิกายน พบว่ามีผู้ตอบเพียง 7,800 คนเท่านั้น !! ปล. ถ้าอยากรู้ที่มาที่ไปของชื่อ Stack Overflow ดูได้ที่นี่เลย

มาดูข้อมูลการใช้งานกันบ้าง

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

1. JavaScript
2. Java
3. Android
4. PHP
5. C#
6. Python
7. jQuery
8. HTML
9. iOS
10. C++

แสดงดังรูป แสดงรายละเอียดดังนี้ ปิดท้ายด้วยผู้ใช้งานในประเทศไทยกันหน่อยสิ (Top user by country) https://data.stackexchange.com/stackoverflow/query/53058/top-users-by-country

หลาย ๆ คนบอกว่า Stack Overflow นั้นมันส่งผลกระทบต่อโลก programming มาก

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

• Copy and paste programmer
• Full stack overflow developer

หนักไปกว่านั้นน่าจะเปลี่ยน Computer programming ไปเป็น Googling Stack Overflow programming ไปเลย ซึ่งจากที่ดูแล้วเรื่องขำ ๆ เหล่านี้มันกลายมาเป็นความจริงแล้วนะ

สุดท้าย มีคำถามว่า ถ้า Stack Overflow ล่ม คุณจะรู้สึก และ ทำอย่างไรดีล่ะ ?

ระหว่าง หรือโทรไปลาป่วย Reference Websites http://priceonomics.com/stack-overflow-and-the-zeitgeist-of-computer/ http://stackexchange.com/sites#traffic

สิ่งที่ควรทำสำหรับ Automated Acceptance Testing

November 30, 2015, 8:03 pm

≫ Next: [แปล] 5 DEADLY BELIEFS THAT LIMIT LEADERS 

≪ Previous: มาดูข้อมูลสถิติต่าง ๆ จาก StackOverflow กันหน่อย

$

0

0

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

พบว่าสิ่งที่ยากที่สุด คือ การทำงานร่วมกัน !!

มันง่ายมากที่จะเขียน spec ของงาน มันง่ายมากที่จะเขียน rule การทำงาน มันง่ายมากที่จะเขียน data test หรือ example แต่เรื่องสนุก ๆ มันจะเกิดขึ้น เมื่อต้องทำการแปลงจากสิ่งที่อยู่ในเอกสารมาเป็น Automated Acceptance Tests เช่น

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

มันช่างดูขัดแย้งกับเป้าหมายของ Automated Tests นะ ว่าไหม ?

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

ถ้าใครอยู่ในสภาวะนี้ แสดงว่า สิ่งที่ทำอยู่นั้นไม่น่าจะถูกต้อง หรือ เหมาะกับทีม หรือ งาน นะ !!

ดังนั้นจึงข้อแนะนำสิ่งที่ควรทำ สำหรับ Automated Acceptance Test

1. Acceptance test กับ End-to-End test (e2e) มันต่างกันนะ

หลาย ๆ คนคิด และ เข้าใจว่า มันคือสิ่งเดียวกัน เพราะว่า มันแยกออกจากกันได้ยากมาก ๆ !! แต่ในความเป็นจริงมันต่างกันนะ มาดูความแตกต่างของทั้งสองกันหน่อย Automated Acceptance Test นั้นจะมีเป้าหมาย และ การทดสอบเพียงอย่างเดียวเท่านั้น จะทำการทดสอบไปยัง function การทำงานนั้น ๆ โดยตรง หรือทดสอบไปยัง API หรือ End point ต่าง ๆ เลย ตัวอย่างเช่น Given I am a new user When I visit the product detail Then I see detail of product A Automated End-to-End Test นั้นจะครอบคลุม หรือเป็นเส้นทางการทำงานของระบบตั้งแต่ต้นทางจนถึงปลายทาง เหมือนกับการใช้งานของผู้ใช้งาน ซึ่งควรคำกำหนดจำนวน test case ไว้เลย ไม่ให้เยอะจนเกินไป เนื่องจากใช้เวลาการทดสอบสูงมาก ๆ ซึ่งต้องพึงระวังอย่างมาก !! ตัวอย่างเช่น Given I am a new user When I visit the product detail And I add product to my order Then I see my basket When I choose and enter my payment detail And I choose my shipping Then I see my order confirmation

ดังนั้นควรแยกให้ชัดเจนนะครับ ซึ่งเราควรเน้นไปที่ Automated Acceptance Test เป็นหลัก เพราะว่ามันทำงานได้รวดเร็ว และ มีเป้าหมายที่แน่ชัด

2. ให้เน้นว่าต้องการทำอะไร ไม่ใช่เขียนตามระบบงาน

เวลาเขียน scenario ต่าง ๆ ต้องไม่ลงรายละเอียดมากจนเกินไป เนื่องจากสิ่งที่เราเขียนมานั้น ต้องให้คนอื่น ๆ เช่น ฝ่าย business อ่าน และ เข้าใจ พูดง่าย ๆ คือ เขียนให้คนทั่วไปอ่านรู้เรื่อง รวมทั้งไม่ยาวจนเกินไป ตัวอย่างเช่น Given I am a customer When I go to the promotion page And I click product A And I click shipping Then I see shipping equals 0 THB เป็นตัวอย่างที่เขียนถึงรายละเอียดของระบบ หรือการพัฒนามากจนเกินไป หรือผูกติดกับ technical มากเกินไป บ่อยครั้งเมื่อเปลี่ยน User Interface กลับมีผลกระทบกับ test อีกด้วย !! น่าจะเขียนให้ตรงกับความต้องการของเรา นั่นคือ ต้องการดูว่า product มันฟรีค่าจัดส่งนะ ตัวอย่างเช่น Given I am a customer When I visit the promotion page Then I see free shipping

ดังนั้นในการเขียน scenario และ feature ควรเน้นไปที่ว่า ระบบทำอะไร (What) มากกว่าระบบทำงานอย่างไร (How) มันจะทำให้เราอ่านง่าย เข้าใจได้ง่าย แถมเปลี่ยนแปลงได้ง่ายอีกนะครับ

3. การทดสอบต้องเป็นอิสระต่อกัน

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

4. Automated test มันต้องช่วยลดการทดสอบแบบ manual test ลงไปนะ

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

• มันช่วยลดเวลาในการทดสอบลงไหม ?
• มันช่วยลดเวลาการทำ regression test ลงไหม ?
• มันช่วยเพิ่มคุณภาพให้กับระบบไหม ?
• มันช่วยเรื่อง time to market ไหม ?
• มันช่วยเพิ่มความมั่นใจต่อระบบไหม ?
• มันช่วยทำให้คุณมั่นใจเมื่อต้อง release ระบบไหม ?

คำตอบมันอยู่ที่คุณแล้ว และผมเชื่อว่า manual test ยิ่งเป็น regression test แล้ว คงไม่มีใครชอบหรอกนะ !!

5. หน้าที่รับผิดชอบในการดูแล Automated Test เป็นของทุกคนในทีมนะ

ให้เชื่อเถอะว่า การสร้างทีมเพื่อแยกออกมาเขียน Automated test โดยเฉพาะ มันไม่เคยได้ดี และ มีประสิทธิภาพที่ดีเลย เพราะว่า ทีมนี้สนใจเพียงเรื่องการทดสอบ ไม่สนใจระบบเลย ดังนั้น ถ้าทุกคนในทีมรับผิดชอบเรื่อง คุณภาพ หรือ (Quality Build-in) มันจะได้ผลลัพธ์ที่แจ่มแมวมาก ๆ ซึ่งมันอาจจะยากสำหรับการเริ่มต้น แต่ผลในระยะยาวมันดีอย่างแน่นอน

การทำงานร่วมกันเป็นทีม มันสำคัญอย่างมาก

6. ทำการทดสอบทุกครั้งที่มีการเปลี่ยนแปลง

มีคำถามว่า จะทดสอบ Automated test บ่อยเท่าไร ? ตอบได้เลยว่า ทุกครั้งที่มีการเปลี่ยนแปลง ไม่ว่าจะเป็น source code ไม่ว่าจะเป็นชุดการทดสอบ หรืออะไรก็ตามที่เกี่ยวข้องกับระบบ จะไม่รอ ให้ครบ 10 test case ก่อน จึงจะทดสอบ จะไม่รอ ให้ถึงเวลา 16.00 น. ก่อน จึงจะทดสอบ เพราะว่า สิ่งที่เราต้องการคือ feedback ของการทดสอบที่รวดเร็ว เราจะได้รู้ว่าสิ่งที่เราเปลี่ยนแปลงไปนั้น มันกระทบต่อการทำงานหรือไม่นั่นเอง ซึ่งมันทำให้คุณมั่นใจทุกการก้าวเดิน

7. ต้อง run test แบบขนาน (Parallel)

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

8. ทำการ run Automated End-to-End Test บน production ไปเลย !!

เนื่องจากการทำงาน Automated test ไม่ว่าจะเป็น Acceptance test และ End-to-End test ล้วนมีค่าใช้จ่ายที่สูง ดังนั้น สิ่งที่ได้กลับมาจากการลงทุนต้องมีคุณค่าสมเหตุสมผลด้วยเช่นกัน เช่น การ run Enn-to-End test หลักจากที่ทำการติดตั้งระบบบน production server เพื่อทำให้มั่นใจในการ deploy ว่ามัน work นะ ซึ่งเป็นคุณค่าที่คุณคู่ควรใช่หรือเปล่า ?

ดังนั้นสิ่งที่คุณ และ ทีมต้องค้นหาก็คือ คุณค่าที่ได้จากชุดการทดสอบที่สร้างขึ้น ทั้งการ run บน dev, testing, staging และ production

สุดท้าย อย่าหยุดที่จะทำสิ่งต่าง ๆ เหล่านี้

เนื่องจากทุก ๆ อย่างมันคือ การทดลอง เพื่อทำให้เราเข้าใกล้เป้าหมายที่ตั้งไว้ของการทำ Automated testing ซึ่งคุณต้องเรียนรู้ เพื่อ Inspect and Adapt ต่อไปครับ

[แปล] 5 DEADLY BELIEFS THAT LIMIT LEADERS 

December 1, 2015, 12:04 am

≫ Next: ทำความเข้าใจกับ Data Mining Process กันหน่อย

≪ Previous: สิ่งที่ควรทำสำหรับ Automated Acceptance Testing

$

0

0

อ่านบทความเรื่อง 5 DEADLY BELIEFS THAT LIMIT LEADERS แล้วโดนใจมาก ๆ โดยเฉพาะจาก comment ที่พูดคุยกันอย่างออกรสชาติ จึงนำมาแปลตามความเข้าใจนิดหน่อย มาดูกันว่า ความเชื่อที่ผิด ๆ มีอะไรบ้าง ?

การกระทำต่าง ๆ ของคนเราล้วนมาจากความเชื่อ

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

1. The problem is out there

มันคือ ความไม่รับผิดชอบต่อสิ่งที่เกิดขึ้น มักจะโยน มักจะโบ้ย มักจะไม่สนใจ ประมาณว่า ความดีเอาเข้าตัว ความชั่วให้คนอื่น คนเหล่านี้มักจะพูดว่า

• ฉันจะไม่ทำอะไรในเรื่องนี้
• มันคือปัญหาของคุณ
• มันไม่ใช่หน้าที่
• ฉันไม่สามารถแก้ไขได้
• พวกคุณไม่เข้าใจฉัน
• ฉันไม่ว่าง งานเยอะ

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

Nothing changes until you change

2. Leaders have power to change others

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

3. Working harder is the answer

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

4. Reserve gratitude and honor for special occasions

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

5. It’s not that bad

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

สุดท้ายแล้ว ฝากไว้ว่า Right belief drives effective action

ยังไม่จบ จาก comment มีเรื่องที่น่าสนใจอีก

ไม่ว่าจะเป็น

• I know more than anyone else หรือ เชื่อว่าฉันรู้มากกว่าคนอื่น ๆ
• I always right hat หรือ เชื่อว่าเป็นฝ่ายถูกเสมอ
• We don’t have time to consider this – we need to get going ง่าย ๆ คือ ไม่มีเวลามาพิจารณานั่นเอง
• I have to be the super-hero leader !!

คำถาม

คุณคิดว่า มีความเชื่อที่ผิด ๆ อะไรอีกบ้าง ? และมีความเชื่ออะไรบ้างที่จะช่วยปรับปรุง และ พัฒนาให้ Leader ดีขึ้นกว่าเดิม ?  

ทำความเข้าใจกับ Data Mining Process กันหน่อย

December 1, 2015, 10:59 pm

≫ Next: ไม่มีใครอยากเขียน code แย่ ๆ หรอกนะ

≪ Previous: [แปล] 5 DEADLY BELIEFS THAT LIMIT LEADERS 

$

0

0

ในปัจจุบันนั้น พบว่ามีการนำ Data Mining มาใช้เยอะขึ้นมาก ๆ แต่ส่วนใหญ่ที่พบเจอ

มักจะคุยกันเฉพาะเครื่องมือที่ใช้งาน  มากกว่าที่จะพยายามทำความเข้าใจกับข้อมูล และ business domain

หรือความรู้ต่าง ๆ ที่จำเป็นต่อการวิเคราะห์ข้อมูล ซึ่งนี่คือปัญหาที่กำลังเกิดขึ้นอยู่ในปัจจุบัน ดังนั้น เรามาเรียนรู้ และ เข้าใจเกี่ยวกับ Data Mining Process กันหน่อย ว่ามันเป็นอย่างไรบ้าง ?

อ้างอิงจาก CRISP-DM (Cross-Industry Standard Process for Data Mining)

ประกอบไปด้วยขั้นตอนดังนี้

1. Business understanding
2. Data understanding
3. Data preparation
4. Modeling
5. Evaluation
6. Deployment

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

โดยขั้นตอนที่มีความสำคัญมาก คือ Business understanding และ Data understanding

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

อ่านไปเจอตัวอย่างที่น่าสนจาก ThinkToStart

ยกตัวอย่างข้อมูลชุดนี้ เป็นข้อมูลการสมัครเข้าเรียนใหม่ของมหาวิทยาลัย เพื่อใช้ในการทำนายว่าจะสมัครเข้าเรียนหรือไม่ ? แสดงดังรูป ลองคิดดูสิว่า ถ้ามีข้อมูลมาเช่นนี้ โดยที่คุณไม่มีความรู้ทางด้านการศึกษาเลย มันจะเกิดอะไรขึ้นบ้าง ? ชีวิตของคุณจะพบปัญหาอีกเยอะหรือไม่ ? ข้อมูลมันมีเยอะพอควร เช่น ที่อยู่ คณะที่สนใจเรียน และ GPA เป็นต้น สิ่งที่คุณจำเป็นต้องรู้ก็คือ ข้อมูลในแต่ละ column นั้นมันคืออะไร ? ข้อมูลในแต่ละ column นั้นมันมีความสัมพันธ์กันอย่างไร ? ตัวอย่างเช่นใน column F คือ Admitted (อนุญาตให้สมัครได้) พบว่ามีข้อมูลแถวที่ 2 และ 8 บอกว่า ทั้งสองจะไม่สมัครเข้าเรียน ? คำถาม ทำไมถึงไม่ได้สมัครเข้าเรียนล่ะ หรือ มหาวิทยาลัยนี้ไม่ดี ? คำตอบ ถ้าเรามีความรู้ใน business domain ของการศึกษา จะพบว่าคนที่ไม่ได้รับอนุญาตให้สมัครเรียน จะไม่สามารถเข้ามายังกระบวนการนี้ได้เลย !! แสดงว่า column F นี้มันไร้ค่ามาก ๆ ไม่ควรเป็นข้อมูลที่ใช้ในการตัดสินใจใด ๆ เลย ดังนั้น จึงตัดทิ้งไปซะ นี่คือตัวอย่างที่คุณควรมีความเข้าใจใน business domain นั้น ๆ เป็นอย่างดี และการทำความเข้าใจก็ไม่จำเป็นต้องใช้เครื่องมือใด ๆ เลย

วันนี้คุณเข้าใจกับ business domain ที่คุณทำอยู่หรือไม่ ? ลองตอบคำถามกับตัวเองก่อนนะ

ไม่มีใครอยากเขียน code แย่ ๆ หรอกนะ

December 2, 2015, 8:26 am

≫ Next: สิ่งที่ Developer ชอบหลงลืม สำหรับการพัฒนา Mobile application

≪ Previous: ทำความเข้าใจกับ Data Mining Process กันหน่อย

$

0

0

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

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

นั่นคือ การเข้าไปทำงาน พูดคุยกันอย่างใกล้ชิด โดยการพูด และ คำถามต่าง ๆ ต้องเป็นไปอย่างสร้างสรรด้วยนะ เพื่อไม่ทำให้อีกฝ่ายเจ็บใจ และ เจ็บปวด ตัวอย่างเช่น แทนที่จะไปถามว่า method นี้ทำไมมันแย่จัง code ยาวมาก ๆ เปลี่ยนมาถามแบบนี้ดีไหม ช่วยด้วย ๆ เราเจอ Bug จาก code ใน method นี้ ในใจก็คิดว่า method นี้มันยาวมาก ๆ ไม่รู้ว่ามันทำงานอย่างไรบ้าง ? ดังนั้น มาช่วยไล่ code และ อธิบายหน่อยสิ ซึ่งเป็นการ pair programming กันนั่นเอง เพื่อหาปัญหา และ แก้ไขต่อไป เมื่อทำงานร่วมกันไปได้สักพัก แทนที่จะพูด หรือ บอกว่า method นี้มันยาวมาก ๆ ก็ให้เปลี่ยนเป็นคำถามดีกว่า เช่น method นี้ดูดีเลยนะ มีการทำงานหลายอย่างเลย มันต้องใช้เวลาเท่าไรกว่าจะเข้าใจการทำงานของมันนะ ? เพื่อนร่วมงานอาจจะตอบกลับมาว่า น่าจะ 4-5 ชั่วโมงละมั้ง ลองถามต่อไปสิว่า ถ้า method นี้มันเล็กลง จะต้องทำอย่างไรดี ? ตรงนี้เป็นคำถามปลายเปิด เพื่อให้แต่ละคนช่วยกันคิดวิธีการแก้ไข เป็นแนวทางในการทำงานร่วมกัน แทนที่จะมาทำการโต้เถียงกัน ซึ่งมันเสียเวลาไปอย่างไร้ประโยชน์สุด ๆ จำไว้ว่า อย่าถามคำถามที่จะนำพาไปสู่วิธีการที่คุณคิดไว้แล้วนะ !! ต้องเก็บอาการกันหน่อยนะ การเปลี่ยนแปลง และ ปรับปรุงจะเป็นไปอย่างค่อยเป็นค่อยไป แต่มีขอบเขตของเวลานะ

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

เมื่อความสัมพันธ์ต่าง ๆ เริ่มดีแล้ว ต่อไปให้เริ่มขยายผลออกไป

นั่นคือ เริ่มแนะนำแนวทาง แนวปฏิบัติใหม่ ๆ เข้าไป เช่นเริ่มให้ขยายผลไปยังคนอื่น ๆ บ้าง นั่นคือการสลับคู่ pair นั่นเอง รวมไปถึงเริ่มมี sharing session ของทีม เช่น การทำงานเป็นกลุ่ม เช่น mop programming การแบ่งปันเรื่อง refactoring สำหรับการปรับปรุง code โดยเรื่องต่าง ๆ เหล่านี้มันคือ การสร้างความสัมพันธ์ของคนภายในทีม การสร้างความไว้เนื้อเชื่อใจของคนภายในทีม ซึ่งจะต้องดูแลรักษาให้ดี และ เพิ่มขึ้นอย่างต่อเนื่อง เพื่อทำให้ทุกคนออกจาก confort zone แบบเนียน ๆ แถมได้ code ที่แจ่ม ๆ ออกมาอีกด้วย

แต่ต้องมีความอดทนสูง ให้กลั้นใจ และ เตรียมตัวให้พร้อมมาก ๆ นะ

สุดท้ายแล้ว

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

สิ่งที่ Developer ชอบหลงลืม สำหรับการพัฒนา Mobile application

December 3, 2015, 12:28 am

≫ Next: มาสร้าง Java 8 Web Server ด้วย Spark กัน

≪ Previous: ไม่มีใครอยากเขียน code แย่ ๆ หรอกนะ

$

0

0

ปัจจุบันการพัฒนา Mobile app นั้น ทีมพัฒนาจะโดนกดดันอย่างหนัก ไม่ว่าจะเป็นการส่งมอบประสบการณ์ที่ดีมาก ๆ ให้ผู้ใช้งาน ไม่ว่าจะเป็นต้องการ review ด้วย 5 ดาว ซึ่งสิ่งเหล่านี้มันทำให้ทีมพัฒนาเร่งรีบ ทำให้ลืมบางสิ่งที่สำคัญไป

1. ลืมไปว่า เราทำการสร้าง App นี้ไปทำไม เพื่ออะไร ?

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

Mobile is really about supporting your overall business objective

2. ลืมเรื่องของ Security !!

ทีมพัฒนาสนใจแต่การสร้าง App ที่ดี ๆ สนใจแต่ความสะดวกสบายในการใช้งานของผู้ใช้ จนลืม และ อาจจะถูกลืมไปเลยก็คือ เรื่อง Security ของ App มีรายงานจาก BlueBox สำหรับ Travel Mobile App พบว่า 40% ของ Android app 60% ของ iOS app มีปัญหาเรื่องความปลอดภัย โดยเฉพาะเรื่องข้อมูลส่วนตัวของผู้ใช้งาน !!

3. ลืมไปว่า ต้องปรับปรุงคุณภาพของ App อยู่อย่างเสมอ

ทีมพัฒนาส่วนใหญ่คิดว่า เมื่อทำการปล่อย App ให้ผู้ใช้งานไปแล้ว ถือว่างานจบ ไม่ต้องสนใจอะไรแล้ว แต่ในความเป็นจริงมันตรงกันข้ามเลย เนื่องจาก งานมันเพียงเริ่มต้นเท่านั้น ทีมพัฒนาจะต้องทำการปรับปรุง และ เพิ่มเติมความสามารถต่างๆ เข้าไปอยู่อย่างสม่ำเสมอ เราไม่มีทางรู้ว่าแนวโน้มของผู้ใช้งานเป็นอย่างไร ดังนั้น ต้องทำการรักษาคุณภาพไว้อย่างสม่ำเสมอ นั่นคือเรื่องการทำ performance test นั่นคือเรื่องการทำระบบ monitoring นั่นคือเรื่องของการ update App อย่างสม่ำเสมอ

4. ลืมเรื่องความพึงพอใช้ของผู้ใช้งาน

ในการพัฒนา Mobile app นั้น สร้างขึ้นมาเพื่อผู้ใช้งาน ดังนั้น คุณควรให้ผู้ใช้งานในกลุ่มเป้าหมายมาใช้งาน ไม่ใช่ให้ผู้ใช้งานทุก ๆ กลุ่ม มันหมายถึง คุณต้องมีกลุ่มเป้าหมายของ App ก่อนนะ นั่นคือข้อ 1 ซึ่งมักจะหลงลืมไปอีก !! ดังนั้นต้องเข้าใจและกำหนดกลุ่มเป้าหมาย จากนั้นจึงสร้าง App ให้ตรงกับกลุ่มนั้น ๆ จะทำให้ผู้ใ้ชงานพึงพอใจมากขึ้น ซึ่งมันส่งผลต่อจำนวนผู้ใช้งาน และ ผลการ review app อีกด้วย

5. More feature == More success

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

ลองถามตัวเราเองสิว่า เราลืมสิ่งใดไปบ้าง ?

---

มาสร้าง Java 8 Web Server ด้วย Spark กัน

December 3, 2015, 7:04 am

≫ Next: สวัสดี PHP 7.0.0 อย่างเป็นทางการ

≪ Previous: สิ่งที่ Developer ชอบหลงลืม สำหรับการพัฒนา Mobile application

$

0

0

สำหรับ Java Developer นั้น การจะสร้าง web application นั้นมันยากเย็นมากนัก ทั้งวิธีการเขียน code ที่เยอะ ทั้ง library ต่างๆ ที่ใช้งาน ทั้ง Web server หรือ Application server ตลอดจนการ deploy เพื่อทดสอบ นี่คือกระบวนการพัฒนาแบบคร่าว ๆ แน่นอนว่า feedback loop มันช้ามาก ๆ แต่หลาย ๆ คนก็ยังคงทำกันอยู่ ทำไมนะ ? ดังนั้น เรามาลองสร้าง Web Server และ Web Application ง่าย ๆ ด้วย Spark กันบ้างสิ ว่ามันช่วยลดงาน และ เพิ่มความเร็วในการพัฒนาบ้างไหม ?

ปล. Spark ที่พูดถึงคือ Spark Java นะครับ ไม่ใช่ Apache Spark !! เขียนครั้งแรกเมื่อปีที่แล้ว แต่ในปีนี้มันเปลี่ยนไปเยอะพอควร จึงนำมาเขียนใหม่

ทำความรู้จักกับ Spark กันหน่อย

เป็น framework เล็ก ๆ สำหรับการสร้าง Java web application โดยทำงานบน Java 8 ขึ้นไปเท่านั้น ได้รับแรงบันดาลใจมาจาก Sinatra มีเป้าหมายเพื่อ ทำให้เราสามารถพัฒนา web application ได้ง่าย และ เร็วขึ้น นั่นคือ Java Developer ใช้พลังงานน้อยลง แต่ได้งานออกมารวดเร็วกว่าเดิม มันช่วยเพิ่ม productivity เยอะเลย ที่สำคัญเอาไปพัฒนาในรูปแบบของ microservice ง่ายด้วยนะสิ ปล. ภาษาอื่น ๆ เขามีมานานแล้วนพ !!

ดังนั้นเราลองมาสร้าง Web application ด้วย Spark กันดีกว่า

ตามธรรมเนียมต้องเริ่มที่ Hello World นะสิ ขั้นตอนการสร้างก็ไม่ยากเป็นดังนี้

ขั้นตอนที่ 1 ตัวอย่างสร้าง project เป็น Maven project

ดังนั้นไฟล์ pom.xml ซึ่งประกอบไปด้วยส่วนที่น่าสนใจ คือ

• Dependency ที่ใช้งานคือ spark-core
• กำหนดการ build ของ Maven ให้ทำงานตามที่เราต้องการทั้งเวอร์ชันของ Java และการ package เป็นไฟล์ JAR ชื่อว่า demo_api.jar
• กำหนด Main class คือ ServerAPI เป็น class สำหรับใช้ Start Web Server นั่นเอง

มีหน้าตาแบบนี้ [gist id="599a9379d47c2f0f648a" file="pom.xml"]

ขั้นตอนที่ 2 สร้าง class ServerAPI ขึ้นมา

เป็น class สำหรับ Start Web Server ซึ่งเราสามารถกำหนด endpoint ต่าง ๆ ของ web ได้เลย จากตัวอย่างจะรับ request ผ่าน HTTP GET มาที่ / และจะส่ง response กลับไปว่า Hello World กลับไป เขียนได้ดังนี้ [gist id="599a9379d47c2f0f648a" file="APIServer.java"]

ขั้นตอนที่ 3 จะช้าอยู่ทำไม run สิครับ

แน่นอนว่า run ด้วย maven สิ ดังนี้ $mvn clean package ผลที่ได้คือจะมีไฟล์ demo_api.jar อยู่ใน folder target จากนั้นทำงาน run demo_api.jar ซะ ดังนี้ $java -jar demo_api.jar ผลที่ได้เป็นดังนี้ [Thread-0] INFO org.eclipse.jetty.util.log - Logging initialized @200ms [Thread-0] INFO spark.webserver.JettySparkServer - == Spark has ignited ... [Thread-0] INFO spark.webserver.JettySparkServer - >> Listening on 0.0.0.0:4567 [Thread-0] INFO org.eclipse.jetty.server.Server - jetty-9.3.z-SNAPSHOT [Thread-0] INFO org.eclipse.jetty.server.ServerConnector - Started ServerConnector@5c4ca375{HTTP/1.1,[http/1.1]}{0.0.0.0:4567} [Thread-0] INFO org.eclipse.jetty.server.Server - Started @327ms จะสังเกตได้ว่า Web server จะทำการ start ขึ้นมาที่ port 4567 ทดสอบผ่าน browser หน่อยสิ ด้วย URL = http://localhost:4567/ ได้ผลดังรูป เพียงเท่านี้ก็สามารถสร้าง Java Web Application ได้แล้วนะ

แต่ว่ามันง่ายไปนะ ดังนั้นเราลองมาสร้าง REST API ใช้งานกันสักหน่อยดีกว่า

พอดีเขียน web ไม่เป็น เขียนเป็นแต่ REST API นะ ความต้องการ คือ เพิ่มข้อมูลพนักงานใหม่เข้าไปในระบบ สำหรับ REST API ต้องกำหนดดังนี้

• Request ต้องผ่าน HTTP POST
• Path ที่ใช้คือ /employee

ดังนั้นเรามาเขียน code กันดีกว่า เริ่มจากทำการเพิ่ม path ใน APIServer.java [gist id="599a9379d47c2f0f648a" file="APIServer2.java"] สังเกตได้ว่าในส่วนของ post มันจะแตกต่างออกไป ซึ่งเราสามารถเขียนได้หลายแบบ แต่ถ้าให้สวยงาม เราควรแยกออกไปเป็น class ใหม่ ซึ่ง class AddEmployee นั้นจะ extends จาก class Route ของ Spark ดังนี้ [gist id="599a9379d47c2f0f648a" file="AddEmployee.java"] จากนั้นลองทำการทดสอบผ่าน HTTP POST ดู เพียงเท่านี้ก็เรียบร้อย สำหรับการสร้าง REST API สำหรับการเพิ่มพนักงานใหม่ด้วย Spark ง่ายไหมนะ ? สามารถดู code ตัวอย่างเพิ่มเติมได้ที่ GitHub::Up1:Spark-Java-Demo

สวัสดี PHP 7.0.0 อย่างเป็นทางการ

December 3, 2015, 9:40 pm

≫ Next: สรุปเทคนิคที่ชอบใน session Android Studio for Experts

≪ Previous: มาสร้าง Java 8 Web Server ด้วย Spark กัน

$

0

0

วันที่ 3 พฤจิกายน 2558 ทีมพัฒนา PHP ได้ปล่อย PHP 7.0.0 ออกมาอย่างเป็นทางการ เป็นการเปลี่ยนแปลงครั้งยิ่งใหญ่ ทั้งตัวภาษา และ Zend engine ซึ่งมีการเพิ่มเติม เปลี่ยนแปลง และ ปรับปรุง feature มากมาย มาดูกันว่ามีอะไรบ้าง มีสถิติที่น่าสนใจจากทีมพัฒนา

10033 commits 48 RFCs 189 contributors

1. ปรับปรุงประสิทธิการทำงาน

ซึ่งบอกว่า PHP 7.0.0 นั้นทำงานเร็วกว่า PHP 5.6 ประมาณ 2 เท่า ลดจำนวน memory ที่ใช้งาน มาดูข้อมูลการทดสอบ performance กันหน่อย จาก Turbocharging the Web with PHP 7

2. มาดู feature ใหม่ ๆ ที่น่าสนใจกันบ้าง

เคยเขียนอธิบาย feature ใหม่ของ PHP 7 ไว้บ้างแล้ว มาดู feature แปลก ๆ กันบ้าง Null Coalesce Operator มันคือ shorthand operator ของ isset() นั่นเอง ตัวอย่าง code เป็นดังนี้ [gist id="cbc143a8b8b25581b2ff" file="null_coalesce_operator.php"] Combined Comparison Operator หรือ Spaceship operator ( <==> ) ใช้สำหรับการเปรียบเทียบข้อมูล ซึ่งผลการทำงานจะออกมาเป็นตัวเลข 3 ค่า ดังนี้

• เลขจำนวนเต็มบวก นั่นคือข้อมูลทางซ้ายมากกว่าทางขวา
• ศูนย์ นั่นคือข้อมูลทางซ้ายและทางขวาเท่ากัน
• เลขจำนวนเต็มลบ นั่นคือข้อมูลทางซ้ายน้อยกว่าทางขวา

ตัวอย่าง code เป็นดังนี้ [gist id="cbc143a8b8b25581b2ff" file="spaceship_operator.php"] ข้อจำกัดคือ ไม่สามารถใช้กับ Object ได้นะ และไม่สามารถเปรียบเทียบข้อมูลต่อกันได้นะ เช่น 1 <==> 2 <==> 3 Scalar Type Declarations ใช้สำหรับการบังคับให้ชนิดข้อมูลที่ส่งไปยัง method ต่าง ๆ ถูกต้อง ซึ่งมีอยู่ 2 mode คือ

• Coercive เป็น default คือส่งข้อมูลชิดอะไรไปก็ได้
• Stricts จะเข้มงวดนั่นเอง

ในความเป็นจริง Stricts มันน่าจะเป็น default นะ !!

มาดูตัวอย่างการใช้ Stricts mode ดีกว่า ถ้าส่งข้อมูลไปผิดชนิดที่ประกาศไว้จะเกิด Exception ทันที [gist id="cbc143a8b8b25581b2ff" file="scalar_type_stricts.php"] กำหนดค่าคงที่ใน define() ได้ ใน php 5.6 นั้นสามารถทำได้ด้วยการใช้ keyword const ส่วนใน php 7.0.0 สามารถกำหนดได้ใน define() แล้ว ตัวอย่าง code เป็นดังนี้ [gist id="cbc143a8b8b25581b2ff" file="define_constant.php"]

อีกอย่างที่ชอบมาก ๆ คือ Exception ของ Engine

ซึ่ง engine ตัวใหม่จะพยายามแปลง error ต่าง ๆ ไปอยู่ในรูปแบบของ Exception เพื่อทำให้ดักจับ error ต่าง ๆ ได้ง่ายขึ้น รวมทั้งสามารถ custom exception ตามที่ต้องการได้อีกด้วย นี่มันภาษา Java เลยนะเนี่ย

ส่วน feature ที่มัน deprecated กับเอาออกไปก็เยอะนะ

เช่น

• PHP 4 constructor ที่เป็น __construct() ก็ถูก deprecated ไปแล้ว ถ้าใช้งานจะแจ้งว่า E_DREPRECATED ส่วนใน PHP 8 เอาออกแน่นอน
• Warning date.timezone ถูกเอาออกไปแล้ว ดีใจอย่างมาก
• PHP tag ใช้ได้อันเดียวนะ คือ standard ของมัน เพื่อลดความสับสนวุ่นวาย
• ไม่สามารถกำหนดชื่อของ argument ใน method ซ้ำได้แล้ว
• Server API (SAPI) ถูกเอาออกไปจนสิ้น
• feature ที่มัน deprecated มาแล้ว ถูกเอาออกไปหมด

Source code ตัวอย่างอยู่ที่ Github::Up1::Hello PHP7 ขอเชิญ Download มาใช้งานกันได้ที่ PHP 7 Download และเชิญ Migrate กันได้แล้วนะ รับรองตายเพียบ !!

พร้อมกับ PHP 7.0.0 กันหรือยัง ? หรือว่า PHP 5.6 ก็ยังไม่ ใช้กัน !!

สวัสดี PHP 7.0.0 +_+ Reference Websites http://www.sitepoint.com/learn-php-7-find-out-whats-new-and-more/ https://github.com/tpunt/PHP7-Reference

สรุปเทคนิคที่ชอบใน session Android Studio for Experts

December 4, 2015, 8:37 am

≫ Next: 3 หัวใจหลัก สำหรับการทำ Code Review

≪ Previous: สวัสดี PHP 7.0.0 อย่างเป็นทางการ

$

0

0

จากงาน Android Dev Summit 2015 นั้น มีหัวอีกหัวข้อที่น่าสนใจ คือ Android Studio for Experts เป็น session ยาวประมาณ 1 ชั่วโมง แต่คิดว่าคุ้มค่ามาก ๆ สำหรับ Tips และ เทคนิคต่าง ๆ ที่ได้รับ สำหรับการใช้งาน Android Studio 2.0 preview ดังนั้น จึงสรุปในสิ่งที่ตัวเองสนใจไว้นิดหน่อย ปล1. ผมคิดว่า Session นี้น่าจะเปลี่ยนชื่อว่า 100 เหตุผลของ Android developer ที่ควรเปลี่ยนมาใช้ Android Studio ปล2. ผมใช้เครื่อง Mac นะ

Code completion

เริ่มด้วย Insert completion โดยปกติเมื่อเรากดปุ่ม control + spacebar เพื่อให้แนะนำ code ถ้าเราต้องการอะไรก็เลือกด้วยการกดปุ่ม Enter ซึ่งผลที่ได้มันคือการเพิ่ม code ต่อท้ายจากจุดที่ cursor อยู่ ทำให้ code ที่ได้มันผิด ดังนี้ ดังนั้นแนะนำให้ใช้ปุ่ม TAB แทน Enter นะ มันจะทำการแทนที่ด้วยสิ่งที่เราเลือก แสดงการใช้งานดังนี้

ต่อมาเรื่อง Smart code completion

จากเดิมเราใช้ control + spacebar และ . เพื่อให้แนะนำ code และ method ซึ่งสิ่งที่แนะนำมาอาจจะไม่ตรงกับ code ที่กำลังเขียนอยู่ เพราะว่า มันไม่ได้สนใจ context ที่เราทำงานอยู่มากนัก ดังนั้นแนะนำให้ใช้ shift + control + spacebar แทนนะ แสดงการใช้งานดังนี้

จากนั้นมาเรื่องของ Intention ซึ่งทำให้ชีวิตง่ายขึ้นเยอะ

มันอาจจะทำให้เราขี้เกียจก็ได้นะ แสดงการใช้งานดังนี้

เพื่อความสนุกสนานมาใช้งาน Live template กันดีกว่า

เริ่มจากการสร้าง for loop แบบง่าย ๆ ใช้ fori จากนั้นลองสร้าง for loop สำหรับตัวแปร Collection กันดู colection_variable.fori แสดงการใช้งานดังนี้

มาสนุกกันอีกสักหน่อยกับ Logging กันบ้าง

ซึ่งมี shortcut key สั้น ๆ สำหรับเขียน code เกี่ยวกับ log ให้มันเขียนง่าย ๆ และ เร็ว ๆ กันหน่อย ซึ่งสามารถใช้

• logi = log information
• logt = log TAG คือการสร้างตัวแปร TAG ขึ้นมาให้อัตโนมัติ

แสดงการใช้งานดังนี้ จากนั้นถ้าต้องการเขียน log ของข้อมูลที่ส่งเข้ามา และ ผลการทำงาน เราสามารถใช้ logm และ logr ได้เลย แสดงการใช้งานดังนี้

สามารถเขียน และ run Unit test และ Instrumentation test ไปพร้อม ๆ กันได้

ไม่ต้องสลับ build variants ไปมาอีกแล้ว รวมทั้งเมื่อทำการ refactor code ที่ง่ายขึ้น ซึ่งสามารถเข้าไปเปิด feature นี้ได้ที่ Preferences > Build, Execution, Deployment > Build Tools > Gradle > Experimental แสดงดังรูป เท่านี้แหละสำหรับ feature ที่มีประโยชน์มาก ๆ ต่อตัวผม

แต่ยังมีเรื่องอื่น ๆ ที่น่าสนใจอีก เช่น

• Search and replace
• การจัดการ xml และ resource ต่าง ๆ
• การใช้งาน debugger
• Gradle
• Testing มันสั้นไป

ลองไปดูจาก VDO ข้างต้น ยิ่งเรียนรู้ ก็ยิ่งรู้ว่าไม่รู้เยอะมาก

3 หัวใจหลัก สำหรับการทำ Code Review

December 5, 2015, 7:33 pm

≫ Next: ทำความรู้จักกับ Hermetic Testing กันหน่อย

≪ Previous: สรุปเทคนิคที่ชอบใน session Android Studio for Experts

$

0

0

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

สิ่งที่จะช่วยทำให้คุณ และ ทีม ประสบความสำเร็จ

ในการนำ Code Review มาใช้งานนั้น ต้องเตรียม 3 ส่วนนี้ให้พร้อม

1. Team
2. Process
3. Tool

มาดูรายละเอียดกันหน่อย

1. Team

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

ลองคิดดูสิว่า ถ้าทีมไม่รู้ และ ไม่เข้าใจสิ่งต่าง ๆ เหล่านี้แล้ว มันจะเกิดอะไรขึ้นบ้าง ?

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

2. Process

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

• ทำก่อนการ commit code (pre-commit)
• ทำหลังจากการ commit code (post-commit)
• ทำเมื่อมี Pull request เข้ามา
• ทำใน feature branch ก่อนทำการ merge

ดังนั้นคุณต้องคิด และ ถาม ตัวคุณเองและทีมก่อนสิว่า จะทำเมื่อใด ?

อย่าลืมว่า การพูดคุยเรื่องขั้นตอนการทำงาน ต้องมาจากทุกคนในทีมนะครับ รวมทั้งอย่างให้ใครเป็นคอขวดในการทำ Code Review โดยเด็ดขาด

เช่น

• คนที่ทำการ review code นั้นควรมีอย่างน้อย 2 คนนะ
• ใช้เวลาในการทำ Code Review นานไปหรือเปล่า ?
• ชอบเลื่อน ด้วยคำว่าเดี๋ยวก่อนหรือเปล่า ?
• หาเวลาว่าง มาทำ Code Review ยากหรือเปล่า ?
• ชอบทำ Code Review หลังจากที่ code มัน deploy ไปแล้วหรือเปล่า ? (Review เมื่อมีปัญหาใช่ไหม ?)

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

3. Tool

สิ่งต่อมาคือ หาเครื่องมือที่เหมาะกับทีม กับงาน กับขั้นตอนการทำงาน

อย่าเอาเครื่องมือมากำหนดกรอบและขั้นตอนของการทำงานโดยเด็ดขาด !!

เนื่องจากเครื่องมือ มันคือสิ่งที่เติมเต็ม มันคือสิ่งที่ช่วยให้งานของเราง่ายขึ้น มิใช่ทำให้ยากขึ้น !! โดยเครื่องมือที่ดีนั้น จะทำการเก็บข้อมูลการพูดคุยเกี่ยวกับ Code Review รวมทั้งช่วยให้ขั้นตอนการทำงานมันแจ่มอีกด้วย

แต่จำไว้ว่า

ถึงแม้จะเตรียมความพร้อมทั้ง 3 แล้ว ก็ไม่ได้บอกว่าคุณจะประสบความสำเร็จ 100% นะ

แต่ถ้าคุณไม่พร้อมข้อใดข้อหนึ่งแล้ว มั่นใจได้เลยว่า Code Review ล้มเหลวอย่างแน่นอน !!

วันนี้ทีมของคุณทำ Code Review แล้วหรือยัง ? Reference Website https://dzone.com/articles/three-keys-to-code-review

ทำความรู้จักกับ Hermetic Testing กันหน่อย

December 6, 2015, 6:56 am

≫ Next: เก็บตกความรู้ที่น่าสนใจจาก session Android Testing

≪ Previous: 3 หัวใจหลัก สำหรับการทำ Code Review

$

0

0

จากงาน Android Dev Summit 2015 นั้น นั่งดู VDO เรื่อง Android Testing ซึ่งมีคำหนึ่งที่น่าสนใจมาก ๆ คือ Hermetic Testing ? เนื่องจากไม่เคยได้ยิน และ งงกับคำนี้มาก เลยทำการค้นหา และ นำมาสรุปหน่อย พบว่า มันสำคัญมาก ๆ สำหรับการทดสอบระบบงาน

Hermetic Testing มันคืออะไร ?

จาก Blog ของ Google Testing อธิบายไว้ว่า ระบบงานต่าง ๆ นั้นมันมีความซับซ้อนสูงมาก ประกอบไปด้วยส่วนการทำงานต่าง ๆ มากมาย ทั้งผ่านและไม่ผ่าน network ทั้งระบบงานภายใน และ ภายนอก ทำให้เกิดปัญหาในการทดสอบมากมาย

ดังนั้นเราทำการทดสอบระบบแบบ End-to-End testing กันอย่างไร ?

แสดงตัวอย่างระบบดังรูป คำอธิบาย ระบบที่ต้องการทดสอบนั้น ผ่าน Frontend server เมื่อผู้ใช้งานใช้งานแล้วจะต้องติดต่อไปยังระบบ backend 3 ระบบ โดยที่ End-to-End test นั้นมีเป้าหมาย เรื่องความเร็วและความน่าเชื่อถือในการทดสอบ ดังนั้นสิ่งที่เราต้องหลีกเลี่ยงคือ

• การติดต่อผ่านระบบ network ลองคิดดูสิว่า ถ้า network มันพัง การทดสอบจะเป็นอย่างไร ?
• การเรียกใช้งานระบบจากภายนอก ลองคิดดูสิว่า ถ้าระบบภายนอกมันปิดไป การทดสอบจะเป็นอย่างไร ?

เราจำเป็นต้องเปลี่ยนจาก Global data มาเป็น Local data จาก server จริง ๆ ก็ให้ทำการจำลอง หรือ สร้าง Fake server ขึ้นมา ดังนั้นทีมทดสอบของ Google จึงได้คิดและออกแบบ End-to-End testing ใหม่ โดยเปลี่ยนมาใช้ Hermetic server แทน server จริง ๆ

มาดูกันหน่อยสิว่า Hermetic Server มันคืออะไรและเป็นอย่างไร ?

พูดง่าย ๆ คือ Server in the box นั่นคือ ถ้าเราสามารถ start server ต่าง ๆ ที่เกี่ยวข้องขึ้นมาบนเครื่องเดียว แน่นอนว่า ไม่จำเป็นต้องติดต่อผ่านระบบ network รวมทั้งเป็น server ที่ทำงานตามที่เราคาดหวังไว้ด้วย เช่น สร้างมาเพื่อให้ทำงานถูก หรือ สร้างมาเพื่อให้ทำงานผิด เป็นต้น เพียงเท่านี้คุณก็มี Hermetic Server ไว้ใช้ทดสอบระบบแล้วนะ

ปล. ในบางกรณีอาจจะมีมากกว่า 1 เครื่องก็ได้นะ Server ที่สร้างอาจจะเป็นเครื่องจริง ๆ หรือ Virtual machine ก็ได้

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

• ใช้ Dependency Injection สำหรับจัดการ connection ต่าง ๆ ไปยัง server
• ข้อมูลที่จะต้องมีอยู่ในแต่ละ server
• ถ้า server มีการใช้งานข้อมูลจาก database จะต้องทำการ fake หรือใช้ In-Memory database แทนเสมอ

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

• สิ่งที่เรา fake ขึ้นมานั้น ต้องทำการตรวจสอบด้วยว่า code ของเราเรียกใช้งานได้อย่างถูกต้องหรือไม่ เช่น การใช้ mock เป็นต้น
• วิธีการเตรียมข้อมูล หรือ test data ให้มันง่าย และ สะดวก
• เตรียม logging module เพื่อช่วยตรวจสอบการทำงานในการทดสอบ

แสดงการใช้งาน Hermetic server สำรับการทดสอบดังรูป ซึ่งมันตอบโจทย์เรื่องความเร็ว และ ความน่าเชื่อถือในการทดสอบ End-to-End test โดยมีขั้นตอนการทดสอบคร่าว ๆ ดังต่อไปนี้

• ทำการ start test server ขึ้นมา
• ทำการทดสอบส่วน API ซึ่งเป็น backend ของระบบ
• ทำการทดสอบ performance test แบบเล็ก ๆ
• ทำการทดสอบ UI จากส่วนของ Frontend

ลองกลับมาที่การทดสอบ Android app หน่อยสิ

แน่นอนว่ามีปัญหาหลัก ๆ ดังนี้

• การทดสอบช้ามาก ๆ
• บ่อยครั้งการทดสอบจะ fail รวมถึงปัญหาเรื่อง memory และ CPU
• ยากต่อการ debug หรือหาข้อผิดพลาด
• ปัญหาในการเรียกใช้ระบบภายนอก เช่น Autentication server และ Backed server เป็นต้น

แสดงการทำงานดังรูป ดังนั้นจึงทำการเปลี่ยนมาใช้ Hermetic UI Testing นั่นคือการสร้าง Fake server ต่าง ๆ ขึ้นมา แสดงการทำงานดังรูป แต่ปัญหาจากวิธีการนี้ คือ การจัดการ Fake server ต่าง ๆ นั่นเอง ลองคิดดูสิว่า ถ้ามี server จำนวนมาก ๆ มันจะเป็นอย่างไร !! เราจำเป็นต้องจัดการให้ดีกว่านี้ เพื่อให้เราแยกส่วนของ Fake server ออกจากการทดสอบได้ รวมทั้งสามารถเปลี่ยนแปลงได้ในขณะ Runtime นั่นก็คือ การใช้ Dependency Injection ประกอบกับใน Android มี Build Variant ให้ใช้งาน ดังนั้น การทดสอบ และ จัดการจึงง่ายขึ้นอย่างมาก ๆ แสดงการทำงานดังรูป มาถึงตรงนี้ น่าจะทำให้เราเข้าใจเกี่ยวกับ Hermetic Testing มากขึ้นแล้วนะ ดังนั้น กลับไปดู VDO กันต่อสิ !!

คำถาม แล้วคุณทำการทดสอบแบบ End-to-End testing กันอย่างไร ?

Reference Websites http://googletesting.blogspot.com/2012/10/hermetic-servers.html http://googletesting.blogspot.com/2015/03/android-ui-automated-testing.html