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

JDK 9 Feature Complete แล้วจ้า !!!

January 22, 2017, 11:01 pm
$
0
0

หลังจากที่ JDK 9 Feature Extension Complete process นั้น เลื่อนมาจากเมื่อปลายปีที่ผ่านมา ถึงตอนนี้ทีมดูแลได้ประกาศออกมาว่าขั้นตอนนี้เสร็จสิ้นแล้ว นั่นหมายความว่า ได้ feature ทั้งหมดออกมาแล้ว !! มาดู feature ที่ผมสนใจกันหน่อย
  • Modularity อันนี้ตัวเด็ดเลย JEPs 200
  • jshell หรือ Java Shell (Read-Eval-Print-Loop) JEPs 222
  • HTTP2 Client ใน JEPs 110
  • Deprecated Applet API แล้วจ้าาา JEPs 289 ดังนั้นจะไม่ support Java plugin ใน browser แล้วนะ
  • มี API สนับสนุน Nashorn ECMAScript JEPs 236
  • ปรับปรุง Startup time ของ Java application JEPs 295
  • Platform สำหรับ Logging API และ Service ใน JEPs 264
สามารถดูรายละเอียดเพิ่มเติมได้ที่ JDK 9 project โดยขั้นตอนก็ต้องมาพิจารณาต่อไปว่า จะต้องทำการปรับปรุงในแต่ละ feature อย่างไรบ้าง ? จะต้องทำการปรับปรุงการทดสอบและเอกสารอะไรบ้าง ? รวมทั้งต้องทำการทดสอบการใช้งาน และรับ feedback ต่าง ๆ จาก developer ต่อไป
หวังว่าในปลายเดือนกรกฎาคมปีนี้จะได้ใช้ JDK 9 GA กันนะครับ
↧
Search

มาทดสอบ RESTful API ด้วยการเขียนเอกสารในรูปแบบ Markdown กัน

January 25, 2017, 10:51 am
$
0
0

จากการพูดคุยเรื่องการทดสอบ RESTful API ที่ Facebook มีการพูดถึง Silk ซึ่งเป็น framework สำหรับการทดสอบ RESTful API ด้วยการเขียนเอกสารในรูปแบบ Markdown ดังนั้นจึงลองนำมาใช้งานแบบขำ ๆ กันหน่อย

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

สิ่งที่ต้องติดตั้งก่อนคือภาษา Go จากนั้นทำการกำหนด $GOPATH ให้พร้อม ทำการติดตั้งด้วยคำสั่ง [code] $go get github.com/matryer/silk [/code] จากนั้นก็สามารถใช้งานคำสั่ง silk ได้ ซึ่งอยู่ที่ $GOPATH/bin

สร้าง RESTful API แบบง่าย ๆ เอาไว้ทดสอบนิดหน่อย

โดยเลือกใช้ stubby4j มาช่วยสร้าง เนื่องจากมันง่าย ๆ มาก สิ่งที่ต้องการคือ API เป็นดังนี้
  • Request ใช้งานผ่าน HTTP GET
  • Response ทำการส่งค่า id และ name ในรูปแบบ JSON
สามารถสร้าง APIs ง่าย ๆ ดังนี้ [gist id="2d6ad8c05079ad9e27a646a4f9f77494" file="test.yaml"] มี response เป็นดังนี้ [gist id="2d6ad8c05079ad9e27a646a4f9f77494" file="response.json"] ทำการ start API server ด้วยคำสั่ง [code] $java -jar stubby4j-version -d test.yaml [/code]

ได้เวลานำ Silk มาใช้ทดสอบ API ที่สร้างกันแล้ว

แนวคิดของ Silk นั้นดูเรียบง่ายมาก ๆ คือ ทำการเขียนเอกสารเพื่ออธิบาย API ในรูปแบบ Markdown ปกติ และได้ทำการกำหนดข้อตกลงการใช้งานสำหรับเรื่องต่าง ๆ ไว้ให้ เช่น
  • โครงสร้างของเอกสารเป็นอย่างไร
  • การกำหนด Request และรูปแบบข้อมูลต่าง ๆ ทั้ง parameter, header, cookie และ body
  • การตรวจสอบผลการทำงาน หรือ assert reponse ที่ API ส่งกลับมาเช่น Response code, content type และ data เป็นต้น
ตัวอย่างการทดสอบ API ข้างต้นสามารถเขียนง่าย ๆ ได้ดังนี้ [gist id="2d6ad8c05079ad9e27a646a4f9f77494" file="get_user_by_id.md"] จากนั้นสามารถทดสอบ API ที่เขียนอธิบายในไฟล์ markdown ดังนี้ [code] $silk -silk.url="http://localhost:8882/" get_user_by_id.md [/code] ผลการทำงานแสดงดังนี้ [code] silk: running 1 file(s)... PASS [/code] คำอธิบาย ทำการกำหนด url ของ API ทำการกำหนดไฟล์ markdown ที่เขียนอธิบาย API ไว้ ซึ่งสามารถระบุได้มากกว่า 1 file หรือสามารถใช้ wildcard ก็ได้นะ เช่น *.md
เพียงเท่านี้ก็สามารถเขียนเอกสารอธิบาย API ซึ่งทดสอบได้อีกด้วย แสดงว่าเราได้สร้างเอกสารที่มีชีวิตขึ้นมาแล้วนะครับ
Source code ตัวอย่างอยู่ที่ Github:Hello Silk ปล. ถ้าใครเขียน code ภาษา Go เป็น ก็สามารถเขียน code เพื่อทดสอบผ่าน silk runner ได้อีกด้วย ซึ่งแน่นอนว่าจะมีประโยชน์และยืดหยุ่นกว่าการใช้งาน commad line Reference Websites http://go-talks.appspot.com/github.com/matryer/silk/other/presentation/silk.slide#1
↧
↧

XCode 8.2 สามารถบันทึกการทำงานบน Simulator เป็น Video ได้แล้วนะ

January 27, 2017, 8:31 am
$
0
0

วันนี้ลองใช้งาน XCode 8.2 พบว่า Simulator มันเปลี่ยนไป นั่นก็คือ สามารถบันทึกการใช้งาน Simulator เป็น Video ได้แล้ว โดยใช้คำสั่งดังนี้ [code] $xcrun simctl io booted recordVideo <filename>.<file extension> [/code] ทำให้การบันทึก Video การใช้งาน app เป็นเรื่องง่ายขึ้น หรือแม้กระทั่งการทำ demo สำหรับ Upload ขึ้น Apple Store ต่อไป รวมทั้งยังมี command ในการ capture หน้าจอด้วยนะ (ปกติใช้ Command + S) ด้วยคำสั่ง [code] $xcrun simctl io booted screenshot [/code] ชุดคำสั่งเหล่านี้น่าจะมีประโยชน์ต่อการใช้งานและพัฒนา app มากขึ้นนะ Reference Websites Xcode 8 Release notes
↧

[Tips] Code Highlight สำหรับ Keynote

January 28, 2017, 5:01 am
$
0
0

ปัญหาที่พบเจอ

ต้องทำการ copy code ตัวอย่างไปใส่ใน Keynote พบว่าต้องมานั่งจัด code เอง ทั้งโครงสร้าง ทั้ง syntax highlight และอื่น ๆ อีกมากมาย ทำให้เสียเวลาอย่างมาก ดังนั้นสิ่งที่ต้องการคือ เราจะลดเวลาในเรื่องของ Code Highlight ได้อย่างไร ?

วิธีการแก้ไขปัญหา

ถ้าไม่คิดอะไรมากก็ทำการ capture เป็นรูปมาจาก IDE/Editor ซะเลย แต่ผู้ใช้งานก็ copy ไปใช้งานยากอีก !! ดังนั้นสิ่งที่ต้องการคือ copy code ไปวางบน Keynote แล้วใช้งานได้เลย ไม่ต้องมาเสียเวลาจัด code ให้สวยงามอีก นั่นก็คือนำ Highlight มาใช้งาน ใช้สำหรับแปลง source code ไปอยู๋ในรูปแบบต่าง ๆ เช่น HTML, RTF, SVG เป็นต้น พร้อมกับทำการ highlight code ให้อีกด้วย มีวิธีการใช้งานดังนี้ 1. ติดตั้ง Highlight [code] $brew install highlight [/code] 2. การใช้งานก็ไม่ยากเท่าไร เป็นการใช้งานผ่าน command line นั่นเอง โดยจะทำการอ่าน code จากไฟล์ที่เราต้องการ จากนั้นนำผลลัพธ์ไปใส่ไว้ใน clipboard ทันที ด้วยคำสั่งดังนี้ [code] $highlight -l -O rtf <file name> | pbcopy [/code] คำอธิบาย ทำการอ่านข้อมูลจากไฟล์ที่เราต้องการ โดยแปลงไปอยู่ในรูปแบบ RTF พร้อมกับแสดงหมายเลขบรรทัดให้อีกด้วย มาดูตัวอย่างที่ผมชอบใช้งานคือ อ่าน code ที่เขียนด้วยภาษา Node.js แสดงหมายเลขบรรทัด ตัวอักษรที่ต้องการคือ Boon font ขนาด 30 เขียน command line ได้ดังนี้ [code] $highlight -O rtf good.js -l --font=Boon --font-size=30 | pbcopy [/code] จากนั้นทำการวาง (paste) ใน Keynote แสดงผลดังนี้ เพียงเท่านี้ก็ทำให้ชีวิตสบายขึ้นอีกเยอะครับ
↧

[Android] ขอรณรงค์ให้ใช้ Retrofit สำหรับจัดการ RESTful APIs เถอะครับ

January 30, 2017, 8:04 am
$
0
0

คำถามสำหรับ Android Developer มีใครที่ยังจัดการ RESTful API เองบ้าง ? เช่น
  • ยังเขียนการติดต่อไปยัง RESTful API ด้วย HTTPClient​ เอง?
  • ยังต้องมาเขียน code จัดการ Request/Response กันเอง ?
  • ยังเขียนการ mapping ไปมาระหว่าง JSON/XML กับ POJO class เอง ?
  • ยังเขียน AsyncTask ใช้เอง ?
ถ้าใครยังจัดการเรื่องนี้เองอยู่ ผมแนะนำให้ ลด ละ เลิก แล้วหันมาใช้ Retrofit เถอะครับ จะได้ไม่เป็นภาระแก่ใคร รวมทั้งจะได้มีเวลาเพิ่มเพื่อพัฒนาในส่วนอื่นๆ
ตัวอย่างการใช้งาน HttpClient [gist id="8c66788043c55be4acb166a1750121e6" file="use_httpclient.java"] ตัวอย่างการ mapping ข้อมูลจาก RESTful API ไปยัง POJO [gist id="8c66788043c55be4acb166a1750121e6" file="mapping_json.java"]

ถ้ายังมี code เหล่านี้อยู่ใน Android app แล้ว !!

ผมแนะนำให้หยุดอยู่เพียงเท่านี้ จากนั้นช่วยเปลี่ยนไปใช้ Retrofit เถอะนะครับ แล้วชีวิตในการพัฒนา app จะดีขึ้นมาก
ปล. ถ้าใครยังไม่เคยเขียนแบบ code ตัวอย่าง แนะนำให้เขียนก่อนนะครับ เพื่อทำความเข้าใจกับมัน จากนั้นก็ลบ code ทิ้งไปซะ
ถ้าถามว่ามีตัวอย่างการใช้งาน Retrofit ไหม ? ตอบได้เลยว่ามากนะครับ ยกตัวอย่างเช่น Google :: การใช้งาน Retrofit ใช้เถอะครับ จะได้ไม่เป็นภาระให้ลูกหลานต่อไป
↧
↧

สรุปสิ่งที่ได้รับจากงาน iOSDevTH Meetup #8

February 1, 2017, 6:58 am
$
0
0

เมื่อวานมีโอกาสไปร่วมงาน iOSDevTH Meetup #8 ซึ่งจัดที่บริษัท Ascend โดยในครั้งนี้มี 2 หัวข้อคือ
  1. Organize your code to repository: Case study Cocoapods
  2. VIPER: Scalable Architecture
ทั้งสองหัวข้อเป็นเรื่องของการวางโครงสร้างของ Mobile app ซึ่งสามารถนำมาใช้ได้ทั้ง Android และ iOS app เลยนะ ดังนั้นมาดูรายละเอียดแบบสั้น ๆ กันหน่อย ปล. ไม่ค่อยได้ฟังเท่าไรนะครับ พอดีงานเข้า

ธรรมชาติของ Mobile app

Mobile app ส่วนใหญ่จะเป็น product ที่ทำการพัฒนาและเพิ่ม feature ตลอด ที่สำคัญต้อง deploy/release กันบ่อยเช่นกัน ทำให้ขนาดของ app ใหญ่ขึ้นเรื่อย ๆ ถ้าไม่วางโครงสร้างของ app ให้ดี ๆ แล้ว อนาคตอันใกล้อาจจะต้องทำการแก้ไข หรือ รื้อและทำใหม่ก็เป็นไปได้ รวมทั้งถ้า app มีขนาดใหญ่แล้ว ก็ส่งผลต่อเวลาในการพัฒนาเช่นกัน นั่นคือ เวลาในการพัฒนามากขึ้นเรื่อย ๆ ตามจำนวน feature !! ทั้ง build นาน ทั้งเพิ่ม feature ยาก ทั้งแก้ไขยาก ทั้งทดสอบยาก
แน่นอนว่า คงไม่มีใครอยากอยู่ในสถานการณ์เช่นนี้ แต่บอกได้เลยว่า ต้องผ่านมากันทุกคนจึงจะเข้าใจ
ดังนั้นจึงมีแนวคิดมากมายเพื่อแก้ไขและป้องกันปัญหาเหล่านี้ ตัวอย่างเช่น
  • การแบ่ง code ออกเป็น module
  • โครงสร้างของ app ที่ดีเช่น MVC, MVP, MVVM, VIPER, Redux และ Clean Architecture เป็นต้น

มาดูเรื่องแรกคือ การแบ่ง code ออกเป็น module

โดยปกติแล้วเรามักจะมี code ส่วนที่เรียกว่า common/utility ซึ่งใช้งานร่วมกันทั้งระบบ ดังนั้น code ส่วนนี้ควรจะแยกออกไปเป็น module/library ต่อไป สามารถนำ module/library ต่าง ๆ เหล่านี้ ไปไว้ในตัวจัดการ dependency ต่าง ๆ ได้ เช่น ที่สำคัญสามารถจัดการได้ทั้งแบบ public และ private ตามที่ต้องการกันเลยทีเดียว แต่เพียงเท่านี้ก็ยังไม่พอ ถ้าเราสามารถแยก module ตาม feature หรือ service จะยิ่งทำให้เกิดประโยชน์มากขึ้นไปอีก เช่น
  • Authentication
  • Authorization
  • External APIs
  • Persistence
ยิ่งถ้านำแนวคิด microservice มาใช้ในการแยก service ใน Mobile app ก็จะช่วยทำให้เราแยกพัฒนา app ได้ง่ายขึ้น จากนั้นทำการรวมหรือ integrate ด้วย dependency management ของแต่ละ platform ต่อไป
สิ่งที่ขาดไปไม่ได้เลยสำหรับแนวทางของ Modular นี้ คือ ชุดของการทดสอบในแต่ละ module และชุดการทดสอบใช้งาน module จากภายนอก

ต่อมาคือเรื่องของ Architecture ของ app

เป็นเรื่องที่สำคัญมาก ๆ โดยใน session นั้นเป้นการแบ่งปันเรื่องของ VIPER ซึ่งย่อมาจาก
  • View ทำการแสดงผล กับรอรับ event จากผู้ใช้งาน โดยจะถูกสั่งให้ทำงานจาก Presenter เท่านั้น
  • Interactor เป็นส่วนของ business logic ของแต่ละ use case
  • Presenter เป็นส่วนของ view logic นั่นคือรับ event ต่าง ๆ จาก view และเรียกใช้งานส่วนอื่น ๆ ตาม business process เช่นดึงข้อมูลจาก database ผ่าน interactor เมื่อได้ข้อมูลก็ส่งข้อมูลไปแสดงผลที่ view โดยที่ควรมี ViewModel สำหรับเป็น model ที่ใช้งานจาก view
  • Entity คือ data model ซึ่งถูกใช้จาก interactor
  • Routing เป็นส่วนจัดการ flow การทำงานของ app หรืออาจจะเรียกว่า Navigation logic ก็ได้
แต่ละส่วนจะมีหน้าที่การทำงานที่ชัดเจน (Single Responsibility Principle) ทำให้การพัฒนาเป็นทีมง่ายขึ้น ทำให้การพัฒนามาตรฐานมากขึ้น ทำให้สามารถทดสอบแต่ละส่วนได้ง่ายขึ้น แสดงดังรูป มีข้อดีก็มีข้อเสีย
  • Learning curve สูง
  • ถ้าไม่เข้าใจก็จะ copy-and-paste
  • จำนวนไฟล์เยอะ แต่ถ้าเข้าใจก็สามารถลดบางสิ่งไปได้

ผมมีความคิดเห็นว่า

Architecture ของ app นั้นไม่ควรแข็งกระด้าง หรือบางคนอาจจะเรียกว่ามันคือ pattern ต้องทำแบบนี้เสมอ ซึ่งผลที่ตามมามันไม่ดีเลย สิ่งที่ควรเกิดขึ้นคือ ให้ Architecture ของระบบมีชีวิต คือ ค่อย ๆ โตตามจำนวน feature ค่อย ๆ เปลี่ยนไปตาม code ที่เพิ่มขึ้น ค่อย ๆ เปลี่ยนไปตามหน้าที่การทำงาน ค่อย ๆ เปลี่ยนไปตามความสามารถของทีม ค่อย ๆ โตไปแบบยั่งยืน โดยที่ Architecture ที่ดีควรเป็นดังนี้
  • จำนวนไฟล์ให้แยกตามหน้าที่การทำงานของแต่ละ feature ไม่ใช่ทุก feature มีโครงสร้างเดียวกันหมด
  • สามารถทดสอบได้ง่าย
  • ง่ายต่อการใช้งาน
  • ใช้เวลาในการดูแลรักษาน้อย หรือ cost ต่ำนั่นเอง
ไปเจอข้อมูลเปรียบเทียบน่าสนใจดี ซึ่งมอง 3 เรื่องคือ distribution, testability และ ease of use ดังรูป
↧

สรุปจากบทความเรื่อง 14 must knows for an iOS developer

February 2, 2017, 3:38 am
$
0
0

จากบทความเรื่อง 14 must knows for an iOS developer หรือ 14 เรื่องที่ iOS ควรจะต้องรู้และเข้าใจ คิดว่าน่าจะพอมีประโยชน์กับมือใหม่มาก ๆ หรือแม้กระทั่งมือเก๋า ซึ่งผมคิดว่าส่วนใหญ่มันคือเรื่องพื้นฐานเลยนะ แต่บางเรื่องก็ยากพอควร ดังนั้นจึงสรุปข้อที่เป็นพื้นฐานจริง ๆ  ไว้นิดหน่อย มาเริ่มกันเลย

ต้องใช้งาน Version Control นะ

ไม่มีข้อยกเว้นใด ๆ ทั้งสิ้น ต้องทำการจัดการ source code และเอกสารต่าง ๆ ด้วย Version Control เสมอ ไม่ว่าจะพัฒนาคนเดียว ไม่ว่าจะพัฒนาเป็นทีม ซึ่งในปัจจุบันน่าจะใช้กันอยู่ 2 ตัวหลัก ๆ คือ Git และ SVN

ต้องรู้และเข้าใจเรื่อง Architecture Pattern

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

เข้าใจทั้ง Objectiv-C และ Swift ก่อนตัดสินใจ

ก่อนที่จะตัดสินใจว่าจะพัฒนา app ด้วยภาษาใดนั้น ควรต้องเข้าใจก่อนว่า ในแต่ละภาษามีข้อดีและเสียอย่างไรบ้าง แต่ผมแนะนำให้เขียนด้วยภาษา Swift นะ เนื่องจาก syntax ของภาษาล้วน ๆ

รู้จักและใช้งาน Dependency Manager

ตัวที่ต้องรู้จักคือ Cocoapod อีกตัวก็น่าจะรู้ด้วยคือ Carthage ถ้าไม่รู้จักสักตัว น่าจะถึงเวลาทำความรู้จักซะ

รู้จักวิธีการจัดเก็บข้อมูลของ app

ซึ่งสามารถจัดเก็บได้หลายวิธีทั้ง NSUserDefault, Keychain, CoreData หรือหลัง ๆ มาผมจะใช้ Realm โดยแต่ละวิธีก็มีทั้งข้อดีและข้อเสีย รวมทั้งความเหมาะสมที่แตกต่างกันไป ตัวอย่างเช่น Keychain จะเก็บข้อมูลที่มี privacy สูง ๆ

รู้และเข้าใจการใช้ Storyboard, Xibs และ Programmatic UI (เขียน code เอง)

โดยแต่ละวิธีก็มีข้อดีข้อเสียต่างกันไป อีกทั้งยังขึ้นอยู่กับการตัดสินใจของแต่ละทีมและ app เริ่มต้นที่ Storyboard ทำให้ทั้งทีมพัฒนา ทีม design เห็น flow การทำงานของ app ได้อย่างชัดเจน แต่เมื่อ flow การทำงานเยอะ แต่เมื่อหน้าจอการทำงานเยอะ ก็ทำให้ storyboard มีความยุ่งเหยิงและวุ่นวายได้ รวมทั้งอาจจะเกิดปัญหาเรื่อง merge conflict อีกด้วย แต่ก็แก้ไขได้ด้วยการแยก storyboard และแยกการทำงานเป็นส่วน ๆ ที่ชัดเจน หรือมีการวางแผนที่ดี Xibs เป็นการเตรียมแต่ละหน้าจอออกมาหรือส่วนเล็ก ๆ เป็นไฟล์ย่อย ๆ ทำให้สามารถ reuse ได้ง่าย เรื่อง merge conflict ก็น้อยลงไป ส่วนเรื่องของ flow ก็ยากหน่อย ต้องทำเอกสารเองนะ หรือไปดูเอกสารจากการออกแบบนั่นเอง Programmatic UI ประมาณว่าเขียน code เพื่อสร้าง UI เอง แน่นอนว่า สามารถควบคุมได้ง่าย ปัญหา merge conflict นี่หายไปเลย แต่ไม่สามารถดูหน้าจอได้ถ้าไม่ run app ชีวิตการพัฒนาจะอยู่ในโลกมึดมาก ๆ รวมทั้งทำให้ใช้เวลาในการพัฒนาพอสมควร แต่ก็มี framework ต่าง ๆ ออกมาช่วยให้งานง่ายขึ้น เช่น SnapKit แต่แนะนำให้ใช้ทั้ง 3 วิธีร่วมกันนะครับ

ปิดท้ายด้วยเรื่องของการทดสอบ (Test)

แน่นอนว่านักพัฒนาทุกคนต้องทำการทดสอบ app แต่สิ่งที่ควรทำเพิ่มคือ Automated testing ทั้ง Unit test และ Instrument test หรือ UI test โดยนักพัฒนาหลายคนอาจจะมองว่า มันต้องเพิ่มเวลาในการพัฒนา มันต้องเขียน code มากขึ้น ซึ่งตอบได้เลยว่าใช่แล้ว ถูกต้องแล้ว แต่มันก็มีข้อดีคือ ช่วยทำให้เรามั่นใจใน code มากขึ้น ช่วยทำให้โครงสร้างของ code ทดสอบได้ง่ายขึ้น ช่วยทำให้ง่ายต่อการดูแลรักษามากขึ้น การทดสอบอย่างเดียวคงยังไม่พอ ต้องมีการทำ profiling เรื่องการใช้งาน CPU และ Memory ต้องมีการตรวจสอบ memory leak อีกเยอะเลย !!

ยังมีเรื่องอื่น ๆ อีกนะครับ เช่น

  • Localization string
  • Location
  • Protocol
  • Functional programming
  • Closure
  • CollectionView และ TableView
  • Scheme
ขอให้สนุกกับการเขียนพัฒนาครับ
↧

การ์ตูนขำ ๆ ว่าด้วยเรื่อง DevOps Culture !!

February 6, 2017, 10:58 pm
$
0
0

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

ว่าด้วยเรื่องของ source code

February 7, 2017, 7:40 am
$
0
0

เรื่องที่ถกเถียงกันประจำสำหรับการเขียน code ประกอบไปด้วย
  • Tab vs Space ใช้อะไรดี ?
  • ใช้ 2 หรือ 4 space แทน Tab หรือไม่ ?
  • เขียน {} หรือไม่ ?
  • เขียน { ในบรรทัดไหน ?
  • Naming convention เป็นอย่างไร  camel case หรือ snake case ?
  • ตั้งชื่อต่าง ๆ เป็นอย่างไร ?
  • ถ้าเขียน test จะตั้งชื่ออย่างไรดี ?
สิ่งที่สำคัญมาก ๆ สำหรับทีมพัฒนาคือ code ที่เขียนมันอ่านง่ายเข้าใจง่ายหรือไม่ ? คนที่บอกว่าอ่านง่ายและเข้าใจคือ ทีม code ที่เขียนทั้งทีมมีรูปแบบเดียวกันหรือไม่ ?
เนื่องจากส่วนใหญ่นักพัฒนา มักใช้เวลาในการอ่าน code มักใช้เวลาในการทำความเข้าใจการทำงานของ code มากกว่าการลงมือเขียนหรือแก้ไข code ทำไมนะ ? เคยไหมที่เปิด code ในแต่ละเครื่อง แล้วทำไม code แสดงผลต่างกัน ทั้ง space และ tab !! เคยไหมต้องทำการ merge code ที่มี conflict หรือข้อขัดแย้ง แถมเจอ code ที่หลายหลายรูปแบบ มันยากต่อการ merge code มาก ๆ เคยไหมต้องไปต่อ หรือ แก้ไข code ของคนอื่น หรือแม้แต่ code ที่เขียนขึ้นมาเอง ต้องเสียเวลาเรียนรู้ ต้องเสียเวลาจัดโครงสร้าง code ดังนั้นเราไม่สามารถบอกได้เลยว่า ต้องใช้เวลาในการแก้ไขหรือเพิ่ม code เท่าไร !! เคยไหมต้องไปค้นหาข้อผิดพลาดใน code ต้องมานั่ง debug เพราะว่าอ่าน code ไม่รู้เรื่องเลย หรือ code มันซับซ้อนเกินไป !! เคยไหมที่ code ถูกจัดเรียงแบบกระโดดไปมาจนน่าปวดหัว ขอ code แบบอ่านจากบนลงล่าง และซ้ายไปขวาได้ไหม ?
สิ่งต่าง ๆ เหล่านี้คือ ปัญหาที่เจอกันได้บ่อย ๆ ในการพัฒนา software !! ดังนั้นเราน่าจะทำให้ชีวิตดีขึ้นกว่านี้กันบ้างนะ

เริ่มด้วยเรื่องแรก ตกลงการใช้งาน whitespace กันทั้งทีมซะ

ตัวอย่างเช่นการใช้งาน Tab vs Space ถ้าใช้ space ทั้งหมดแล้ว ตกลงกันเลยว่า Tab ต้องใช้กี่ space ตกลงกันเลยว่า space ที่ใช้ตอนประกาศตัวแปร method for loop และอื่น ๆ อีกมากมาย เพื่อทำให้ code มีโครงสร้างที่เหมือนกัน จากนั้นก็นำ lint มาใช้งานกันซะ

ลำดับการจัดเรียงของ member ต่าง ๆ ใน class หรือในไฟล์

ถ้ามีการกำหนดลำดับ ถ้ามีการกำหนดกลุ่มของ code ในแต่ละ class หรือแต่ละไฟล์ให้ชัดเจน มันน่าจะช่วยให้ง่ายต่อการ merge code นะ เช่น ค่าคงที่อยู่บนสุด รองลงมาคือ field ต่าง ๆ รองลงมาคือ constructor รองลงมาคือ public method รองลงมาคือ private method

รูปแบบการตั้งชื่อก็สำคัญมาก ๆ

ถ้าเราตั้งชื่อให้สื่อความหมายไม่ได้ แสดงว่าเรายังเข้าใจสิ่งที่กำลังพัฒนาไม่ดีพอ ให้เริ่มด้วยรูปแบบของการตั้งชื่อ เช่น ตัวพิมพ์ใหญ่ทั้งหมดสำหรับค่าคงที่ การตั้งชื่อตัวแปรให้ใส่ prefix หรือ suffix เป็นต้น แนะนำให้มีการ review code บ่อย ๆ หรือให้มี pair programming กันตลอด วิธีการตรวจสอบว่าตั้งชื่อดีหรือไม่ แนะนำให้ลองค้นหาดูนะ ว่าคุณนึกชื่อนั้น ๆ ออกหรือไม่ ?

โครงสร้างของ package หรือ namspace แนะนำให้แบ่งตาม feature

จะได้หา code กันง่าย ๆ ไม่ต้องพึ่งความสามารถของ Editor/IDE มากนัก

สุดท้ายอย่าลืมเขียน test นะครับ

มันจะช่วยทำให้เรากล้าแก้ไข code กัน และใช้งาน Version Control ด้วยนะ Reference Websites https://dzone.com/articles/keep-your-code-consistent
↧
↧

สิ่งที่มาแทนที่ @RequestMapping ใน Spring framework 4.3.6 กัน

February 8, 2017, 6:30 am
$
0
0

วันนี้เปิดดูเอกสารของ Spring framework 4.3.6 พบว่า มี feature ที่น่าสนใจคือ Annotation ใหม่ ๆ ซึ่งมาแทนที่ @RequestMapping ซึ่งใช้งานยากน่าดู ที่สำคัญสั้นกว่าเดิมมากมาย ดังนั้นจึงทำการสร้าง annotation ใหม่แยกตาม HTTP Method ดังนี้
  • @GetMapping
  • @PostMapping
  • @PutMapping
  • @DeleteMapping
  • @PatchMapping
ซึ่งทำให้ใช้งานได้ง่ายขึ้นมาก แถมไม่สับสนอีกด้วย ตัวอย่างการใช้งานเป็นดังนี้ [gist id="28f44874006bcc61046ddd4ee978802a" file="Example.java"]

แต่เมื่อเข้าไปดู implementation ของ Annotation ใหม่เหล่านี้

ก็พบว่าภายในยังใช้ @RequestMapping เช่นเดิมนะครับ แสดงดัง code [gist id="28f44874006bcc61046ddd4ee978802a" file="GetMapping.java"] หวังว่า feature นี้น่าจะช่วยให้การพัฒนาระบบด้วย Spring framework สะดวกขึ้นนะครับ
↧

[Android] ถ้าอยากเขียน log แนะนำ Hugo นะ

February 9, 2017, 8:19 am
$
0
0

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

การใช้งาน Hugo

การใช้งานนั้นไม่ยากเลย เพียงแค่ใส่ annotation คือว่า @DebugLog ไปที่ method ที่เราต้องการ เมื่อมีการเรียกใช้ method นั้น ๆ ก็จะทำการ print ค่าที่ส่งเข้ามายัง method และค่าที่ถูก return ออกจาก method โดยที่ไม่ต้องไปเขียน log ใด ๆ ใน code อีกต่อไป จะทำงานเฉพาะ build type ที่เปิดการ debug เท่านั้น หรือไม่ปิดการทำงานของ Hugo
เมื่อลองเข้าไปดูการพัฒนาของ Hugo แล้ว พบว่าใช้ AspectJ นั่นเอง (AOP  ย่อมาจาก Aspect Oriented Programming)
ปล. แสดงว่าในแต่ละ method ต้องมีหน้าที่การทำงานชัดเจนนะ ไม่ใช้ทำงานเยอะ ๆ ยาว ๆ ซึ่งคิดว่าน่าจะลำบากต่อชีวิตน่าดู

มาดูตัวอย่างการใช้งานแบบง่าย ๆ กันหน่อย

เริ่มจากการเพิ่ม dependency plugin ใน build.gradle ดังนี้ [gist id="54395b470a924c8ed7b40f7fad780a8c" file="build.gradle"] จากนั้นเพิ่ม plugin เข้าไปในไฟล์ build.gradle ของ app ดังนี [gist id="54395b470a924c8ed7b40f7fad780a8c" file="app_build.gradle"] ทำการเขียน code แบบขำ ๆ สัก 1 method ดังนี้ [gist id="54395b470a924c8ed7b40f7fad780a8c" file="MainActivity.java"] ทำการ run app จะแสดง log ดังนี้ ซึ่งดูดีมีฐานะอย่างมาก [code] V/MainActivity: ⇢ sayHi(name="Somkiat") V/MainActivity: ⇠ sayHi [0ms] = "Hi Somkiat" [/code] คิดว่าน่าจะมีประโยชน์บ้างนะครับ
↧

[Tips] แนะนำการทดสอบแบบอัตโนมัติสำหรับ Mobile app

February 12, 2017, 7:40 am
$
0
0

ความท้าทายสำหรับการทดสอบ Mobile app ประกอบไปด้วย
  • การทดสอบบน device จริง ๆ และหลากหลาย
  • การทดสอบแบบ parallel เพื่อทำให้การทดสอบรวดเร็วขึ้นมาก
  • การจัดการ code ของการทดสอบ เช่นลด code ที่ซ้ำซ้อน รวมไปถึงการ reuse
  • การทดสอบบน environment ที่เหมือนจริง
  • การทดสอบบน environment ต่าง ๆ เช่น ความเร็วของ network, สถานะของ battery
  • การทดสอบเมื่อมี interrupt ต่าง ๆ เช่น มีสายเรียกเข้า, มี notification และ การทำงานใน background process
  • การทำ stress testing เช่นทำการทดสอบหรือใช้งาน app เป็นเวลานาน ๆ เพื่อดูการจัดการ resource ของ app

จากบทความเรื่อง 7 Mobile Test Automation Tips

แนะนำแนวทางสำหรับการเริ่มต้นที่ดี ซึ่งมีขั้นตอน 7 ขั้นตอนดังนี้
  1.  เริ่มต้นเล็ก ๆ ค่อย ๆ โต ค่อย ๆ ขยาย
  2.  เมื่อชุดการทดสอบใดที่น่าเชื่อถือ ได้รับการยอมรับ ก็เริ่มนำไปใส่ในระบบ Continuous Integration
  3.  ในแต่ละ platform ของ Mobile ล้วนแตกต่างกัน ดังนั้นต้องทำการ debug ซะ
  4.  เมื่อชุดการทดสอบมากขึ้น จะมีสิ่งที่ซ้ำซ้อน นั่นคือเริ่มมีสิ่งที่ reuse กันได้
  5.  เพิ่มการตรวจสอบในแต่ละชุดการทดสอบ
  6.  เริ่มใส่ชุดการทดสอบสำหรับเหตุการณ์ต่าง ๆ ที่ไม่คาดไม่ถึง
  7.  สิ่งที่สำคัญมาก ๆ คือช่องการติดต่อสื่อสารระหว่างทีมพัฒนา ทีม operation และ business เพื่อสร้างความไว้เนื้อเชื่อใจซึ่งกันและกัน
แสดงดังรูป

ก่อนที่จะเริ่มต้นควรเริ่มด้วยคำถามว่า

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

[Robot Framework] มาสร้าง report สวย ๆ ด้วย Allure Report Framework กัน

February 13, 2017, 11:33 pm
$
0
0

พอดีเห็นว่ามีคนพัฒนา Library สำหรับช่วยสร้างผลการทำงานจาก Robot Framework ให้อยู่ในรูปแบบของ Allure Report Framework ชื่อว่า Robot Framework Allure Report แต่ยังไม่ทำการสร้างไฟล์ report สวย ๆ นะ เป็นเพียงไฟล์ xml และไฟล์ property กาก ๆ เท่านั้น ดังนั้นต้องทำการสร้าง report หน้าสวย ๆ เอง ผ่าน Allure Command line ต่อไป มาดูตัวอย่างการติดตั้งและใช้งานกันนิดหน่อย

1. ทำการติดตั้ง Allure Command line กันก่อน

เป็น command line สำหรับการสร้างไฟล์ report สวยงาม ติดตั้งสำหรับ Mac OS ด้วยคำสั่ง [code] $brew tap qatools/formulas $brew install allure-commandline [/code] การติดตั้งสำหรับ Windows และ Unix ทำการ download library มาจาก Allure Core จากนั้นทำการ extract และกำหนดในตัวแปร PATH ซะ ผลจากการติดตั้งจะต้องใช้คำสั่งนี้ได้จากทุกที่ [code] $allure [/code] ผลการทำงานเป็นดังนี้ [code] usage: allure [(-v | --verbose)] [(-q | --quiet)] <command> [<args>] The most commonly used allure commands are: generate Generate report help Display help information report Report commands version Display version See 'allure help <command>' for more information on a specific command. [/code]

2. ทำการติดตั้ง Library สำหรับ Robot Framework

สามารถติดตั้งผ่าน pip ด้วยคำสั่ง [code] $pip install robotframework-allurereport [/code]

3. ทำการเขียน test data ของ Robotframework อย่างง่ายเพื่อทดสอบ

นั่นก็คือ Hello Google ดังนี้ [gist id="7a6b3676b8413ddd8ea1dbfd2425b45c" file="hello.robot"] คำอธิบาย สามารถกำหนด path สำหรับเก็บไฟล์ xml ของสำหรับ Allure report จากนั้นทำการ run test data ด้วยคำสั่งปกติ [code] $pybot hello.robot [/code] ผลการทำงานยังทำงานเป็นปกติเช่นเดิม เพิ่มเติมคือไฟล์ต่าง ๆ สำหรับ Allure report อยู่ใน path ที่เรากำหนดไว้ ตัวอย่างเช่น [code] 872228a1-7700-4a70-9cd9-2c1472b3253e-testsuite.xml allure.properties environment.xml [/code] ปล. จะทำเก็บ history ของผลการทำสอบแต่ละครั้งให้ด้วยนะ ดีมาก ๆ

4. ทำการสร้างไฟล์ report สวย ๆ ในรูปแบบของ Allure

ด้วยคำสั่งดังนี้ [code] $allure generate <path of allure report> [/code] ผลการทำงานเป็นดังนี้ [code] Report successfully generated to the directory <allure-report>. Use `allure report open` command to show the report. [/code] นั่นคือจะทำการสร้าง folder ชื่อว่า allure-report ขึ้นมา จากนั้นทำการเปิดดู report สวย ๆ ด้วยคำสั่ง [code] $allure report open [/code] จะทำการ start web server ขึ้นมา และเปิด report สวย ๆ ผ่าน browser ดังรูป ตัวอย่างของหน้าแรกแสดงผลการทดสอบครั้งต่าง ๆ ไว้ให้ และมีกราฟงาม ๆ ให้ดูแบบผลการทดสอบ
เพียงเท่านี้ก็จะได้ report สวย ๆ ไว้ใช้งานแล้ว ขอให้สนุกกับการเขียน automation test ด้วย Robot Framework นะครับ
ปล. จากการใช้งานยังพบ bug ในหลาย ๆ จุดอยู่นะ !!
↧
↧

[Swift] ลดการเขียน code ซ้ำ ๆ ด้วย Sourcery กันหน่อย

February 17, 2017, 12:15 am
$
0
0

ในการ coding นั้นเรื่องของ copy-and-paste รวมทั้ง code ที่ต้องเขียนซ้ำไปซ้ำมา บางครั้งเป็น code ที่ไม่ควรจะต้องมี แต่ด้วยโครงสร้างของภาษาก็จำเป็นต้องเขียน ทำให้เสียเวลาในการพัฒนาระบบไปอย่างมาก นั่นแสดงว่าเราได้ปฏิบัติตัวขัดแย้งกับ DRY principle อย่างมาก DRY ย่อมาจาก Don’t Repeat Yourself ดังนั้นเรามา ลด ละ เลิก กันบ้างแถอะ หนึ่งในนั้นคือ การ generate code จาก template ซึ่งในบทความนี้ขอแนะนำ Sourcery

ยกตัวอย่างเช่น code ที่เขียนด้วยภาษา Swift

เมื่อเราต้องการเปรียบเทียบระหว่าง object จำเป็นต้องเขียน extension จาก Equatable protocol เสมอดังนี้ [gist id="d93c03c42f2fed808038a07b6476bf10" file="Employee.swift"] มันเป็นเรื่องที่น่าเบื่อมาก ๆ ลองคิดดูสิว่า ถ้ามีการเปรียบเทียบข้อมูลระหว่าง object แบบนี้เยอะ ๆ จะเขียนเยอะไหม จะ copy-and-paste แล้วมาแก้ไขเยอะไหม ? ถ้ามีการเปลี่ยนแปลงเช่นเพิ่มหรือแก้ไขหรือลบ property ต่าง ๆ จะต้องมาแก้ไขเองอีกใช่ไหม ? ยังไม่พอนะ ถ้ามีกรณีอื่น ๆ หรือ รูปแบบอื่น ๆ อีกล่ะ ทั้ง Hashable, Enum และ Tests เป็นต้น ก็ต้องมานั่งทำเองหมด มันไม่น่าจะสนุกเท่าไรนะครับ ดังนั้นมาหาวิธีการที่ง่ายขึ้นหน่อยดีกว่า

สิ่งที่เลือกมาแนะนำคือ Sourcery

เป็น command line tool ที่จะทำการ scan source code เพื่อวิเคราะห์ว่ามี code ส่วนไหนตรงกับ template ที่กำหนดไว้บ้าง จากนั้นก็จะทำการ generate source code ให้เองแบบอัตโนมัติ โดย template จะอยู่ในรูปแบบของ Stencil และสามารถดูตัวอย่าง template เพิ่มเติมได้ที่นี่ จากตัวอย่างข้างต้นสามารถเขียน template ได้ดังนี้ [gist id="d93c03c42f2fed808038a07b6476bf10" file="template.stencil"]

จากนั้นให้ทำการติดตั้ง Sourcery

โดยทำการ download ได้จากที่นี่ หรือทำการติดตั้งผ่าน CocoaPods หรือทำการติดตั้งผ่าน Swift Package Manager

ต่อมาทำการ run ด้วยคำสั่ง

[code] $sourcery Employee.swift template.stencil Employee.more.swift [/code] ถ้าอยากให้ทำการ monitoring การเปลี่ยนแปลงตลอดเวลา ก็เพิ่ม --watch เข้าไปดังนี้ [code] $sourcery Employee.swift template.stencil Employee.more.swift --watch [/code] คำอธิบาย Parameter ตัวที่ 1 คือ input file Parameter ตัวที่ 2 คือ template file Parameter ตัวที่ 3 คือ output file ผลการทำงานเป็นดังนี้ [code] Scanning sources... Found 1 types. Loading templates... Loaded 1 templates. Generating code... Processing time 0.0418089628219604 seconds [/code] มาดู output file จะได้ source code ดังนี้ [gist id="d93c03c42f2fed808038a07b6476bf10" file="Employee.more.swift"] มาถึงตรงนี้น่าจะช่วยลดเวลาในการเขียน code ซ้ำ ๆ ได้บ้างนะครับ แถวเอาคำสั่งนี้ไปไว้ใน build phase ก็น่าจะแจ่มขึ้นไปอีก ขอให้การเขียน code สนุกขึ้นครับ
ปล. IDE และ Text Editor หลาย ๆ ตัวก็มี feature เหล่านี้ให้ใช้งานนะครับ ลองไปค้นหากันดู
Reference Websites https://medium.com/@orron/meta-programming-swift-with-sourcery-3843eafb248#.f43b6bcay
↧

[Swift] มาทำการ refactor code พวก Singleton กันหน่อย

February 18, 2017, 9:45 pm
$
0
0

ใน code สำหรับ iOS ที่พัฒนาด้วยภาษา Swift นั้น พบว่ามีการเขียน code ในรูปแบบ Singleton เยอะมาก ๆ แน่นอนว่า วิธีการนี้มันมีทั้งข้อดีและข้อเสีย เช่น พัฒนาได้ง่าย ใช้งานง่าย ยากต่อการทดสอบ ยากต่อการ reuse state เปลี่ยนได้ตลอด ขอบเขตการทำงานเป็น global ไป ๆ มา ๆ ข้อเสียเยอะนะเนี่ย !! ดังนั้นจึงเป็นเหตุผลว่า ทำไมควร ลด ละ เลิก หรือถ้าต้องการใช้งานจริง ๆ ก็ควรระมัดระวังให้มากเข้าไว้ แต่ถ้าเป็น code ที่มีอยู่แล้วละ ? การจะทำการลบ code เหล่านี้ทิ้ง น่าจะเป็นงานช้างแน่ ๆ ดังนั้นเรามาหาวิธีการอยู่กับ Singleton กันเถอะ นั่นคือการ refactor code นั่นเอง มาเริ่มกันเลย

ถ้าไปดูใน code ต่าง ๆ ของ Apple จะพบว่า Singleton มีอยู่ทุกหนแห่ง

เช่น
  • UIApplication
  • NotificationCenter
  • UserDefaults
  • URLSession
  • NSTimeZone
แสดงว่ามันก็มีข้อดีเยอะมาก ๆ นะ แต่เรานั่นเองที่มักนำมาใช้งานแบบผิด ๆ ดังนี้

เมื่อเรานำสิ่งต่าง ๆ เหล่านี้มาใช้งาน

จะมี code ในรูปแบบนี้ [gist id="fe7f5c6919ce75aaea012524efa496f5" file="ExampleViewController.swift"] จาก code นี้มีปัญหาอะไรบ้าง ? ถ้าต้องการแก้ไขอะไร น่าจะลำบากมากขึ้นเรื่อย ๆ ตามจำนวน code ถ้าต้องการทดสอบก็ยากต่อการจำลอง นับวันยิ่งซับซ้อน !!
ดังนั้นมาทำการปรับปรุง code ให้ดีขึ้นกันหน่อย

วิธีการที่ง่าย ๆ คือ Dependency Injection (DI)

นั่นคือ ผู้เรียกใช้งานทำการส่ง object ที่ทางผู้ถูกเรียกต้องการเข้ามา จากตัวอย่างนั้นสิ่งที่ต้องส่งเข้ามาประกอบไปด้วย
  • UserDefaults
  • URLSession
ดังนั้นอาจจะทำการสร้าง constructor เพื่อรับค่าต่าง ๆ เหล่านี้ แสดงดัง code [gist id="fe7f5c6919ce75aaea012524efa496f5" file="ExampleViewController02.swift"] ข้อดีของวิธีนี้ก็คือ ผู้เรียกใช้งานสามารถส่ง object ที่ต้องการมาได้เลย ขอให้เป็นชนิดเดียวกันเท่านั้น ดังนั้น จึงง่ายต่อการทดสอบ และลดปัญหาของ Singleton ลงไปได้ (ถึงแม้ object ที่ส่งมาจะเป็น singleton ก็ตาม)

ปัญหาที่เกิดขึ้นคือ ส่วนที่เรียกใช้งาน ExampleViewController อยู่แล้ว !!

นั่นคือ compile ไม่ผ่านอย่างแน่นอน เพราะว่าเราได้เปลี่ยนวิธีการไปจากเดิมโดยสิ้นเชิง จากเดิมที่สร้าง object ด้วย default constructor มาเป็น constructor ที่มี argument 3 ตัว ซึ่งนั่นหมายความว่า เราทำการ refactor code โดยไม่สนใจใครเลย เป็นสิ่งที่ไม่ดีอย่างมาก และขัดแย้งกับแนวคิดของการ refactor code อย่างมาก นั่นคือ
Easy to change, but difficult to break
ปัญหานี้สามารถแก้ไขง่าย ๆ ด้วย Default parameter value นั่นเอง [gist id="fe7f5c6919ce75aaea012524efa496f5" file="ExampleViewController03.swift"] น่าจะทำให้การเขียน code สนุกขึ้น คำถามที่น่าสนใจคือ เราทำการ refactor code กันบ่อยเพียงใด ? คำแนะนำสำหรับการพัฒนาคือ
Go slow and steady and keep shipping
↧
Search

[แปล] ทำความเข้าใจเกี่ยวกับ TDD และ Unit test กันอีกสักหน่อย

February 20, 2017, 2:14 am
$
0
0

เช้านี้นั่งอ่านบทความเก่า ๆ ที่เก็บเอาไว้คือ 5 Common Misconceptions About TDD & Unit Tests อธิบายเกี่ยวกับความเข้าใจผิดเกี่ยวกับ TDD และ Unit Test จึงทำการแปลและสรุปเนื้อหาบางส่วนไว้นิดหน่อย นักพัฒนาทุกคนเห็นด้วยว่า การทดสอบเป็นสิ่งที่ดีมาก ๆ แต่นักพัฒนาส่วนใหญ่กลับไม่ทดสอบ !! เช่นไม่เขียน Unit test เป็นต้น หรืออาจจะทดสอบในแบบของตัวเอง สุดท้ายสิ่งที่สร้างก็กลับมาทำร้ายเราเอง เป็นแบบนี้ทุก ๆ งานไป ปัญหาเหล่านี้อาจจะเกิดมาจาก ความไม่รู้ ความมีประสบการณ์เยอะไป จนไม่เปลี่ยนวิธีการรวมไปถึงความเชื่อ ความเข้าใจผิด หรือเหตุผลใด ๆ ก็ตาม ดังนั้นมาปรับทัศนคติกันหน่อย ซึ่งในบทความอธิบายไว้ 5 ข้อดังต่อไปนี้

1. การเขียน unit test หรือทำตามแนวทางของ TDD นั้นมันใช้เวลานาน

ดังนั้นทางทีม business ไม่เห็นดีเห็นงามอย่างแน่นอน ที่สำคัญมันคือเหตุผลหลักของการไม่ทดสอบระบบ ผลที่ตามมาก็กระทบทั้งสองฝ่ายคือ development และ business !!
เนื่องจากฝ่าย business ไม่สนใจหรอกว่า ฝ่าย development จะทำอะไร อย่างไร แบบไหน ขอให้ได้งานตามที่ต้องการก็พอ
ดังนั้นสิ่งที่ต้องมาคุยและทำความเข้าใจกันใหม่คือ ฝ่าย business สนใจตัวชี้วัดอะไรบ้าง ? ในการเขียน unit test และ TDD นั้นส่งผลอะไรต่อตัวชี้วัดของทาง bussiness บ้าง ?
  • ช่วยปรับปรุง productivity ของทีมพัฒนาในระยะยาว
  • ลดค่าใช้จ่ายของฝั่ง customer service และ operation
  • ช่วยทำให้มีผู้ใช้งานมากขึ้น
  • ลูกค้ามีความพึงพอใจมากขึ้น ลดการเลิกใช้งานไป
จากงาน research ของระบบงานที่เขียน unit test และ TDD มาใช้งาน พบว่าสามารถลด bug บน production ได้ถึง 40-80% นั่นหมายความว่า ถ้านักพัฒนาเขียน code โดยไม่มีการทดสอบเช่นเขียน unit test แล้ว จะเป็นการเพิ่ม bug หรือความผิดพลาดเข้าไปในระบบ นั่นคือ เราเสียเวลาไปโดยเปล่าประโยชน์หรือไม่ ? นั่นคือ เสียค่าใช้จ่ายแล้วได้ bug กลับมา มันใช่หรือไม่ ?
ที่สำคัญการแก้ไข bug มันคือ การเสียเวลาไปโดยใช่เหตุ และมักจะเป็นสิ่งที่เข้ามาขัดจังหวะการพัฒนาของทีมอีกต่างหาก เราจะลดงานเหล่านี้ไปได้อย่างไรนะ ?
ในบทความอธิบายว่า ช่วงเริ่มต้นของการนำ unit test และ TDD มาใช้งาน จะเพิ่มเวลาในช่วงแรกประมาณ 10-30% แต่เมื่อเวลาผ่านไปจะช่วยลดงานต่าง ๆ ลงไป การทำความเข้าใจกับทาง business มันสำคัญมาก ๆ นะ ถ้ายังมีปัญหาต้องคุยกัน เพื่อสร้างความเข้าใจร่วมกัน และต้องเปิดเผยความจริงด้วยนะ อย่าหมกเม็ด

2. นักพัฒนาไม่สามารถเขียน test ได้ถ้ายังไม่เขียน code

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

3. ต้องเขียน test ให้ครบก่อนเริ่มเขียน code !!

สิ่งที่ต้องเข้าใจก่อนคือ ปัญหา และ ภาพรวมของสิ่งที่กำลังจะพัฒนา จากนั้นให้เริ่มทำตามขั้นตอนดังนี้
  1. เขียน test เพียง test case เดียวเท่านั้น
  2. Run test case นั้น แน่นอนว่าต้อง fail
  3. ทำการเขียน code เพื่อให้ test case ผ่าน (Code เท่าที่ทำให้ test case ผ่าน)
  4. Run test case นั้น แน่นอนว่าต้อง ผ่าน
  5. กลับไปทำข้อ 1 ใหม่อีกรอบ

4. ต้องทำการ refactor code อยู่ตลอดเวลา !!

ถามว่าดีไหม ตอบว่าดี แต่ต้องตอบให้ได้ก่อนว่า เหตุใดจึงทำการ refactor ? นั่นคือ คุณต้องเรียนรู้ Code Smell ก่อนนะ เป้าหมายของการ refactoring คือ ปรับปรุง code ให้ดีขึ้น ปรับปรุง code ให้เหมาะสมกับทีม ปรับปรุง code เพื่อให้ทีมเร็วและเข้าใจมากขึ้น นั่นคือการลดเวลาที่ไร้ประโยชน์ออกไป

5. ต้องเขียน unit test ทั้งหมด !!

ระบบงานที่พัฒนานั้นมักจะต้องติดต่อสื่อสารกับส่วนอื่น ๆ มากมาย ทั้งระบบ I/O, database, network, User interface แน่นอนว่า การเขียน unit test สำหรับสิ่งเหล่านี้มันยากมาก ๆ บ่อยครั้งจะต้องใช้ Test double ร่วมด้วยเช่น Mocking บ่อยครั้ง Mocking เต็มไปหมด นั่นคือ Code smell อย่างหนึ่ง !! หมายความว่า unit test เหล่านั้นมันไม่ค่อยมีประโยชน์ต่อเราสักเท่าไร !! หรือว่า ต้องไปเขียน integration/functional/e2e test น่าจะมีประโยชน์หว่าหรือไม่ ? แต่จะถ้าจะไปเขียน integration/functional/e2e test ทั้งหมดก็ไม่ดี เพราะว่า ใช้เวลาในการทดสอบสูง เพราะว่า ใช้เวลาในการเตรียม environment สูง รวมทั้งเรื่องของ test converage ก็จะต่ำ และ code ก็ไม่ถูกปรับปรุงให้ดีขึ้น หรือให้สามารถเขียน unit test ได้ง่าย (Isolation) เรื่องของ ROI (Return On Investment) จึงมีความสำคัญอย่างมาก
ปล. สำหรับคนเริ่มต้นแนะนำให้เขียนทั้งหมด แล้วเราจะเรียนรู้ได้ว่า อะไรบ้างที่มีประโยชน์ อะไรบ้างที่ไร้ประโยชน์ อย่าเพิ่งมาถกเถียง จนกว่าจะได้ลงมือทำด้วยตนเอง
↧

เขียน Unit Test กันดี ๆ หน่อยนะ

February 23, 2017, 8:12 am
$
0
0

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

1. Unit test ต้องทำงานได้อย่างรวดเร็ว

เหตุผลหลักของการเขียน Unit test คือ ต้องทำการทดสอบ มีประโยชน์เพื่อ ทำให้มั่นใจว่าสิ่งที่สร้างและเปลี่ยนแปลงทำงานได้อย่างถูกต้อง ทำให้มั่นใจว่าสิ่งที่สร้างและเปลี่ยนแปลงกระทบต่อส่วนการทำงานอื่น ๆ หรือไม่ ถ้าพบเจอปัญหาได้อย่างรวดเร็ว ก็จะทำการแก้ไขได้ทันที นั่นหมายความว่า ความเร็วในการทดสอบต้องเร็วมาก ๆ เพื่อให้ได้รับผลหรือ feedback ที่รวดเร็ว เพื่อทำให้เรามั่นใจ เพื่อทำ regression ซ้ำแล้วซ้ำเล่า เมื่อเรามั่นใจแล้ว คนอื่น ๆ ก็มั่นใจตามไปด้วย ที่สำคัญทำให้เรากล้าที่จะแก้ไข หรือ ปรับปรุง code ให้ดีขึ้นอีกด้วย ลองคิดดูสิว่า ถ้า Unit test ทำการทดสอบนาน ๆ แล้ว ยังจะมีใครมาเขียนหรือทดสอบกันไหม !! ดังนั้น พยายามแยกส่วนการทำงานต่าง ๆ ออกมาเป็นส่วนย่อย ๆ ไม่รวมเอาการทดสอบพวก UI, Network และ Database มาใส่ในชุดการทดสอบ Unit test อย่าทำการ sleep หรือ wait ในชุดการทดสอบ Unit test
จำไว้ว่า ยิ่งทำการทดสอบ Unit test บ่อยมากเท่าไร ก็จะยิ่งได้รับประโยชน์จาก Unit test มากเท่านั้น

2. แต่ละ test case ต้องมีเป้าหมายในการทดสอบเดียวเท่านั้น

ในการแต่ละ test case นั้นต้องให้ผลออกมา fail หรือไม่ผ่าน เนื่องจากเป้าหมายหลักเพื่อออกแบบ test case ที่ช่วยหาข้อผิดพลาด หรือ ป้องกันข้อผิดพลาดนั่นเอง ดังนั้นชื่อของ test case ต้องอธิบายอย่างชัดเจน ว่าต้องการทดสอบอะไร ด้วยข้อมูลอะไร รวมทั้งความคาดหวังเสมอ ซึ่งความคาดหวังควรมีเพียงอย่างเดียวหรือเรื่องเดียวนั้น
ปล. ถ้าเขียน Unit test แล้วยังมานั่ง debug code แสดงว่า Unit test ยังใหญ่ หรือ ไม่ focus ในสิ่งที่ต้องการ ดังนั้นแทนที่จะ debug ก็ให้เขียน test case เพิ่มซะ

3. Unit test ต้องมีความน่าเชื่อถือ 100%

ไม่ว่าจะทดสอบที่ไหน ไม่ว่าจะทดสอบเวลาไหน ไม่ว่า network จะล่มไหม ไม่ว่า database จะพังไหม ถ้ามันเคยผ่านก็ต้องผ่านเสมอ ถ้ามันไม่ผ่านก็ต้องไม่ผ่านเสมอ ไม่ใช่ว่า บางครั้งผ่านบางครั้งไม่ผ่าน หรือดวงดีผ่านหรือดวงไม่ดีก็ไม่ผ่าน ถ้าเป็นแบบนี้จะไม่มีใครเชื่อถือ Unit test เลย สุดท้ายก็มองว่ามันคือสิ่งที่ไร้ประโยชน์
มาเขียน Unit test กันเถอะนะ
↧
↧

ขั้นตอนการเขียนโปรแกรมแบบขำ ๆ จาก Programming Geek

February 23, 2017, 6:05 pm
$
0
0

เช้านี้เปิดไปเจอรูปอธิบายเรื่องขั้นตอนการเขียนโปรแกรม (How to Program ?) จาก Programming Geek ซึ่งอธิบายไว้ว่าการเขียนโปรแกรมประกอบไปด้วย 4 ขั้นตอนคือ 1. Google the fucking problem 2. Open a StackOverflow link 3. Copy and paste the code 4. If did not work, go to step 2. If did work, go to step 1 ปิดท้ายด้วย FAQ ที่น่าสนใจ คำถาม :: What if there is no code ? คำตอบ :: Then it is impossible. แสดงดังรูป    ขอให้สนุกกับการเขียนโปรแกรมครับ
↧

ข้อผิดพลาดที่มักเกิดกับการพัฒนา Mobile App

February 25, 2017, 12:17 am
$
0
0

ในการพัฒนา Mobile app นั้นแตกต่างจาก Web app และ Desktop app มากมาย แต่กลับพบสิ่งที่ผิดพลาดสำหรับการพัฒนา Mobile app มากมาย เนื่องจากยังใช้แนวคิดจากการพัฒนาระบบอื่น ๆ มาใช้ จึงทำการสรุปสิ่งที่ผิดพลาดไว้นิดหน่อย

1. Mobile ทุกชนิดต้องแสดงผลและใช้งานเหมือนกันหมด

ตัวอย่างเช่น Mobile app ที่ทำงานบน Android และ iPhone จะต้องมีหน้าตา app ที่เหมือนกัน จะต้องแสดงผลเหมือนกัน จะต้องใช้งานเหมือนกัน เป็นสิ่งที่มักพบบ่อยมาก ๆ ทั้ง ๆ ที่แต่ละ plateform ล้วนแตกต่างกัน ทั้งการออกแบบ ทั้งการใช้งาน ทั้งมาตรฐานต่าง ๆ ดังนั้นสิ่งที่ควรทำคือ ออกแบบ app ให้ตรงตาม platform เพื่อให้ผู้ใช้งานไม่สับสน เช่น Android ก็ต้องยึดตาม Material Design เป็นต้น

2. ออกแบบโดยคิดว่า ผู้ใช้งานมี mouse และ keyboard

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

3. Mobile app ต้องสามารถทำงานบน device ต่าง ๆ ได้

ในแต่ละ device จะมี version ของ OS ที่แตกต่างกัน ยิ่งนานไปจำนวน device และ version ของ OS ยิ่งมีมากขึ้น ดังนั้นการพัฒนา Mobile app ให้ทำงานได้ทุก device เป็นเรื่องที่ยากมาก ๆ เป็นเรื่องที่ทำให้ code ของระบบมีความซับซ้อนอย่างมาก ยกตัวอย่างเช่น Android มี device ทั้งโลกเป็นหมื่น ๆ device Android มี version ของ OS เยอะมาก ๆ
ดังนั้นสิ่งที่ต้องทำคือ ต้องรู้ด้วยว่าผู้ใช้งาน app ของเราคือใคร ใช้ device อะไรบ้าง ? ใช้ OS version อะไรบ้าง ?
ถ้า device หรือ OS version อะไรที่มีการใช้งานต่ำ ๆ ก็ควรจะตัดใจ หรือ ไม่สนับสนุนซะ อย่าเสียเวลาไปดูแลเลย มิฉะนั้น จะทำให้ Mobile app ของคุณมี bug เยอะมาก ๆ เนื่องจาก code ซับซ้อน เนื่องจากการทดสอบย่อมไม่ครอบคลุมอย่างแน่นอน ดังนั้นจงเลือก จงตัด แล้วชีวิตการพัฒนาจะดีขึ้น

4. ไม่สนใจขนาดของ Network bandwidth เลย

เคยไหม ในการทดสอบจะใช้งาน Mobile app ผ่าน WIFI, 3G/4G หรือ Network ของบริษัท ซึ่งมีความเร็วสูงมาก ๆ แต่กลับลืมไปว่า ผู้ใช้งาน Mobile app ที่อยู่ในพื้นที่ที่มีระบบ Network ช้า ๆ จะสามารถใช้งาน Mobile app ได้หรือไม่ ? จะสามารถแสดงผลข้อมูลได้หรือไม่ เช่น รูปภาพ (มีขนาดที่เหมาะสมในแต่ละ Network หรือไม่) ดังนั้นแนะนำให้ทำการทดสอบใช้งาน Mobile app ใน Network ที่มีความเร็วที่แตกต่างกันด้วยนะครับ เพื่อตรวจสอบว่า Mobile app ทำงานได้ดีหรือไม่ ?

5. Mobile app ของเรานั้นกินแบตเตอรี่เยอะหรือไม่ ?

สิ่งที่อาจจะทำให้ผู้ใช้งานลบ Mobile app ออกไปนั่นก็คือ App นั้น ๆ กินแบตเตอรี่มาก ๆ ดังนั้นนักพัฒนาต้องทำการตรวจสอบเสมอว่า มี process อะไรที่ใช้งานแบตเตอรี่เยอะ ๆ บ้าง เช่น background process

6. การพัฒนา Mobile app ควรนำแนวคิด Asynchronous มาใช้เสมอนะ

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

สรุปจากการอ่านหนังสือ The Passionate Programmer

February 27, 2017, 7:19 am
$
0
0

ช่วงวันหยุดหยิบหนังสือ The Passionate Programmer มาอ่าน โดยเนื้อหาในหนังสือประกอบไปด้วย 5 ส่วนรวมทั้งหมดมี 53 หัวข้อ จึงทำการสรุปไว้นิดหน่อย น่าจะมีประโยชน์สำหรับการพัฒนา software บ้าง

ส่วนที่ 1

  • ต้องทำการศึกษาเทคโนโลยีใหม่ ๆ อยู่อย่างเสมอ
  • ต้องรู้ด้วยว่าความต้องการในตลาดงานเป็นอย่างไร อะไรเป็นที่ต้องการและไม่ต้องการ
  • ต้องเข้าใจในตัว business ด้วยนะ
  • อย่าเป็นคนที่น้ำเต็มแก้ว ต้องเรียนรู้จากผู้อื่นเสมอ
  • ทำการเรียนรู้เพื่อเข้าใจแต่ละภาษาโปรแกรมว่าแตกต่างกันอย่างไร มีเป้าหมายอย่างไร
  • อย่ากลัวที่จะตัดสินใจ เพราะว่าความกลัวทำให้เราไม่กล้าลงมือทำอะไร
  • ต้องทำการ update สิ่งที่รู้และไม่รู็อยู่อย่างสม่ำเสมอ เพื่อให้เรารู้ตัวเอง
  • ต้องลงในรายละเอียดของแต่ละภาษาโปรแกรม แต่ละเทคโนโลยีที่ใช้งาน
  • พยายามใช้เทคโนโลยีที่แตกต่าง ทั้งระบบใหญ่และระบบเล็ก เพื่อให้เข้าใจในตัวเทคโนโลยีต่าง ๆ
  • Love it or Leave it ดังนั้นถ้าชอบสถ้ารักสิ่งใดต้องทำให้มันเต็มที่

ส่วนที่ 2

  • ต้องเรียนรู้ พัฒนาและปรับปรุงในเครื่องมือและเทคโนโลยีที่ใช้ในงานปัจจุบัน
  • ต้องเรียนรู้เพิ่มเติมว่า จะทำอย่างไรให้ business มันดีขึ้นกว่าเดิมอยู่เสมอ
  • หา mentor ซะ
  • จงไปเป็น mentor ให้คนอื่นด้วย แล้วคุณจะเข้าใจมากยิ่งขึ้น
  • ต้องฝึกฝนอย่างสม่ำเสมอ ตัวอย่างเช่นเป็น developer คุณทำการฝึกเขียน code บ้างหรือไม่ ?
  • ต้องทำการเรียนรู้และเข้าใจเกี่ยวกับกระบวนการในการพัฒนา software เพื่อเข้าใจจุดแข็งและจุดอ่อน และนำมาใช้งาน
  • ทำการเรียนรู้การเขียน code ด้วยการอ่าน code ของคนอื่น
  • งานอะไรที่มันต้องทำซ้ำ ๆ ก็ทำให้มันทำงานแบบอัตโนมัติ (หัดขี้เกียจบ้าง)

ส่วนที่ 3

  • ถ้าต้องการหรืออยากได้อะไร ก็ให้ลงมือทำเดี๋ยวนี้ อย่ามันแต่หาข้ออ้าง
  • Predict the future
  • ควรทำการ review process และ ปัญหาต่าง ๆ ในทุก ๆ วัน
  • ต้องรู้และเข้าใจเป้าหมายของบริษัท
  • ทำการตั้งเป้าหมายระยะยาวของงานที่ทำอยู่ เช่นในสัปดาห์ต่อไปจะทำอย่างไรให้ดีขึ้นกว่าเดิม มีเป้าหมายเพื่อให้งานสำเร็จ
  • จงทำงานที่น่าเบื่อให้มันสนุกขึ้น เช่นการเปิดให้เห็นว่าแต่ละคนทำอะไรกันอยู่บ้าง ซึ่งอาจจะมีคนที่รู็และทำได้ดีกว่า
  • ทำสิ่งต่าง ๆ ให้คุ้มค่า รวมทั้งเราทำงานคุ้มเงินค่าจ้างหรือไม่
  • ทำการแบ่งปันความรู้ในสิ่งที่เราทำแก่คนอื่น ๆ ทั้งทีมและหัวหน้า
  • ต้องทำการวัดผลอยู่อย่างเสมอ เพื่อทำการปรับปรุงให้ดีขึ้น (Measure => Improve => Measure)
  • ทำงานให้คุ้มกับการว่าจ้าง เช่นในเวลางานก็ตั้งใจทำงาน
  • เรียนรู้ที่จะผิดพลาด เพื่อให้รู้เข้าใจและระวัง
  • ถ้าไม่รู้ก็บอกว่าไม่รู้
  • จงอย่ากลัวหรือกระต่ายตื่นตูมเกินไป
  • พูดได้ ก็ต้องทำได้ และแสดงออกมาให้เห็น

ส่วนที่ 4

  • ต้องรู้เสมอว่าคนรอบตัวคิดกับเราอย่างไรบ้าง
  • เป็นคนอ่อนน้อมถ่อมตน เข้ากับคนง่าย ๆ
  • ให้ทำการสรุปไว้ด้วยว่าเราทำการตัดสินใจอะไรไปบ้าง อย่างไร เพื่อนำมาวิเคราะห์เพื่อหาวิธีการปรับปรุงต่อไป
  • เน้นการสื่อสารด้วยการพูดคุยแบบเห็นหน้ามากกว่า email และ chat
  • รู้จักพูด สรุปให้ชัดเจนไม่ต้องมากความ
  • ทำอะไรต้องมีเป้าหมายเสมอ เพื่อทำให้คุณรู้ว่าต้องทำอะไรบ้างเพื่อไปยังเป้าหมายนั้น
  • ถ้ายังไม่เขียน blog ก็ให้มาเขียนกันเถอะนะ อย่ามีข้ออ้างเลย
  • ทำการสร้างตัวตนของเราขึ้นมาบ้าง
  • เข้าไป contribute กับ opensource บ้าง
  • ลองทำบางสิ่งบางอย่าง จากที่เคยทำนานเป็นสัปดาห์ให้เหลือวันเดียวดูบ้างสิ เริ่มต้นจากส่วนเล็ก ๆ นะ
  • ทำการ contribute กลับไปยัง software ที่เราใช้กันบ้าง หรือแนะนำ feature ใหม่ ๆ ไปยังผู้สร้าง

ส่วนที่ 5

  • ต้องทำการ update เทคโนโลยีต่าง ๆ ที่ใช้อยู่อย่างเสมอ เพราะว่าสิ่งที่ใช้ในวันนี้พรุ่งนี้อาจจะล้าสมัยหรือเลิกใช้ไปแล้ว
  • ลองทำอย่างอื่นดูบ้าง เช่นถ้าเป็น programmer ให้ลองทำเหมือนเป็น tester, manager ดูบ้าง ไม่ใช่เปลี่ยนงานแต่ลองทำอะไรที่แตกต่างดูบ้าง
  • เส้นทางระหว่างการเดินทางสวยงามกว่าเป้าหมายปลายทางเสมอ
  • ทำการสรุปสิ่งที่ผ่านมา ปัจจุบันและอนาคต พร้อมสรุปที่ต้องการศึกษาเพิ่มเติม
  • ให้ศึกษา trend และ ตลาดด้วยว่าเป็นอย่างไร อย่าเป็นกบในกะลา
  • Feedback จากเพื่อร่วมงานนั้นสำคัญมาก ๆ เป็นเหมือนกระจกบานใหญ่สะท้อนตัวเราเอง
  • อย่างเชื่อมั่นใจบางสิ่งบางอย่างมากจนเกินไป รวมทั้งอะไรที่ไม่ชอบก็ให้ลองนำมาใช้งานดูบ้าง
  • อย่างวางแผนแบบ Waterfall และอย่าทำอะไรที่ลูกค้าไม่ต้องการ
  • จงทำให้ดีกว่าเมื่อวาน หรือ ดีกว่าเดิมอยู่อย่างเสมอ
  • ออกไปทำอย่างอื่นบ้างเถอะ ให้ตัวเองเป็นอิสระบ้าง
ขอให้สนุกกับการพัฒนา software ครับ
↧
Viewing all 2000 articles
Browse latest View live
Search