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

Performance Testing :: อย่าประเมินพลังของผู้ใช้งานต่ำเกินไป

$
0
0

Leadership-Performace

Leadership-Performace ปัญหาเรื่องระบบล่มเนื่องมาจากผู้ใช้งานเข้ามาใช้ระบบจำนวนมากพร้อม ๆ กัน เป็นปัญหาที่ผมคิดว่า นักพัฒนาพบเห็นประจำ เช่น ดังนั้นสิ่งที่ควรต้องเตรียมตัวไว้เสมอคือ การทดสอบปริมาณการใช้งานแบบพุ่งสูงอย่างรวดเร็ว (Spike Traffic) เพื่อให้เราสามารถรับมือกับปัญหาต่าง ๆ ได้อย่างรวดเร็ว มิฉะนั้นระบบไฟไหม้อย่างแน่นอน
ปล. จงรู้ปัญหาก่อนผู้ใช้งาน และรับมือมันได้อย่างทันท่วงที
มาดูปัญหาที่ระบบเหล่านี้มักพบเจอ และวิธีการแก้ไขปัญหาในเบื้องต้นกัน

ปัญหาที่ 1 ประเมินจำนวนผู้ใช้งานต่ำเกินไป

ในบางครั้งอาจจะไม่รู้ด้วยซ้ำ !! ในบางครั้งอาจจะประเมินสูงเกินไป ก็จะเกิดปัญหาอีกแบบ !! เราจะรู้ว่าระบบล่ม เมื่อผู้ใช้งานจริงเข้ามาใช้ ซึ่งมันน่ากลัวมาก ๆ หรือว่า คนจริงต้องเจอกันบน production server !! และรู้ปัญหาหลังผู้ใช้งานเสมอ แน่นอนว่าส่งผลไม่ดีต่อธุรกิจเลย ดังนั้นสิ่งที่ต้องทำก็คือ การทำ Stress Testing และ Soak Testing เพื่อให้รู้ขีดความสามารถของระบบงาน ว่าสามารถรองรับการใช้งานสูงสุดเท่าไร อย่างไร และทำให้เห็นถึงปัญหาที่ต้องแก้ไข เช่น
  • Bandwidth ที่ใช้งาน
  • Memory
  • CPU
และระบบที่เกี่ยวข้อง เพื่อหาจุดที่เป็นคอขวด เพื่อแก้ไขปัญหาต่อไป โดยในการทดสอบให้ทำการเพิ่มจำนวนผู้ใช้งาน หรือ traffic ขึ้นไปเรื่อย ๆ จนไปถึงจุดที่ทำให้ระบบมีปัญหา จากนั้นทำการแก้ไข และ ทดสอบซ้ำ ๆ ไปเรื่อย ๆ ประเด็นหลักคือ เราทำการทดสอบรูปแบบนี้หรือไม่ และ ตอนไหน ?

ปัญหาที่ 2 เมื่อเกิดข้อผิดพลาดแล้วทำการ recover ระบบได้รวดเร็วเพียงใด

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

ปัญหาที่ 3 ต้องรู้ด้วยว่า พฤติกรรมของผู้ใช้งานเป็นอย่างไร ?

เมื่อเราทำ Performance testing ระบบงาน สิ่งที่ต้องเข้าใจคือ พฤติกรรมของผู้ใช้งานต่อระบบเป็นอย่างไรบ้าง มิฉะนั้นแล้ว คุณอาจจะทดสอบไม่เจอปัญหาที่ผู้ใช้งานเจอจริง ๆ ก็เป็นได้ ซึ่งนั่นคือปัญหาที่ส่งผลร้ายแรงมาก ดังนั้นสิ่งที่ควรทำคือ การ tracking พฤติกรรมของผู้ใช้งานด้วย Analytic tool ต่าง ๆ จากนั้นนำข้อมูลเหล่านี้มาใช้สำหรับการทำ Performance testing ต่อไป
คำถามคือ วันนี้คุณทำ Performance testing กันหรือยัง ?

ทำความรู้จักกับ Stack Overflow Documentation 

$
0
0

stackoverflow-00

stackoverflow-00 ทาง StackOverflow ได้เปิดระบบที่เรียกว่า Documentation เป็นอีกแหล่งความรู้สำหรับนักพัฒนา software โดยเฉพาะ โดยข้อมูลต่าง ๆ ของระบบมาจาก community นั่นเอง ซึ่งเน้นในเรื่องของตัวอย่าง ตัวอย่าง และ ตัวอย่าง code ดังนั้นพลาดไม่ได้ด้วยประการทั้งปวง มาทำความรู้จักกับ Stack Overflow Documentation กัน ซึ่งสรุปจากบทความเรื่อง Introducing Stack Overflow Documentation Beta

โครงสร้างของตัวอย่างหรือ Code example ของแต่ละเรื่อง

ประกอบไปด้วย
  • Examples
  • Parameters
  • Syntax
  • Remarks
แสดงดังรูป stackoverflow-02

สมาชิกสามารถช่วยกัน contribute ได้อีกด้วย

ทั้งการ vote ทั้งการส่งหัวข้อใหม่ ๆ เข้ามา ทั้งการเพิ่ม Code example ถึงเวลาของนักพัฒนามาช่วยกันปรับปรุงแล้วนะ ทำให้ระบบนี้เป็นมากกว่าระบบ Q&A ทั่วไป stackoverflow-01

ทำไมระบบ Documentation ต้องมีใน Stack Overflow ด้วยล่ะ ?

Stack Overflow นั้นเกิดมาจากนักพัฒนา เพื่อนักพัฒนา เป็นที่รวบรวมความรู้ทางด้าน programming จากนักพัฒนาทั่วโลก ไม่ว่าจะพัฒนาด้วยภาษาโปรแกรมอะไร ไม่ว่าจะใช้ระบบปฏิบัติการอะไร ที่นี่คือ บ้านของทุกคน มีเป้าหมายหลักเพื่อทำให้โลกของ programming ดีขึ้น

โดยระบบ Documentation นั้นมีต้นกำเนิดมาจาก

ระบบ Q&A ที่อยู่ใน Meta community พบว่ามันมีประโยชน์มาก ๆ เมื่อพบกับปัญหาต่าง ๆ รวมทั้งถ้ามี code ตัวอย่างด้วยมันน่าจะดีไม่น้อย ของดี ๆ แบบนี้ไม่น่าจะอยู่ในวงแคบ ๆ อีกต่อไป ดังนั้นจึงเปิดให้ใช้แบบ public กันไปเลย
มาเริ่มใช้งานกันครับ มันแจ่มมาก ๆ กับ Documentation
stackoverflow-03 Reference Websites http://stackoverflow.com/tour/documentation http://meta.stackoverflow.com/questions/303865/warlords-of-documentation-a-proposed-expansion-of-stack-overflow

อย่าปล่อยให้ code มีกลิ่นที่ไม่ดี !!

$
0
0

code-smell

code-smell สิ่งที่นักพัฒนาที่ดีพึงมี คือ มีจมูกที่ดี หมายความว่าต้องหัดดมกลิ่นของ code ว่า code เหล่านั้นมีกลิ่นที่ไม่ดี ไม่พึงประสงค์หรือไม่ ? ซึ่งเราจะเรียกว่า Code Smell
แต่ปัญหาหลัก ๆ คือ เหล่านักพัฒนานั้น จมูกไม่ค่อยดีนะสิ มักจะไม่ได้กลิ่นอะไรจาก code เลย !!
ดังนั้นสิ่งแรกที่นักพัฒนาควรทำคือ อ่าน และ ศึกษา รูปแบบของ code ที่ไม่ดีจากหนังสือ Refactoring : Improving the Design of Existing code มาดูกันว่า Code Smell ที่เจอบ่อย ๆ มีลักษณะอย่างไรบ้าง ?

1. ไม่มีการกำหนดรูปแบบของ code (Coding Standard)

บางทีม บางบริษัทอาจจะบอกว่า เรามี coding standard guideline นะ แต่เป็นเอกสาร !! ปัญหาคือ ไม่มีใครรู้ ปัญหาคือ ไม่มีใครทำตาม ผลที่ตามมาก็คือ รูปแบบของ code มั่วไปหมด ดังนั้นสิ่งที่ต้องทำก็คือ สรุป Coding standard ร่วมกันซะ จากนั้นเริ่มง่าย ๆ จากการกำหนดไว้ใน Text editor และ IDE ของแต่ละคน ต่อมาใส่ขั้นตอนการตรวจสอบ Coding standard ในระบบ Continuous Integration (CI) อีกด้วย ปล. แค่เรื่อง Tab กับ Spacebar ยังเป็นเรื่องกันเลย !!

2. Code ที่ไม่สามารถทดสอบได้ หรือ ทดสอบได้ยากมาก ๆ

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

3. Code ที่มึน ๆ งง ๆ สับสนวุ่นวาย

เคยเจอไหมที่ comment หรือ document ไม่ตรงกับ code เคยเจอไหมที่เจอ Log มากกว่า code เคยเจอไหมที่ตัวแปรใน code มีแต่ i, j, k, x, y, z มีตัวแปร boolean ขยะจำนวนมาก เช่น ทำงานสำเร็จ return true แต่ถ้าไม่จะเป็น false ตัวแปรเหล่านั้นมักจะชื่อ flag เราลบ code กันดีไหม ?

สุดท้ายอย่า Copy and Paste code แบบไม่เข้าใจมันจริง ๆ

บางคนบอกว่าวิธีการนี้มันคือ DRY (Don’t Repeat Yourself) แต่ในความเป็นจริงมันเป็นวิธีการของคนขี้เกียจมากกว่า ดังนั้นก่อนนำไปใช้งานหยุดคิด ตั้งสตินิดนึง
วันนี้จมูกของคูณดีไหม ได้กลิ่นอะไรจาก code หรือไม่ ?
Reference Websites https://medium.freecodecamp.com/do-not-allow-bad-smells-in-your-java-code-4e8ad244393#.j013zfh1a

แนะนำหนังสือโดนใจนักพัฒนา !!

$
0
0

book14

เห็นปกหนังสือแปลก ๆ ใน internet ซึ่งน่าสนใจอย่างมาก เนื่องจากเป็นคำที่แทงใจนักพัฒนาอย่างมาก ดังนั้นเรามาดูกันว่ามีหนังสืออะไรบ้าง ? แน่นอนว่า หนังสือเหล่านี้ไม่มีอยู่จริงนะครับ สามารถดูเพิ่มเติมได้จาก @thepracticaldev และเข้าไป download ได้ที่ github book13   book01   book02   book12   book11   book10   book09   book14   book15   book16

ทำไมสิ่งที่ออกแบบกับสิ่งที่สร้างมักแตกต่างกัน ?

$
0
0

logo

logo วันนี้อ่านบทความเรื่อง Java legacy hairball: refactoring case-study ทำการอธิบายถึงการ refactor legacy code ว่ามีแนวคิดและขั้นตอนอย่างไรบ้าง ? ซึ่งมีความน่าสนใจอย่างมาก จึงนำมาสรุปไว้นิดหน่อย
สิ่งที่ผมชอบมาก ๆ คือ ทำไมสิ่งที่เราออกแบบมักจะแตกต่างจากสิ่งที่สร้างขึ้นมา ?

เริ่มด้วยสิ่งที่เราออกแบบ

ทำการแยกส่วนการทำงานของระบบชัดเจนมาก ทั้ง 2-tier, 3-tier หรือ n-tier ทำการแยก service ออกเป็นกลุ่ม ๆ อย่างสวยงาม มันสวยงามและเป็นระเบียบมาก เมื่ออยู่ในรูปแบบเอกสาร และ diagram ต่าง ๆ แสดงดังรูป design

แต่เมื่อทำการพัฒนาระบบจากสิ่งที่ออกแบบ กลับพบว่ามันต่างกันโดยสิ้นเชิง

ยกตัวอย่างเช่นในส่วนของ Business tier โดย code ของแต่ละส่วนจะผูกมัดกันอย่างมากมาย (Tight coupling) บางครั้งเรียกว่ายุ่งเหยิงเลยก็ว่าได้ แสดงดังรูป implement

คำถามก็คือ เราออกแบบไปทำไม ?

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

ในบทความยังอธิบายวิธีการ Refactoring Legacy Code

เพื่อเป็นแนวทางสำหรับการปรับปรุง code ของระบบให้ดีขึ้น รวมทั้งมีตัวอย่าง VDO และ code ให้ศึกษาอีกด้วย แสดงดังรูป singletons-sl-di

แนะนำการใช้งาน SwiftLint เพื่อตรวจสอบ code

$
0
0

swiftlint-13-638

swiftlint-13-638
วันนี้ Swift developer ทำการตรวจสอบรูปแบบของ source code กันหรือไม่ ? มีข้อตกลงในการเขียน code ( Code convention ) หรือไม่ ?
ถ้ายังไม่มีขอแนะนำ SwiftLint ซึ่งจะช่วยเหลือเรื่องดังกล่าวอย่างมาก โดยอ้างอิงรูปแบบจาก Swift style guide ดังนั้นมาดูการใช้งานกันนิดหน่อย

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

ติดตั้งผ่าน Homebrew ด้วยคำสั่ง [code] $brew install swiftlint [/code] ทดสอบใช้งานผ่าน command line กันได้เลย โดยใช้คำสั่ง [code] $swiftlint [/code] จะทำการอ่านและวิเคราะห์ code ที่พัฒนาด้วยภาษา Swift ให้ โดยในบรรทันสุดท้ายจะมีการสรุปตัวเลข issue ต่าง ๆ ที่ขัดแย้งก็กฏพื้นฐานของ SwiftLint แสดงดังตัวอย่าง [code] Done linting! Found 8990 violations, 616 serious in 207 files. [/code]

ถ้าพบว่าจำนวน issue เยอะก็ไม่ต้องตกใจอะไรมากนัก

เนื่องจากเป็นเรื่องปกตินะครับ (แต่ผมว่าไม่ปกตินะ !!) โดยบาง issue นั้นสามารถให้ SwiftLint ช่วยแก้ไขให้ได้ ด้วยคำสั่ง [code] $swiftlint autocorrect [/code]

ถ้าต้องการรู้ว่า SwiftLint มีกฎ หรือ rule อะไรบ้าง ?

สามารถดูด้วยคำสั่ง [code] $swiftlint rules [/code] แสดงผลดังนี้ lint-01

ถ้าต้องการแก้ไขกฎล่ะ ทำได้ไหม ?

ตอบได้เลยว่าได้ ทำได้ทั้งแก้ไข ทำได้ทั้งยกเลิก ทำได้ทั้งเพิ่มเข้าไปใหม่ ดังนั้นขอยกตัวอย่างการแก้ไข และ ยกเลิกกฎก็แล้วกัน โดยให้ทำการสร้างไฟล์ชื่อว่า .swiftlint.yml ขึ้นมา แสดงดังตัวอย่าง [gist id="2ed74df07ebbffa2f8fb9dbe8277d847" file=".swiftlint.yml"] คำอธิบาย
  • กำหนด path ที่ต้องการให้วิเคราะห์
  • กำหนด path ที่ไม่ต้องการให้วิเคราะห์
  • กำหนดความยาวในแต่ละบรรทัดต้องไม่เกิน 200 เนื่องจากปกติจะมีค่า 100
  • กำหนดความยาวของ data type และ ตัวแปร
  • กำหนดจำนวนบรรทัดของแต่ละไฟล์

ยังไม่พอนะ สามารถใช้งานใน XCode ได้อีกด้วย

ให้ทำการเพิ่ม Run Script ใน Build Phases ดังรูป lint-02 จากนั้นทำการ build project หรือ cmd + B จะแสดงผลของการวิเคราะห์ code กันใน XCode ดังนี้ lint-03 ปล. ยังสามารถนำ SwiftLint ไปตรวจสอบ code ทั้งเครื่องนักพัฒนาเอง และในระบบ Continuous Integration ได้อีกด้วย
วันนี้ Swift developer ทำการตรวจสอบ code ที่เขียนกันหรือยัง ว่า code มีรูปแบบเป็นไปตามที่ตกลงกันไว้หรือไม่ ?

สรุป Top programming language ประจำเดือนกรกฎาคม ปี 2016

$
0
0

top-programming

top-programming ในช่วงกลางปีนั้นมีการสรุป Top programming language ทั้ง
  1. IEEE Spectrum
  2. TIOBE Programming community index
  3. PYPL Index
ดังนั้นมาดูผลสรุปกันหน่อยว่าเป็นอย่างไร ในแต่ละที่จะมีผลที่แตกต่างกันไป ตามที่มาของข้อมูล และ เงื่อนไขต่าง ๆ แต่โดยรวมก็ไปในทิศทางเดียวกันนะ

เริ่มจาก IEEE Spectrum ภาษา C กลับมาครองที่ 1 ในรอบ 2 ปี

โดยที่ภาษา Java ตกไปเป็นอันดับ 2 ส่วนภาษาที่น่าสนใจคือ R ขึ้นมาอยู่ใน Top 5 แล้ว นั่นทำให้เห็นว่าแนวโน้มของ Big Data, Data Science มาแน่นอน ภาษา Go ของ Google ก็มาอยู่ใน Top 10 สำหรับภาษา Swift ก็ได้รับความนิยมสูงกว่า Objective C ไปอย่างมาก แสดงดังรูปสำหรับภาพรวม ieee สำหรับการพัฒนา Mobile application ieee-02

มาดูข้อมูลจากทาง TIOBE กันบ้าง

สิ่งที่น่าสนใจคือ ภาษา Assembly ขึ้นมาอยู่ใน Top 10 ส่วนอันดับต้น ๆ ก็ไม่แตกต่างอะไรกันมาก แสดงดังรูป TIOBE01 แสดงแนวโน้มตั้งแต่ปี 2002 จนถึงปัจจุบัน TIOBE-02

มาดูข้อมูลจาก PYPL Index กันนิดหน่อย

ใช้ข้อมูลจากการค้นหาใน Google ทำให้เราเห็นข้อมูลของภาษา Java, Python และ PHP เยอะเป็นพิเศษ PYPL Index

อย่าลืมจัดการกับ Error response ของ API นะ มันสำคัญมาก ๆ

$
0
0

ErrorMessage

ErrorMessage เนื่องจากช่วงนี้ต้องไปร่วมพัฒนาระบบงานที่มี RESTful APIs ให้บริการ พบว่าสิ่งหนึ่งสำหรับนักพัฒนาที่ดีจะต้องคำนึงถึงก็คือ การจัดการกับ error หรือข้อผิดพลาดต่าง ๆ ซึ่งถ้าจัดการได้ดี จะทำให้ API ที่สร้างนั้นมันดูดีมากขึ้น เนื่องจากสิ่งที่สร้างนั้น เพื่อให้คนใช้งานนะ ดังนั้นการออกแบบสำหรับการจัดการข้อมูลพลาดจึงสำคัญมาก ๆ จึงทำการสรุปเรื่องที่ต้องใส่ใจไว้ดังนี้ ต้องเป็นไปตามกฎต่าง ๆ ของ HTTP ดังนั้น error response ต่าง ๆ ก็ต้องทำตามด้วย เพื่อทำให้ error ต่าง ๆ
  • มี Status code ที่ถูกต้อง
  • ต้องสนใจ Accept header เสมอ
  • ส่งข้อมูลกลับไปให้ถูกต้องตาม Content-Type
เริ่มจาก Status Code สำหรับ Error มักจะสนใจอยู่สองกลุ่มคือ
  • 4xx เป็น error ฝั่ง client หรือผู้ใช้งาน
  • 5xx เป็น error ฝั่น server หรือผู้ให้บริการ
ตัวอย่างเช่น
  • 400 สำหรับการ validate ข้อมูล
  • 401 และ 403 จะเกี่ยวกับ permission การใช้งาน
  • 404 ไม่พบข้อมูล
  • 500 และ 503 จะเกี่ยวกับ server error
ต่อมาเรื่องของ Media Type ซึ่งถูกส่งมาจากผู้ร้องขอ หรือ ผู้ใช้งาน ว่าต้องการ หรือ ยอมรับข้อมูลรูปแบบไหน เช่น XML และ JSON เป็นต้น ดังนั้นทางฝั่งผู้ให้บริการควรสนใจ และส่งผลของ error กลับไปในรูปแบบนั้น ๆ ต่อมาเรื่องรูปแบบของ Error response ที่ส่งกลับไป อย่างน้อยควรประกอบไปด้วย
  • Error code ของ application หรือของระบบที่กำหนดไว้
  • ข้อความที่คนสามารถอ่านรู้เรื่องและเข้าใจ
โดยทั้ง Error code และข้อความต่าง ๆ ควรมีอยู่ในเอกสารเพื่ออธิบายเสมอ เพียงเท่านี้ Error response ของ API ก็จะดูดี รวมทั้งผู้ใช้งานก็เข้าใจและใช้งานได้ง่าย ไม่ต้องมานั่งแปลเป็นภาษาคนอีก !!
คำถามคือ วันนี้คุณออกแบบ Error response ของ API กันอย่างไร ?
Reference Websites https://www.api2cart.com/blog/hints-tricks-better-api-error-codes/ http://www.daimto.com/google-api-error-list/ https://dzone.com/articles/api-errors-are-first-class-citizens http://apiux.com/2013/03/28/2-steps-api-error-codes/

XCode :: ทำการ Inject Object จาก Storyboard กัน

$
0
0

1-bQCSLKNrW3ROh34pl2_Jww

1-bQCSLKNrW3ROh34pl2_Jww เนื่องจากมีโอกาสได้แบ่งปันเรื่อง MVP pattern ให้ทีมนิดหน่อย (แบบไม่ตั้งใจ) ซึ่งมีเรื่องหนึ่งที่ติดค้างไว้ก็คือ การ Inject Object จาก Storyboard ไปเลย จะได้ไม่ต้องมาสร้าง object ขึ้นมาใน ViewController เอง ทำให้การเขียน code ง่าย และ สะดวกขึ้น

จากตัวอย่าง code ในวันนี้อยู่ที่ Github

ซึ่งไปดูในไฟล์ ViewController.swift จะพบว่า function sort() ทำการสร้าง object จาก class SortController ขึ้นมา ดังนี้ [gist id="21d27ef67c97335aff1a4cc05dfec5e3" file="ViewController.swift"] คำอธิบาย class SortController นั้นคือ Presenter หรือตัวแทนการทำงาน หรือเป็นส่วน business logic ของระบบนั่นเอง ซึ่งจากตัวอย่างจะทำการเรียงลำดับข้อมูลตัวอักษร ดังนั้นเราจึงพยายามแยกการทำงานออกมาจาก ViewController

จากการสร้าง object ของ SortController นี่เอง

จึงมีคำถามว่า ถ้าเราไม่อยากมาสร้าง object แบบนี้ล่ะ เนื่องจากไม่ต้องการให้ code ผูกมัดจนเกินไป (Tight coupling) มันมีวิธีอื่น ๆ อีกไหม ? ซึ่งตอบได้เลยว่ามีหลายวิธีมากเช่น
  • เขียนเอง
  • ใช้ library เกี่ยวกับ dependency injection
รวมทั้งวิธีที่ผมใช้คือ Inject ผ่าน Storyboard กันไปเลย แต่ต้องแก้ไข code นิดหน่อย มาเริ่มกันเลย ขั้นแรกแก้ไขไฟล์ SortController.swift ให้ extends มาจาก NSObject ก่อน [gist id="21d27ef67c97335aff1a4cc05dfec5e3" file="SortController.swift"] ขั้นที่สองทำการแก้ไขไฟล์ ViewController.swift ให้ทำการเพิ่มตัวแปรชนิด SortController เข้ามาดังนี้ [gist id="21d27ef67c97335aff1a4cc05dfec5e3" file="ViewController02.swift"] ขั้นที่สามสร้าง Object ขึ้นมา และ เพิ่มเข้ามายัง Storyboard ทำการเลือกชื่อ class เป็น SortController ซะ แสดงดังรูป xcode-01 ขั้นตอนที่สี่ทำการเชื่อมโยงระหว่าง object ใน Storyboard กับตัวแปรใน ViewController แสดงดังรูป xcode-02 ขั้นตอนที่ห้าถ้า run ระบบจะพังตอนเปิดขึ้นมา เนื่องจากจะทำการสร้าง object ของ SortController ขึ้นมา ด้วยการเรียกผ่าน init() ซึ่งใน code ไม่มี ดังนั้นจำเป็นต้องสร้างขึ้นมา หรือลบ init() ที่เราไม่ออกไป ซึ่งผมเลือกการลบทิ้งไป ผลที่ตามมาจากการลบไปนั้น พบว่าระบบสามารถ run ขึ้นมาได้ แต่ไม่สามารถใช้งานได้ เนื่องจากเกิด error ดังนี้ [code] fatal error: unexpectedly found nil while unwrapping an Optional value [/code] ขั้นตอนที่หกทำการแก้ไขด้วยการแก้ไข code เปลี่ยนจากการ Injection แบบเดิมคือ Constructor Injection มาเป็น Property หรือ Setter Injection ซะ ซึ่งเป็นการ injection ที่นิยมใน framework ต่าง ๆ ดังนั้นจึงทำการแก้ไขดังนี้ [gist id="21d27ef67c97335aff1a4cc05dfec5e3" file="ViewController03.swift"] แต่ยังไม่จบนะ !! ลอง Run Test ของระบบนี้สิ แล้วจะพบว่าตายเรียบ เนื่องจากเราเปลี่ยนวิธีการพัฒนานั่นเอง ดังนั้นจงแก้ไขซะดี ๆ ขั้นตอนที่เจ็ดแก้ไข test ทั้งหมด และ ปรับชื่อให้อ่านง่ายขึ้น รวมทั้งอย่างลืมเรื่อง SwiftLint ด้วยว่าต้องมีค่าเป็น 0 นะ นั่นคือไม่มี warning ใด ๆ เลย เพียงเท่านี้ก็สามารถแก้ไขและปรับมาใช้การ Inject Object ผ่านทาง Storyboard ได้แล้ว สามารถดู code จากการแก้ไขได้ที่ Github::Up1

[Android] มาดูว่า Medium app พัฒนาด้วยอะไรบ้าง ?

$
0
0

medium

medium เพื่อความสนุกในการศึกษา Android app ของชาวบ้าน เลยนำ app ที่ได้รับความนิยมในด้านดีมาดูกันหน่อย ซึ่งนำไฟล์ APK มา decompile เพื่อเรียนรู้ว่า app เหล่านั้นมีอะไรที่น่าสนใจบ้าง ทั้ง Library ที่ใช้งาน ทั้งแนวทางในการเขียน code ทั้งโครงสร้างของ code โดยมาเริ่มที่ Medium app กันเลย medium02

เริ่มต้นด้วย Library หรือ Dependency ที่ใช้งาน

บอกได้เลยว่ามันเยอะมาก ๆ จะเยอะไปไหน ?
  • Google GSON
  • Google Guava
  • Square Dagger เป็น Dependency Injector ลงไปในส่วนต่าง ๆ ของระบบ ทำให้ส่วนการทำงานแยกเป็นส่วน ๆ ชัดเจนมากขึ้น
  • Square Phrase สำหรับจัดการรูปแบบของข้อมูล ซึ่งสะดวกมาก ๆ
  • Square Picasso
  • Square Retrofit
  • RxJava with RxAndroid
  • Chrisjenx Calligraphy สำหรับการ custom font ใน app
  • Bumptech Glide
  • JakeWharton Timber สำหรับจัดการ Log
  • JakeWharton ButterKnife
  • JakeWharton DiskLRUCache
  • Flipboard BottomSheet
ซึ่งเป็นไปตาม Android app ทั่วไป ที่นิยมใช้งาน library จาก Square และ Google ส่วน library ที่ใช้เยอะ ๆ คือ JakeWharton ทั้ง Timber, DiskLRUCache และ ButterKnife คำถามที่น่าสนใจคือ ทำไมถึงใช้ทั้ง Square Picasso และ Bumptech Glide ด้วยล่ะ ? เมื่อไปดูใน code พบว่า code ใน version ใหม่ของ Medium app นั้น ใช้งาน Bumptech Glide แต่ใน feature เก่า ๆ ยังใช้งาน Square Picasso อยู่ ซึ่งดูจากการกำหนด Module ใน Dagger นั่นเอง

มาดูโครงสร้างของ App กันหน่อย

ประกอบไปด้วยส่วนการทำงานดังนี้
  • Activity สำหรับแสดงผล และ ดักจับการใช้งานจากผู้ใช้
  • View Presenter สำหรับกำหนดการทำงานในแต่ละหน้า
  • Controller เป็นส่วนควบคุมการทำงานหลัก
  • Data store สำหรับจัดเก็บข้อมูล
  • API สำหรับดึงข้อมูลจาก API ต่าง ๆ
เนื่องจากใช้ Dagger จึงมีการสร้าง Component/Module จำนวนมาก ขอบอกเลยว่าเยอะจริง ๆ ซึ่งเป็นส่วนการทำงานหลักของ Medium app เลยก็ว่าได้

ส่วนที่ชอบมาก ๆ ใน App นี้ก็คือ การใช้งาน Optional จาก Google Guava

ทำให้ข้อมูลในตัวแปร และ ข้อมูลจาก method ต่าง ๆ ไม่เป็น Null แน่นอนว่า ไม่ต้องมาตรวจสอบค่า Null หรือเจอกับปัญหา NullPointerException อีกต่อไป รวมทั้งลด ละ เลิกการใช้งาน Android Annotation ต่าง ๆ ซึ่งรกตาอย่างมาก เช่น
  • @Nullable
  • @NotNull
ตัวอย่าง code ของการใช้ Optional [gist id="922096f32415fe45d6529d0d5792e011" file="Optional.java"] ปล. ในภาษา Swift และ Kotlin นั้นเรื่อง Optional มันเข้าไปอยู่ใน type system อยู่แล้ว

เมื่อไปดูใน res/drawable พบว่ามีแต่ไฟล์ xml เท่านั้น

ไม่มีไฟล์รูปภาพใด ๆ เลย เพราะว่าไฟล์รูปภาพแยกออกไปยัง folder ตามขนาดหน้าจอไปเลย เป็นแนวปฏิบัติในการพัฒนาที่ดีเลย
วันนี้ได้เรียนรู้สิ่งต่าง ๆ เยอะมากจาก Medium app เพื่อนำไปประยุกต์ใช้ในการพัฒนาต่อไป มันสนุกดีนะ

แนะนำการใช้งาน Postman ให้เกิดประโยชน์

$
0
0

postman

postman-00 เนื่องจากทีมพัฒนาที่ทำด้วยนั้นใช้งาน Postman กันเยอะมาก ๆ แต่เมื่อลงไปดูการใช้งาน พบว่ายังใช้ประโยชน์จาก Postman น้อยมาก ๆ นั่นคือ ใช้เพียงทดสอบ API ว่าทำงานได้หรือไม่เท่านั้น ดังนั้นจึงทำการแนะนำการใช้งานที่น่าจะมีประโยชน์ไว้นิดหน่อย

1. สร้าง Collection ไว้สำหรับเก็บชุดของ API ที่ทดสอบกันหรือไม่ ?

ส่วนใหญ่มักจะบันทึกรวม ๆ กันไว้โดยไม่แยกเป็นกลุ่ม ทำให้มีปัญหาเมื่อมีจำนวน API เยอะ ๆ ดังนั้นแนะนำให้บันทึกแยกเป็น Collection ไปนะ postman-01

2. เมื่อเราสร้างเป็น Collection แล้วเราสามารถ run API ทั้งหมดในแต่ละ Collection ได้เลยนะ

เท่าที่เห็นคนใช้งาน Postman จะ run ทีละ API ไปเรื่อย ๆ เห็นแล้วขัดใจน่าดู !! ดังนั้นเมื่อสร้างเป็น Collection แล้วเราสามารถ run ทั้งหมดในการกดปุ่มเดียวเท่านั้น postman-02 จากนั้นทำการกดปุ่ม Run และ Start Test ได้เลย จะทำการทดสอบ API ทุกตัวใน Collection นั้น ๆ รวมทั้งสามารถกำหนดจำนวนรอบในการทดสอบได้อีกด้วยนะ ผลการทำงานเป็นดังนี้ postman-11

3. เมื่อเราต้องทำการ run API เดิมใน environment ต่าง ๆ จัดการอย่างไร ?

บางคนก็ทำการเปลี่ยน IP หรือ domain name ใน URL ของแต่ละ API เลย บางคนดีขึ้นมาหน่อยบันทึกแยกกัน บางคนดีขึ้นมาหน่อยทำการบันทึกแยก Collection แต่ปัญหาที่ตามมาคือ ถ้า environment ต่าง ๆ เปลี่ยนล่ะ เช่น IP หรือ domain name เปลี่ยน สิ่งที่ต้องแก้ไขคือ เข้าไปแก้ไขใน API ทุก ๆ ตัวนะสิ !! มันลำบากมาก ๆ
ดังนั้นสิ่งที่แแนะนำคือ การกำหนด environment ไปเลย
มีขั้นตอนดังนี้ เข้าไปจัดการ environment กัน postman-04 ทำการสร้าง Environment แยกกันตามที่ต้องการ  เช่น DEV, SIT, TEST และ UAT เป็นต้น postman-05 โดยในแต่ละ environment ทำการเพิ่ม key และ value แยกตาม environment กันไป เช่น SERVER-URL = my-domain.com postman-06 ในการอ้างถึง key ใน Environment สามารถทำได้ด้วย {{key name}} จากนั้นก่อนทำการ run แต่ละ API ก็ให้เลือกก่อนว่าจะทดสอบด้วย environment อะไร ? postman-07
ถ้าสังเกตจะเห็นว่าในการ run แบบ Collection นั้น สามารถเลือก Environment ได้ด้วยนะ แถมสามารถจัดการข้อมูลทดสอบใน data file ทั้ง CSV และ JSON ได้อีกด้วย

4. API ต่าง ๆ ใน Postman สามารถ share กันได้นะ

ทั้งการทำงานเป็นทีม หรือ sync ผ่าน account ได้ แต่ที่ชอบใช้คือ การ export collection ออกมาเป็นไฟล์ จากนั้นเก็บไว้ใน Version Control ต่อไป เมื่อมีการแก้ไขหรือเปลี่ยนแปลงก็ทำการ import เข้ามาใช้งาน เพียงเท่านี้ก็ใช้งานร่วมกันได้แล้ว postman-08

5. แต่ละ API เราสามารถเขียน script สำหรับการทดสอบได้นะ รู้ยัง ?

ทั้งการตรวจสอบ Response code ทั้งการตรวจสอบข้อมูลที่ส่งกลับมา และอื่น ๆ อีกมากมาย ซึ่งทำได้มากกว่ามานั่งดูด้วยตานะครับ !! postman-09

ยังไม่พอเราสามารถทำการ run Postman ผ่าน command line ได้อีกด้วยนะ

ซึ่งต้องติดตั้ง Newman ก่อน ด้วยคำสั่ง [code] $npm install -g newman [/code] จากนั้นทำการ export ทั้ง Collection และ Environment จาก Postman ออกมาเป็นไฟล์ และทำการ run ผ่าน newman ด้วยคำสั่ง [code] $newman -c <collection file> -e <environment file> [/code] จะแสดงผลการทำงานดังนี้ postman-10
สุดท้ายยังสามารถนำไปใส่ในระบบ Continuous Integration ได้อีกด้วย คำถามคือ วันนี้เราใช้ Postman กันอย่างไรบ้าง ?

อย่าถามว่าต้องทำการ Refactor code หรือไม่ แต่ให้ลงมือทำไปเลย

$
0
0

improve

improve การ Refactor code เป็นสิ่งหนึ่งที่นักพัฒนา software ที่ดีต้องทำอยู่อย่างสม่ำเสมอ แต่เรากลับพบว่า
  • มักจะขอเวลาเพิ่มสำหรับการ refactor code ?
  • ทำการสร้าง backlog สำหรับการ refactor code ขึ้นมา ?
  • ถามว่าเราควร refactor code หรือยัง ?
  • ไม่ทำการเพิ่ม test ใด ๆ เข้ามาเลย ?
  • ทำการทดสอบไม่ครอบคลุม ?
หนักกว่านั้นคือไปขอเวลากับทางลูกค้าเพื่อปรับปรุง code ให้ดีขึ้นอีก ซึ่งส่วนใหญ่ไม่มีใครเห็นดีเห็นงามด้วยเลย ดังนั้น เราก็พัฒนาแบบเดิมกันต่อไป ส่วน code ที่ออกมานั้นก็แย่ลงไปทุกวัน !! ในการ Refactor code นั้นประกอบด้วยหลายสิ่งอย่างมาก เช่น
  • ปรับปรุงโครงสร้างของ class/method
  • ทำการเพิ่มชุดการทดสอบ เช่น Unit tests เพื่อทำให้เรามั่นใจในการแก้ไข
  • ทำการลบ code ที่ไม่ใช้ และ ไม่จำเป็นออกไป
  • ทำการปรับปรุงเพื่อทำให้ code อ่านและทำความเข้าใจได้ง่ายขึ้น
  • ปฏิบัติตามแนวคิดดี ๆ เช่น Clean code และ SOLID เป็นต้น
อย่าพูดว่าต้องขอเวลาทำการ Refactor code เนื่องจากชื่อของคุณมันอยู่ใน code อยู่แล้ว เนื่องจากชื่อของคุณมันอยู่ในทุก ๆ การ commit อยู่แล้ว มันคือความรับผิดชอบที่จะต้องสร้างและส่งมอบระบบที่มีคุณภาพออกไป หยุดหาข้ออ้างเพื่อไม่ทำการ refactor code ไม่ต้องถามว่าควรทำตอนไหน ไม่ต้องถามว่าทำอย่างไร (เป็นสิ่งที่นักพัฒนาต้องศึกษาเพิ่มเติม) แต่ให้ลงมือทำทันที เพราะว่าการ Refactor code มันคือส่วนหนึ่งของการพัฒนา software ที่จะขาดไปเสียมิได้เลย
หยุดหมกเม็ด หยุดซ่อน หยุดปิดบัง แล้วมาทำการปรับปรุง code ให้ดีขึ้นเถอะนะ

มาดูกันหน่อยว่า Pokemon Go พัฒนาด้วยอะไรบ้าง ?

$
0
0

pokemon

pokemon วันนี้ Pokemon Go เปิดให้ download และเล่นในประเทศไทยได้แล้ว ดังนั้นในฐานนะของนักพัฒนา software จึงลองมาดูหน่อยว่าระบบนี้ สร้างด้วยอะไรบ้างทั้ง Mobile และ Server ? ทั้งหมดเป็นการเดาเอาล้วน ๆ จากข้อมูลที่พอหาได้ !!

ฝั่ง Mobile ทั้ง Android และ iOS พัฒนาด้วย library และ technology ต่าง ๆ ดังนี้

โดยตัวเกมส์พัฒนาด้วย Unity3D ผนวกเข้ากับ Augmented Reality(AR) Technology Android Android และ iOS iOS

มาดูฝั่ง Server กันบ้าง

ถ้าดูจากตำแหน่งงานที่เปิดรับของ Niantic team ก็สามารถเดาได้ไม่ยาก นั่นก็คือ
  • ใช้ Infrastructure ของ Google นั่นคือ Google Cloud Platform (GCP)
  • พัฒนาด้วยภาษา Java
  • ใช้ NoSQL database ในการจัดเก็บข้อมูล น่าจะเป็นพวก BigTable-like นะ
  • การทำงานเป็นแบบ Asynchronous
  • โดยน่าจะเป็นการเปิด Socket server !!
สามารถแอบไปดูว่าระบบของ Pokemon Go ล่มหรือไม่ที่ Pokemon Go Status

สำหรับนักพัฒนาที่ต้องการใช้งาน Pokemon Go API

และข้อมูลต่าง ๆ ที่เกี่ยวของกับเกมส์นี้ สามารถติดตามและศึกษาเพิ่มเติมได้จาก Awesome PokemonGo

[Kotlin meetup #01] สรุปความสามารถที่น่าสนใจของภาษา Kotlin

$
0
0

kotlin-01

kotlin-01 จากงาน Thailand Developer Konference #1 ของกลุ่ม Thailand Kotlin Android Developer มีหลายเรื่องที่น่าสนใจ ไม่ว่าจะเป็น feature ของภาษา Kotlin ไม่ว่าจะเป็นการนำมาพัฒนา Android app ไม่ว่าจะเป็นการใช้งานร่วมกับ Android Studio แต่ขอทำการสรุปเรื่อง feature ที่น่าสนใจของภาษา Kotlin ไว้นิดหน่อย ที่สำคัญสามารถนำมาพัฒนา Android app ได้แบบสบาย ๆ นะ เหตุผลแสดงดังรูป kotling-02

เริ่มจาก Null Safety

ปัญหาของ Null ในภาษา Java นั้นจัดการลำบากบาก ๆ แน่นอนว่าทำให้เจอปัญหา NullPointerException (NPE) บ่อยมาก !! รวมทั้งใน code มีการตรวจสอบค่า Null ของตัวแปรต่าง ๆ วุ่นวายไปหมด ซึ่งเป็นหนึ่งในความผิดพลาดของภาษาโปรแกรม ดังนั้น Kotlin จึงออกแบบมาเพื่อแก้ไขปัญหานี้ ให้สามารถกำหนดได้ว่ามีข้อมูลชนิดใด ตามความต้องการ เช่น
  • Non-null
  • Nullable
มาดูตัวอย่างกัน เริ่มด้วย Non-null [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="nonnull.kt"] ดังนั้นจึงไม่สามารถกำหนดค่า Null ให้กับตัวแปรที่เป็น Non-null ได้ ทำให้ code ปลอดภัยมากขึ้นเยอะ ต่อมาคือ Nullable นั่นคืออนุญาตให้เป็นค่า Null ได้ แต่จะมีปัญหาตามมาก็คือ ถ้ามีการเรียกใช้ method/property ของตัวแปรนั้น ๆ จะเกิด error ตอน compile ขึ้นมา สามารถเขียนได้ดังนี้ [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="nullable.kt"] จาก error message จะบอกวิธีการแก้ไขให้แล้ว ซึ่งมี 2 วิธีที่ให้ผลที่แตกต่างกัน [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="nullable02.kt"] จากเอกสารอธิบายเพิ่มอีกว่าสามารถใช้ Safe call แบบต่อ ๆ กันได้ด้วย ซึ่งผลการทำงานจะได้ค่า Null กลับมา ไม่เกิด NullPointerException นะ เมื่อทำการเรียกใช้งาน property/method ของ null object แสดงดังตัวอย่าง [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="nullable_chain.kt"] บ่อยครั้งที่ระบบต้องทำงานกับข้อมูลที่ Non-null เท่านั้น แต่ในชุดของข้อมูลกลับมีบางตัวที่เป็น Null ดังนั้นเราสามารถกรองข้อมูลเหล่านั้นออกไปด้วยการใช้ let แสดงดังตัวอย่าง [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="filter_null_01.kt"] ซึ่งจะพบว่าเกิด Error ขึ้นมาเมื่อเจอกับข้อมูลที่เป็น Null แต่ถ้าไม่ต้องการเราสามารถกรองออกไปได้ ดังนี้ [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="filter_null_02.kt"] หรืออาจจะใช้งานผ่าน Collection ก็ได้นะ ซึ่งมี method filterNotNull() ให้ใช้งานดังนี้ [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="filter_null_03.kt"] ทำให้การเขียน code ง่ายและสะดวกมากยิ่งขึ้น ยังไม่พอนะเรื่องของ Null Safety  เช่นถ้าเราพยายาม cast type ของข้อมูลที่ผิด ๆ แล้ว มักจะเกิด ClassCastException ขึ้นมา แต่ใน Kotlin นั้นจะทำการ return ค่า null ออกมาให้ ดังนี้ [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="cast_null.kt"] เยอะจริง ๆ แต่มีประโยชน์มาก

ต่อมาเรื่องของ Enum Class

Enum ใน Java นั้นใช้กันน้อยมาก เนื่องจากความสามารถของ Enum ไม่เยอะเท่าไร รวมทั้งใช้งานยาก แต่ใน Kotlin นั้นทำให้ใช้งานง่ายและมีประโยชน์ สำหรับคนที่เขียนภาษา Swift มาคงไม่แปลกใจเท่าไร เนื่องจากมันเหมือนกันเลย ในการใช้งานเบื้องต้นคือ การกำหนดค่าคงที่ขึ้นมา ซึ่งเราสามารถกำหนดค่าให้ได้ แถมประกาศ Anonymous class ข้างในได้อีก ตัวอย่างเช่นเรื่องของเพศ (Gender) [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="enum.kt"]

ต่อมาเรื่องของ Immutable ของตัวแปรต่าง ๆ ซึ่ง build-in มาใน Kotlin เลย

ซึ่งมีทั้ง mutable และ immutable หลาย ๆ คนฟังแล้วก็อาจจะงงว่ามันคืออะไรกัน ? อธิบายง่าย ๆ คือ ตัวแปรที่เป็น immutable คือ ไม่สามารถกำหนดค่าซ้ำได้ ดังนั้นค่าของตัวแปรจะไม่มีการเปลี่ยนแปลงเลย ถ้าใครพยายามจะทำการแก้ไข จะ compile error ทันที ส่วน mutable ก็ตรงกันข้าม ทำอะไรกับมันก็ได้ โดยตัวแปรที่ต้องการให้เป็น immutable ก็ประกาศด้วย val เท่านั้นเอง ส่วน mutable ก็ใช้ var ไป ดังนี้ [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="immutable.kt"]

ต่อมาเรื่องของ Properties และ Fields ใน Class ต่าง ๆ

โดย property ใน class นั้นมีอยู่ 2 แบบ คือ
  1. ถ้าต้องการให้เป็นแบบ read-only ก็ประกาศด้วย val
  2. ถ้าต้องการทั้ง read และ write หรือ mutable ก็ประกาศด้วย var
ส่วนการเรียกใช้งาน property ต่าง ๆ สามารถเรียกใช้ผ่านชื่อ property ได้เลยดังนี้ [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="Person.kt"] แต่ถ้าต้องการกำหนด getter/setter ในแต่ละ property ก็ทำได้ง่าย ๆ ดังนี้ [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="Person02.kt"] ยังไม่พอนะ มีเรื่องของ Delegate Property อีก เป็นความสามารถที่น่าสนใจก็คือ เราสามารถเฝ้าดูการเปลี่ยนแปลงค่าของ property ต่าง ๆ ได้ (Observable) ตัวอย่างเช่นเฝ้าดูการเปลี่ยนค่าของ firstName ใน Person [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="Person03.kt"] จากความสามารถนี้เราสามารถนำไปใช้ประโยชน์ได้อย่างมาก เช่นเมื่อเกิดการเปลี่ยนแปลงค่าต่าง ๆ จะให้ทำอะไรบ้าง ถ้าเป็นแบบปกติเราต้องสร้าง interface และ implement code ให้วุ่นวายกันอย่างมาก แต่ใน Kotlin ได้เตรียมไว้ให้หมดแล้ว

ต่อมาคือเรื่องของ Data Class

สำหรับ class ที่สร้างขึ้นมาสำหรับเก็บข้อมูลต่าง ๆ (Data class) ซึ่งเรามักจะเรียกว่า POJO บ้าง Data Object บ้าง Transfer Object บ้าง Bean class บ้าง Entity class บ้าง โดยมีส่วนการทำงานต่าง ๆ เหมือนกัน และ ต้องเขียน code ซ้ำ ๆ เช่น
  • Constructor และ overload constructor
  • Getter/Setter method
  • Equals() method
  • HashCode() method
  • toString() method
  • การ copy
ซึ่งมันเป็นเรื่องที่น่าเบื่อหน่ายอย่างมาก บางคนก็บอกว่าใช้เครื่องมือช่วย generate code สิ แต่ code มันก็เยอะเหมือนเดิม ดังนั้นใน Kotlin จึงเตรียมสิ่งต่าง ๆ เหล่านี้ไว้ให้ใน Data class โดยที่ Data class จะต้องมีคุณสมบัติต่าง ๆ ดังนี้
  • ใน constructor จะต้องมี parameter อย่างน้อย 1 ตัว
  • ในการประกาศ parameter ต้องกำหนดว่าเป็น immutable หรือ mutable ด้วย val หรือ var เสมอ
  • Data class ไม่สามารถเป็น abstract class ได้
  • Data class ไม่สามารถ extend จาก class อื่น ๆ ได้
[gist id="0fe7576363adbe328c60dcc6fb110ea3" file="Dataclass.kt"]

ปิดด้วย Extension function ก็แล้วกัน

ใน Kotlin นั้นสามารถเพิ่มความสามารถเพิ่มเติมของ class ต่าง ๆ ด้วยการใช้งาน extension โดยไม่ต้องมาทำการ inheritance อีกต่อไป ตัวอย่างเช่น ถ้าต้องการเพิ่มความสามารถของ Int ด้วยการเพิ่ม Day() และ Hour() สำหรับการแปลงวันเป็นชั่วโมง ทำให้ code เราอ่านง่าย และ เข้าใจง่ายขึ้น แถมสะดวกอีกด้วย ดังตัวอย่าง [gist id="0fe7576363adbe328c60dcc6fb110ea3" file="Extension.kt"]
ปล. ความสามารถยังมีอีกเยอะเลย ลองไปศึกษาเพิ่มเติมได้จาก Kotlin Document Reference รวมทั้งฝึกเขียน Kotlin ผ่าน web ที่ Try Kotlin

ยังไม่พอนะ Kotlin ยังสามารถนำไปพัฒนาระบบต่าง ๆ ได้เช่น

มีข้อดีก็ย่อมต้องมีข้อเสียกันด้วย

ทั้ง community ที่ยังมีขนาดเล็กอยู่ ทั้งเรื่องความเข้ากันได้กับ library บางตัวเช่น Mockito ปัญหาและอุปสรรคสำคัญของการนำ Kotlin มาใช้ไม่ใช่เรื่องของ feature นะ แต่มันคือเรื่องของคนล้วน ๆ ทั้งการโน้มน้าวให้หัวหน้าเชื่อ ทั้งการโน้มน้าวให้ทีมเชื่อ และตัวคุณเอง !!

สามารถดูเพิ่มเติมได้จาก

สรุปเรื่อง Story Weight Reduction Toolkit

$
0
0

asplitworkswork_logo

asplitworkswork_logo จากบทความเรื่อง Story Weight Reduction Toolkit ทำการอธิบายวิธีการแบ่งแยกงานใหญ่ ๆ ออกเป็นงานย่อย ๆ ซึ่งทำให้เราสามารถทำการประเมินได้ง่ายขึ้น ซึ่งทำให้เราสามารถจัดการได้ง่ายขึ้น ซึ่งทำให้เราสามารถพัฒนาระบบงานได้ดีขึ้น จึงนำมาแปลและสรุปสิ่งที่น่าสนใจไว้นิดหน่อย เริ่มจากสาเหตุหลักของแต่ละงานที่มีขนาดใหญ่ (Bloated Stories) นำพาไปสู่ปัญหามากมาย ประกอบไปด้วย
  • แต่ละงานประกอบด้วยงานต่าง ๆ มากจนเกินไป
  • ทีมพัฒนาไม่มีความรู้ในงานนั้น ๆ เพียงพอ
  • แต่ละงานต้องพัฒนาอยู่บนเทคโนโลยีใหม่ ๆ ซึ่งไร้ความแน่นอน
  • แต่ละงานที่ทำนั้น ลูกค้ายังไม่เข้าใจชัดเจนเลยว่าต้องการอะไรกันแน่
ดังนั้นในบทความจึงแนะนำวิธีการเพื่อช่วยลดปัญหาเรียกว่า SSST ทำให้ขนาดของแต่ละงานมีขนาดเล็กลง นั่นคือทำให้สามารถประเมินและจัดการได้ดีขึ้น โดยที่ SSST ประกอบไปด้วย
  1. Split
  2. Spike
  3. Stub
  4. Time box
มาดูรายละเอียดของแต่ละเรื่องกันว่าเป็นอย่างไร

1. Split

เป็นวิธีการพื้นฐานสำหรับแบ่งแยกงานใหญ่ ๆ ออกเป็นงานย่อย ๆ เนื่องจากในงานใหญ่ ๆ มักจะมี scenario/flow การทำงานต่าง ๆ มากมาย ทั้ง normal case และ special case โดยปกติเรามักจะรวมสิ่งต่าง ๆ เหล่านี้ไว้ในเพียงงานเดียว !! ดังนั้นแนะนำให้แยกซะ งานที่แยกออกมานั้นมันต้องมีคุณค่าทาง business ด้วยนะ ซึ่งเรื่องของการ Split งานนั้นมันคือสิ่งที่ต้องเรียนรู้และปรับปรุงอย่างต่อเนื่อง เพื่อให้ได้งานที่เหมาะสมกับทีมพัฒนา

2. Spike

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

3. Stub

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

4. Time box

ในบางครั้งคุณต้องการวางแผน ในบางครั้งคุณต้องการแยกงานใหญ่เป็นงานเล็ก ๆ ในบางครั้งคุณต้องการ Spike งานบางอย่าง ซึ่งสิ่งต่าง ๆ เหล่านี้ควรทำอยู่ภายในกรอบเวลาที่กำหนด เพื่อทำให้เรารู้ และ เข้าใจในสิ่งที่กำลังทำ ว่ามันเป็นอย่างไร ว่ามีปัญหาอะไร ว่าต้องการอะไร ว่าต้องปรับปรุงอะไรเพิ่มเติม ทำให้เราเห็น progress ของการพัฒนา ทำให้เราเห็นจริง ๆ ว่าสิ่งที่กำลังพัฒนามันใช่หรือไม่
โดยรวมแล้วเราจำเป็นต้องใช้ทั้ง 4 วิธีด้วยกัน ซึ่งจะช่วยทำให้เราสามารถแบ่งงานใหญ่ ๆ ออกเป็นงานย่อย ๆ ได้ดีขึ้น
Reference Websites http://agilecoach.typepad.com/agile-coaching/2010/09/ideas-for-slicing-user-stories.html http://blog.odd-e.com/yilv/2015/07/split-work-and-people.html

จัดการ Dependency Injection ด้วย Dagger 2

$
0
0

Dagger2

Dagger2 จากบทความเรื่อง Dependency Injection Made Simple ทำการอธิบายเรื่อง Dependency Injection และ Dependency Inversion Principle (DIP) ทำให้เข้าใจว่าวิธีการนี้มีความสำคัญอย่างไรต่อการพัฒนา software สิ่งที่น่าสนใจคือ การจัดการ Dependency Injection ในระบบงานด้วย Dagger ซึ่งเป็น library ที่นักพัฒนาหลาย ๆ คนไม่น่าจะพลาด โดยเฉพาะ Android Developer น่าจะรู้จักและใช้งานกันเกือบทุกคน !!
ในบทความข้างต้นใช้ Dagger 1 แต่ในบทความนี้ใช้ Dagger 2 นะครับ
ดังนั้นเรามาดูในรายละเอียดว่ามีอะไรที่น่าสนใจบ้าง
  • Dagger 1 นั้นถูกพัฒนาและดูแลจาก Square
  • Dagger 2 นั้นถูก fork มาจาก Dagger 1 ซึ่งดูแลโดย Google

สำหรับ Android app แนะนำให้ใช้ Dagger 2 นะ

เนื่องจาก Dagger 1 นั้นมีปัญหากับ proguard เพราะว่าใน code มีการใช้ Reflection API จำนวนมาก และ code จะ generate ออกมาดูยากมาก ๆ ส่วน Dagger 2 นั้นทำการแก้ไขปัญหาข้างต้นให้เรียบร้อย ส่วนการพัฒนาระบบด้วยภาษา Java ก็ใช้งานได้เช่นกัน ซึ่งจะอยู่ในตัวอย่างด้านล่างต่อไป

คำแนะนำสำหรับการใช้งาน Dagger 2 นั้น

ควรทำความรู้จักและเข้าใจเกี่ยวกับ Dependency Injection ก่อนนะ มิเช่นนั้นคุณจะรู้เพียงว่า ทำแบบนี้แล้วทำงานได้ แต่ไม่ได้เข้าใจเลยว่า การทำงานเป็นอย่างไร ? ซึ่งเป็นปัญหาอย่างหนึ่งที่มักพบเจอในการพัฒนา software !! (รู้แต่ไม่เข้าใจ) บทความเพิ่มเติมเกี่ยวกับ Depencey Injection

อธิบาย Dependency Injection ให้เข้าใจง่าย ๆ คือ

เราจะไม่ทำการสร้าง object ของ class ที่ต้องการใช้งานเอง ตัวอย่างเช่น [gist id="3013226898763fd6594382ae5a263d80" file="NormalDI.java"] เมื่อ dependency class เริ่มมีเยอะ ๆ แล้ว เราน่าจะมีการจัดกลุ่มและทำการสร้าง object เหล่านั้นให้เลย ซึ่ง class นี้จะเรียกว่า Factory หรือโรงงานผลิต object นั่นเอง ตัวอย่างเช่น [gist id="3013226898763fd6594382ae5a263d80" file="WorkWithFactory.java"] เมื่อต้องการเรียกใช้งาน dependency ต่าง ๆ ก็เรียกใช้งาน ผ่าน Factory กันไปเลย ดังตัวอย่าง [gist id="3013226898763fd6594382ae5a263d80" file="Main.java"]

จะเห็นได้ว่าใน Factory ต้องเขียน code แบบเดิม ๆ สำหรับ dependency ทุกตัว

มันน่าเบื่อมาก ๆ code ซ้ำ ๆ ซาก ๆ ดังนั้นจึงมีคนคิด library ต่าง ๆ ขึ้นมา เพื่อลดจำนวน code ลงไป หนึ่งในนั้นคือ Dagger แต่ในบทความนี้จะเน้นไปที่ Dagger 2 เริ่มด้วยการใช้งาน @Inject สำหรับ Dependency Injection กัน มีอยู่ 3 แบบ คือ
  • Constructor Injection
  • Field Injection
  • Method Injection
ตัวอย่างเช่น [gist id="3013226898763fd6594382ae5a263d80" file="DemoDI.java"]

ปัญหาต่อมาคือ แล้วจะไปเอา Object ของ Dependency มาจากไหนล่ะ ?

ในตัวอย่างแรกมี Factory class สำหรับเตรียมและสร้าง object ต่าง ๆ เมื่อมาใช้ Dagger 2 แล้วก็ต้องจัดการเช่นกัน ซึ่งจะใช้งานผ่าน Module และ Component โดยโครงสร้างของ dependency ต่าง ๆ ถูกนำเสนอในรูปแบบของ graph ที่เป็นแบบ Directed Acyclic Graph (DAG) มันคือ directed graph ที่ไม่เกิด cyclic นั่นเอง ซึ่งเป็นที่มาของชื่อ Dagger นั่นเอง แสดงดังรูป AcyclicDigraphs_800 มาดูรายละเอียดของทั้งคู่กันนิดหน่อย

Module คือ Factory นั่นเอง

สามารถแบ่ง dependency ต่าง ๆ ออกเป็นกลุ่ม เพื่อให้ง่ายต่อการจัดการและใช้งาน รวมทั้งเชื่อมโยง dependency ต่าง ๆ เข้าด้วยกัน แถมสามารถอ้างอิงไปยัง Module อื่น ๆ ได้อีก ตัวอย่างเช่น [gist id="3013226898763fd6594382ae5a263d80" file="FirstModule.java"]

Component คือ ประตูหรือทางเข้าใช้งาน

สิ่งต่าง ๆ ที่กำหนดไว้ผ่าน annotation @Injection และ @Provides เทียบง่าย ๆ ก็คือ interface นั่นเอง ซึ่ง interface ไม่สามารถสร้าง object ได้ ดังนั้น Dagger 2 จึงทำการสร้าง class มาให้ใช้งาน มีรูปแบบชื่อ class ดังนี้ DaggerComponentName ตัวอย่างเช่น [gist id="3013226898763fd6594382ae5a263d80" file="FirstComponent.java"] จากนั้นให้ทำการ run ด้วยคำสั่ง [code] mvn clean install exec:java -Dexec.mainClass="demo.di.Main" [/code]

จากตัวอย่างจะเห็นว่าเมื่อนำแนวคิด Dependency Injection มาใช้แล้ว

ทั้ง class MyClass, Dependency1 และ Dependency2 นั้น แยกการทำงานออกจากกันชัดเจนมาก (Loose coupling) ทำให้แต่ละส่วนทำงานเป็นอิสระมากขึ้น ทำให้จัดการได้ง่ายและสะดวกขึ้น ทำให้ทดสอบได้ง่ายขึ้น แต่ปัญหาที่ตามมาและหลีกเลี่ยงไม่ได้คือ ความซับซ้อนที่สูงขึ้น จำนวน class/interface มากขึ้น ระบบงานเริ่มมี magic มากขึ้น ทำให้ learning curve สูงขึ้น
ดังนั้นก่อนจะเริ่มใช้งานอะไร ขอแนะนำให้ศึกษาเรื่องพื้นฐานก่อนเสมอ อย่าใช้เพียงเพราะว่าเขาบอกว่า ฟังมาว่า มันดี !!
สามารถดู source code ของตัวอย่างได้จาก Github::MyDagger2 และสามารถดูตัวอย่าง code เพิ่มเติมเรื่องการชงกาแฟ เป็นตัวอย่างจาก Dagger 2 :: Coffee อธิบายได้ชัดเจนมาก โดยแสดงการทำงานดังรูป dagger-example
ในบทความต่อไปจะเป็นตัวอย่างในการพัฒนา Android app มีส่วนการทำงานหรือ dependency ต่าง ๆ เยอะมาก ทั้ง Activity, Fragment, Service รวมทั้ง 3-parties library ต่าง ๆ อีก มาดูกันว่าสามารถจัดการด้วย Dagger 2 กันอย่างไร

[Android] สิ่งที่ได้เรียนรู้จาก Source code ของ SimpleNote app

$
0
0

simplenote

simplenote ทีมพัฒนา SimpleNote ได้ประกาศเปิด opensource ของ app ทุก platform ออกมาทั้ง
  • iOS พัฒนาด้วย Objective-C เป็นหลักและมี Swift นิดหน่อย
  • Android
  • macOS พัฒนาด้วย Objective-C เป็นหลัก
  • Window/Linux ซึ่งพัฒนาด้วย Electron
ดังนั้นมาลองดู code ของ Android app กันหน่อย ว่ามีอะไรที่น่าสนใจกันบ้าง ? เริ่มต้นด้วยคำพูดที่ชอบมาก ๆ คือ
We don’t make software for free, we make it for freedom

มาดู Library ที่ใช้พัฒนา App กันบ้าง

ภายใน build.gradle ของ App ไม่มีอะไรมาก

ส่วนใหญ่เป็นสิ่งที่ต้องมีอยู่แล้ว เช่น
  • การ sign APK แบบอัตโนมัติ คงไม่มีใครมานั่งทำแบบ manual หรอกนะ !!
  • การกำหนด configuration ต่าง ๆ ซึ่งไม่มีน่าจะมีใครไป hard code หรอกนะ !!

โครงสร้างของ code ไม่ได้ซับซ้อนอะไรมากนัก

ไม่มีการใช้ View Data Binding ไม่มีการใช้ Dagger ไม่มีการใช้ Reactive ไม่มีการนำแนวคิด MVP, MVVM, VIPER มาใช้ ไม่มีวิธีการที่หวือหวาอะไร โดยแบ่งส่วนการทำงานตาม package ดังนี้
  • Analytics ทำหน้าที่จัดการพวก analytic ต่าง ๆ ของ app
  • Model ทำหน้าที่จัดการข้อมูลบน Simperium
  • Utils เป็นส่วน utilities ต่าง ๆ ของระบบ ซึ่งเยอะมาก ๆ
  • Widgets
  • ส่วนหลักจะเห็น Activity และ Fragment ของแต่ละหน้า ซึ่งจำนวน code ในแต่ละ Activity เยอะใช้ได้เลย

สิ่งที่ชอบมาก ๆ ของ App นี้คือ

มีชุดการทดสอบที่เยอะใช้ได้เลย ซึ่งอยู่ใน AndroidTest ทั้งหมด ประกอบไปด้วย
  • Unit test
  • Integration test ผ่านการ Mock หรือ Test double เช่น Database และ HTTP connection
  • Activity test ผ่าน Instrument testing ของ Android ซึ่งมีอยู่เพียง 2 test case

โดยเราสามารถนำมาศึกษาวิธีการเขียนได้

และเมื่อนำ source code มาวิเคราะห์ด้วย SonarQube ได้ผลดังนี้ ซึ่งเราสามารถเข้าไป contribute ได้อีกเยอะครับ simplenote-sonar Reference Websites https://simplenote.com/2016/08/11/ios-android-and-macos-apps-now-open-source/ https://github.com/Simperium/simperium-android

แนะนำวิธีการเพื่อปรับปรุงการเขียน code ให้ดีขึ้น

$
0
0

road-block

road-block ปัญหาอย่างหนึ่งสำหรับการเขียน code ของเหล่านักพัฒนาคือ เมื่อติดปัญหาหนึ่ง ๆ แล้วมักจะลากยาว จากนั้นก็จะจมอยู่กับปัญหานานมาก จนสุดท้ายพบว่า code ที่เขียนออกมาเพื่อแก้ไขปัญหา มันอ่านไม่รู้เรื่องเลย มันอ่านยากมาก มันทำความเข้าใจยากมาก มันดูแลยากมาก มีข้อดีอย่างเดียวคือ แก้ไขปัญหาได้เท่านั้นเอง หรือบ่อยครั้งไม่สามารถแก้ไขปัญหาได้ แต่ก็ไม่สามารถลบ code ชุดนั้นทิ้งได้ !!
ดังนั้นจึงขอแนะนำวิธีบรรเทาปัญหาเหล่านี้ลงไปบ้าง ซึ่งแปลและสรุปมาจากบทความเรื่อง This Is One Weird Trick for Improving Your Code — Really 

1. กำหนดกรอบเวลาในการแก้ไขปัญหาซะ

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

2. ถ้าติดปัญหาเดิมมานาน ๆ ให้นำงานอื่น ๆ ที่ไม่เกี่ยวข้องกันมาทำ

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

3. ถ้าติดปัญหาเดิม ๆ มาทั้งวัน คิดเท่าไรก็คิดไม่ออกล่ะ !!

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

4. ลองแก้ไขปัญหาด้วยภาษาโปรแกรมอื่นดูบ้าง !!

บางคนอาจจะบอกว่า ทั้งชีวิตเขียนเป็นภาษาเดียว จะไปทำได้อย่างไรล่ะ ?

สุดท้ายถ้าไม่ได้จริง ๆ ก็หาคนช่วยเหลือเถอะนะ

นั่นคือ เรื่องของ pair programming และ mob programming นั่นเอง เพื่อช่วยทำให้เราเห็นมุมมองในการแก้ไขปัญหาจากคนอื่น ซึ่งแน่นอนว่าย่อมแตกต่างจากเรา

โดยสรุป ถ้าเราต้องจมอยู่กับปัญหาใดนาน ๆ แล้ว

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

[iOS]แนะนำ trainer เครื่องมือสำหรับการสร้างผลการทดสอบในรูปแบบ JUnit

$
0
0

trainer-00

trainer-00 ในการทดสอบ iOS app ผ่านระบบ Continuous Integration นั้น จำเป็นต้องทำการทดสอบทั้ง Unit test และ UI test และสร้างผลการทดสอบในรูปแบบ JUnit เพื่อสรุปผลการทดสอบต่าง ๆ ให้ง่ายและชัดเจน ปกติจะใช้ xcpretty ร่วมกับ xcodebuild แต่ว่าจะลำบากขึ้นเมื่อใช้งานร่วมกับ XCode 8 ดังนั้นทางผู้พัฒนา fastlane ก็ได้สร้างเครื่องมือใหม่ชื่อว่า trainer ขึ้นมา ซึ่งใช้ง่ายกว่า และ ทำการได้รวดเร็วกว่า ดังนั้นลองมาใช้งานกันดูหน่อย

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

สามารถติดตั้งได้ 2 แบบคือ
  1. ติดตั้งผ่าน RubyGems
  2. ติดตั้งผ่านระบบ plugin ของ fastlane
โดยสิ่งที่ผมใช้งานคือ ติดตั้งผ่าน RubyGems ด้วยคำสั่ง [code] $gem install trainer [/code]

จากนั้นเข้าไปยัง folder ของ Xcode project ของเรา

ทำการ compile และ ทดสอบด้วย scan ของ fastlane ด้วยคำสั่ง [code] $scan --derived_data_path "output_dir" [/code] จะทำการ compile code และ ทดสอบทั้ง Unit test และ UI test ผลการทดสอบถูกสร้างอยู่ใน folder ชื่อว่า output_dir แสดงการทำงานดังรูป trainer-01

จากนั้นทำการแปลงผลการทดสอบไปอยู่ในรูปแบบ JUnit ด้วย trainer

ด้วยคำสั่ง [code] $trainer [/code] จะทำการอ่านข้อมูลใน folder output_dir มาแปลงให้อยู่ในรูปแบบ JUnit แสดงการทำงานดังรูป trainer-02

จากนั้นสามารถนำ JUnit report เหล่านี้ไปแสดงผลบนระบบ Continuous Integration ได้แล้ว

ซึ่งทำการ configuration ไว้ใน Jenkins ดังนี้ trainer-03 ส่วนผลการแสดงผลรายงานใน Jenkins เป็นดังนี้ trainer-04 เพียงเท่านี้ก็สามารถนำ trainer มาช่วยแปลงข้อมูลการทดสอบ ให้อยู่ในรูปแบบ JUnit เรียบร้อยครับ มันง่ายมาก ๆ Reference Websites https://krausefx.com/blog/trainer-the-simplest-way-to-generate-a-junit-report-of-your-ios-tests https://pspdfkit.com/blog/2016/converting-xcode-test-results-the-fast-way/

[Android] แนะนำ Build Time Tracker สำหรับดูแนวโน้มของเวลา build app

$
0
0

android-000

android-000 วันนี้ดูปัญหาเรื่องการ build ของ Android app ที่ใช้เวลานาน โดยปกติจะดูผ่าน build profile ที่มากับ Gradle ซึ่งก็ให้ผลลัพธ์ละเอียดตามที่ต้องการ แสดงดังรูป android-build-01 แต่ถ้าเราต้องการทำการบันทึกผล และ ติดตามเวลาการ build ในแต่ละวัน จะต้องทำการบันทึกเอง ซึ่งมันไม่สนุกเลย จึงลองทำการค้นหาว่ามีวิธีการอะไรบ้าง ? หนึ่งใน plugin ที่น่าสนใจคือ Build Time Tracker ซึ่งทำการบันทึกเวลาการ build ไว้ให้ตลอด ดังนั้นมาลองใช้งานกันดูบ้างนะ

เริ่มด้วยการติดตั้งและ configuration ใน Android app

[gist id="2a12dd98a61835c9d826b7f215222612" file="build.gradle"] จากนั้นทำการ run app ด้วยคำสั่ง [code] $gradlew clean cAT [/code] ได้ผลการทำงานดังนี้ android-01 และสร้างรายงานในรูปแบบ CSV ออกมาใน folder build ทำการเก็บข้อมูลทุกครั้งที่ build ทำให้เราเห็นว่าแนวโน้มของเวลาในการ build เป็นอย่างไร เพื่อให้รู้ถึงปัญหาและแก้ไขได้อย่างรวดเร็ว

ชาว Android developer ลองนำไปใช้งานกันดูครับ

และเมื่อไปดูจำนวน method ในไฟล์ dex (Dex count) ก็เจอปัญหาเช่นกัน !!!! ได้เวลา ลด ละ เลิกกันแล้วนะ android-02
Viewing all 2000 articles
Browse latest View live