Category Archives: Uncategorized

What you should know about iOS Dev in 2017

2-3 เดือนหลังๆมานี่ผมไม่ค่อยได้เขียน blog เท่าไหร่ ก็ด้วยเพราะว่า มัวแต่ทำ Video Swift ที่จะเปิดสอนในปีหน้า แต่วันนี้เป็นโอกาสดีที่ผมจะเขียนเกี่ยวกับ สิ่งที่คุณควรจะรู้เกี่ยวกับ Swift และ iOS ในปี 2017 ที่จะมาถึงนี้ ..

ผมเชื่อว่า ณ ตอนนี้จำนวน iOS Dev เมืองไทย คงมีเยอะมากกว่าสมัยที่ผมเพิ่งจะเริ่มเขียน Blog นี้ สัก 100 เท่าได้มั้ง มีคนเก่งมากมายกว่าแต่ก่อน ยิ่งถ้าเนื้อหาแบบ Basic แล้วผมว่า คนทั่วๆไปก็คงน่าจะพอรู้หมดแล้วแหละ เพราะว่า เวปต่างๆ ก็มีให้อ่านมากมาย ทั้งไทย ทั้ง ตปท. นับว่า สิ่งทีดีมากครับ ยิ่งมีคนเก่งมาก เท่าไหร่ ประเทศเราจะพัฒนาเร็วเท่านั้น

ตามความตั้งใจแรกของผมคืออยากจะเขียน blog เกี่ยวกับ mac dev ตั้งแต่สมัย Apple ยังไม่ออก iPhone ด้วยซ้ำไป จนปัจจุบันมีนักพัฒนา iOS , Mac มากมาย ซึ่งมันก็บรรลุจุดประสงค์ของผมแล้ว เอาตรงๆนี่ผมยังตกใจเลยว่า นี่ผมเขียน blog นี้มาตังแต่ปี 2008 เลยเหรอ แม้ว่าจำนวน Dev จะเพิ่มมากกว่าแต่ก่อน อย่างไรก็ตาม ผมคิดว่า จำนวนไม่ใช่สิ่งสำคัญแล้ว สิ่งที่สำคัญกว่าคือ คุณภาพ ซึ่งการที่จะยกระดับ Dev ไทยให้เก่ง กว่า ณ ปัจจุบัน ได้นั่นก็คือ Dev เองนั้นควรจะรู้ว่า ตอนนี้ โลก เค้าไปถึงไหนกันแล้วบ้าง ดังนั้นผมจะขอ List สิ่งต่างๆ ที่ iOS และ Swift Dev นั้นควรจะศึกษาไว้ หรือถ้าไม่ศึกษา ก็ควรจะได้ยินคำศัพท์ พวกนี้บ้าง ซึ่งผมจะแบ่งเป็นหลายๆ หัวข้อ อธิบาย สั้นๆ ว่ามันคืออะไร ส่วนที่เหลือ ก็ไปศึกษากันเองนะครับ

Programming Paradigm

  • Protocol Oriented Programming
    สำหรับปีนี้ค่อนข้างจะมาแรงมาก คือเป็นแนวทางการเขียนโปรแกรมด้วย protocol (ส่วนตัวผมคิดว่าใช้ protocol  แบบเพียวๆไม่ได้หรอก แต่มันเป็น concept ที่ควรศึกษาไว้)
  • Functional Programming
    แม้ว่า swift ไม่ใช่ภาษา functional แบบเพียวๆเหมือนอย่าง haskell แต่ว่า swift ก็เขียนแบบ functional ได้เหมือนกัน อย่างน้อยๆคุณควรจะใช้ filter , map , reduce อะไรแบบนี้เป็นบ้าง

Tools

  • Cocoapod
    หลายคนน่าจะคุ้นเคยกันดี กับ package manager ตัวนี้ คือถ้ายังไม่เข้าใจว่ามันคืออะไร คุณควรจะศึกษามันเสียตั้งแต่วันนี้
  • Carthage
    เป็น package manger เหมือนกัน แต่มีแนวคิด ต่างออกไปจาก cocoapod เพราะมันไม่รวม repo ไว้ตรงกลาง และมันไม่ไปแก้ไข project setting ของเรา (หลังๆมานี่ผมใช้ carthage แทน cocoapod)
  • Fastlane
    มันคือ Continues Delivery Tool ตัวหนึ่ง และมันประกอบไปด้วย เครื่องมืออีกยิบย่อยมากมาย ช่วยให้เราทำงานได้เร็วขึ้น
  • Swift Package Manager
    ตัวนี้เป็น package manger ของ swift เองเลย ณ ปัจจุบันที่ผมเขียน ยังไม่รองรับ iOS แต่เหมาะสำหรับใช้งานกับ Linux
  • Swift Tool Chain
    คือถ้าใครเขียน Swift บน Linux หรือพวก Server Side อันนี้ควรจะรู้บ้าง
  • Fabric (Crashlytic , Beta)
    อันนี้ของพื้นฐานเลยนะครับ สำหรับช่วยให้เราดูได้ว่าหลังจาก ปล่อย app ไปแล้วมัน crash ตรงไหน

Architecture Pattern

  • MVC
  • MVVM
  • MVP
  • Viper

ถ้าเขียน iOS นี่อย่างน้อยคุณควรจะเข้าใจ Architecture Pattern อย่าง Model View Control (MVC) บ้างนะครับ ถ้าแม้แต่ MVC ยังไม่รู้ว่ามันคืออะไร นี่ผมว่าแย่ครับ ควรจะรีบไปศึกษาให้เข้าใจ สำหรับคนที่เข้าใจแล้ว หลังๆมานี้ ก็มีพวกโมเดล อื่นๆ ที่ควรจะรู้ไว้บ้างครับ เพราะหลายๆที่ก็เริ่มใช้โมเดลอื่นนอกจาก MVC แล้ว

Mind-Set

  • Agile
  • Continues Integration , Continues Delivery ( CI/CD)

สมัยนี้แล้ว บริษัทไหนยังทำงานแบบ waterfall อยู่อันนี้ผมว่า ควรจะลองศึกษาการทำงานแบบ agile ได้แล้วนะครับ เพราะทั่วโลกเค้าใช้วิธีการทำงานแบบนี้แทบจะทั้งนั้น (ผมไม่ได้บอกว่ามันดีที่สุดนะ อย่าง Google เองก็ไม่ได้ใช้ Agile ) นอกจากการทำงานแบบ agile แล้ว สิ่งหนึ่งที่คุณจะได้ยินบ่อยมากคือ CI/CD ควรจะศึกษาไว้ครับ

Engineering Practice

  • Unit Test
  • TDD
  • Automate Test
  • Pair Programming

ใครยังไม่เคยเขียน Unit Test เลย ควรจะลงมือศึกษามันโดยด่วน จากประสบการณ์ส่วนตัว ถ้าคุณเขียน Unit Test ไม่เป็น ผมบอกเลยว่า คุณแทบจะไม่มีโอกาสได้ทำงานกับบริษัทชั้นนำเลย (เว้นแต่ว่าคุณทำงานสาย Game การเขียน unit test , automate test นั้นไม่ค่อยมีใครทำเท่าไหร่)

Swift Server Side

  • IBM Kitura
  • Vapor
  • Perfect

ตอนนี้ก็มีหลายบริษัท กำลังเอา Swift ไปเขียน backed ผมว่านี่เป็นโอกาสที่ดี ทีคุณน่าจะลองศึกษา swift สำหรับ server บ้างครับ ส่วนตัวผมเคยลองเล่นทั้ง Kitura กับ Vapor ก็คิดว่า ในปีหน้านี้ มันมาแน่ๆครับ

Platform / Service

  • Firebase
  • AWS
  • Realm
  • Heroku

ถ้าเอ่ยชื่อ  firebase แล้ว คนที่ทำ mobile ฝั่ง android น่าจะรู้จักดี แล้วก็ไม่ได้จำกัดแค่ใน android  นะ ใน iOS ก็ใช้ได้เหมือนกัน นอกจากนั้นก็มีอย่างอื่นให้ลองเล่นเช่น heroku หรือ aws , แม้ว่าสิ่งเหล่านี้จะดูเหมือนเป็น server side มากกว่า mobile แต่ผมว่าควรศึกษาไว้บ้างครับ

Others Useful tools

  • Slack
  • Brew
  • Postman
  • Docker
  • Shell ( Bash / Zsh )
  • git / svn

สำหรับนักศึกษา จบใหม่ อาจจะไม่เคยใช้ git/svn ก็ควรจะเรียนรู้มันโดยเร็วครับ แต่ถ้าคุณทำงานมา 1-2 ปีแล้วยังไม่รู้จัก git , svn นี่ผมว่าคุณเป็น dev ที่ใช้ไม่ได้ครับ  และปิดท้ายด้วย tools ที่ควรจะรู้ไว้บ้าง อย่างการใช้ shell command หรือว่า postman เป็นต้น และถ้าใครยังคุยงานโดยใช้ Line นี่ผมว่าควรเปลี่ยนไปใช้  slack ได้แล้วนะครับ

ในส่วนที่ผมไม่ได้เขียนถึง ก็คือพวก Library ต่างๆอย่าง Alamofire , Quick , SwiftyJSON อะไรแบบนั้น เพราะผมคิดว่า มันแบ่งออกย่อยเป็นหมวดหมู่เยอะมากมาย  ก็เลยไม่ได้เขียนไว้ ผมแนะนำให้ไปดูที่ https://github.com/Wolg/awesome-swift

และในส่วนของการเพิ่มพูนความรู้ ขอแนะนำให้อ่านหนังสือ พวกนี้ครับ

Book

  • Clean code a handbook of agile software craftsmanship ( Robert C. Martin)
  • Functional Swift: Updated for Swift 3 (Chris Eidhof)
  • Code Complete : A Practical Handbook of Software Constructoin ( Steve McConnell)
  • Advance Swift : Update for Swift 3 (by Chris Eidhof, Ole Begemann , Airspeed Velocity )

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

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

และขอบคุณทุกคนครับ ที่ตามอ่าน blog ของผมมาโดยตลอด
สุดท้ายนี้ ขอให้ ปี 2017 ที่จะมาถึง เป็นปีที่มีความสุขครับ Happy Coding 🙂

Closure Parameter

ช่วงนี้งานเยอะมาก ไม่ค่อยได้ update และอัด video tutorial สักเท่าไหร่ ช่วงนี้หยุดหลายวันมีเวลาได้เขียน blog บ้าง เอาละเข้าเรื่องเลยดีกว่า

Closure ในภาษา Swift ก็เหมือนกับ Block ในภาษา Objective-C อธิบายสั้นๆมันก็คือ รูปแบบหนึ่งของฟังก์ชันที่ต้องไม่มีชื่อ เมื่อเราเขียนโปรแกรมด้วยภาษา swift สักระยะหนึ่ง ก็จะได้ใช้ closure อย่างแน่นอน สำหรับโพสต์นี้ผมคงไม่ได้มาอธิบายว่า อะไรคือ closure แต่จะพูดถึง สไตล์ การเขียนเพื่อทำให้โค้ดมันอ่านง่ายมากขึ้น สำหรับคนที่เพิ่งหัดเขียน swift ก็ควรจะศึกษา closure ไว้นะครับ เพราะยังไงก็ต้องได้ใช้แน่นอน

ปกติการใช้ closure มักจะเห็นได้บ่อยกับฟังก์ชันคือ ตัวฟังก์ชันมักจะรับ closure เข้ามาเป็นพารามิเตอร์ เช่น ฟังก์ชัน sort ของ Array

เมื่อพิจารณาจากฟังก์ชัน sort ก็จะเห็นว่าตัวแปร isOrderedBefore นั้นเป็น closure ที่รับพารามิเตอร์สองตัว เป็นสตริง และส่งค่ากลับเป็น Bool เมื่อเรียกใช้งานฟังก์ชัน sort ก็จะมีลักษณะดังนี้

โดยทั่วๆไป ฟังก์ชันที่มี closure เป็นพารามิเตอร์ตัวสุดท้าย มักจะเขียนในลักษณะ trailing closure ดังนี้

การใช้ trailing closure นี้ก็ทำให้โค้ดสั้น กระชับ มากขึ้น

ในภาษา swift การใช้ closure นั้นมีประโยชน์มาก และเขียนลดรูปให้สั้นลงได้หลายแบบ แต่อย่างไรก็ตาม ถ้าหากฟังก์ชันรับพารามิเตอร์ ที่เป็น closure สัก 2 ตัว ก็จะเริ่มเกิดปัญหา คือ โค้ด มันอ่านยากกกกกก เช่นฟังก์ชัน animateWithDuration ของ UIView ซึ่งมีหน้าตาดังนี้

จากตัวอย่างจะเห็นว่า ฟังก์ชันนี้รับพารามิเตอร์มาด้วยกัน 3 ตัวคือ

  1. duration: NSTimInterVal
  2. animation: () -> Void
  3. completion: ((Bool) -> Void)?)

เมื่อเรียกใช้งาน โค้ดจะมีลักษณะดังนี้

ในครั้งแรกที่เห็น ผมเชื่อว่า หลายคน งง บอกตรงๆว่าแรกๆ ผมก็งง ถ้าคุณไม่งง แสดงว่าคุณได้เข้าใจ closure ในระดับดีมาก แต่สำหรับคนที่งงว่า โค้ดมันทำอะไร ถ้าลองถ้าพิจารณาอย่างคร่าวๆ ก็พอจะเห็นว่า โค้ดนี้  view จะเปลี่ยนขนาดของ frame จากนั้น view ก็จะเรียกเมธอด removeFromeSuperView

ทำไงดี ให้โค้ดมันอ่านง่ายขึ้น ?

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

สำหรับตัวผมเอง มีเทคนิค 2 อย่าง ที่คิดว่า ทำให้โค้ดมันอ่านง่ายขึ้น

  • อย่างแรกคือตัวแปร closure ขึ้นมา
  • สองก็คือประกาศฟังก์ชัน

เนื่องจาก swift นั้นได้ให้ function/closure เป็น first class variable ดังนั้น เราจึงสามารถประกาศตัวแปรให้เป็น function/closure ได้ ซึ่งการประกาศตัวแปรให้เก็บ closure นี้ก็จะมีการประกาศตัวแปรลักษณะแบบนี้

เมื่อนำโค้ด ฟังก์ชัน dissmiss มาเขียนใหม่ก็จะได้ว่า

ส่วนวิธีที่สอง ก็คล้ายกับวิธีการแรก คือใช้การประกาศฟังก์ชันแทน

แม้ว่าโค้ดที่เขียนใหม่ทั้งสองจะเขียนยาว กว่าเดิม แต่จะเห็นได้ว่า โค้ด ที่เขียนไปนั้น อ่านง่ายกว่าเดิมเยอะมาก

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

สอบถามความคิดเห็นของหนังสือ Objective-C

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

โปรดสละเวลาของท่านตอบแบบสอบถาม ของผมด้วยนะครับ

>> แบบสอบถาม

เราจะเป็น Rockstar

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

“I think everybody in this country should learn how to program a computer because it teaches you how to think.” — Steve Jobs, the Lost Interview

ตัวอย่าง Source code ในหนังสือ Objective-C

หลังจากเขียนหนังสือไปได้ ประมาณ 8 บท ( จริงๆแล้ว 7 เพราะบทที่ 6 ยังไม่ได้เขียน ) คิดอยู่นานว่าจะเอา Source Code ตัวอย่างให้ที่เขียนไว้ในหนังสือ ปล่อยให้โหลดด้วยดีหรือเปล่า  เพราะ กลัวว่าผู้อ่านจะโหลดไปแล้วไม่ได้ทดลองเขียน code ด้วยตัวเอง ทำไมต้องกลัวด้วย ? คำตอบผมคือว่า การเขียนโค้ดด้วยตัวเอง มันทำให้เราเข้าใจคุ้นเคยกับความผิดพลาดที่เกิดขึ้นระหว่างเขียนโค้ด ยกตัวอย่างเช่นเกิดคุ้นเคยกับ syntax error  เป็นต้นว่าอาจจะลืมเครื่องหมาย ; ปิดประโยค หรืออาจจะเขียนชื่อตัวแปรผิด แต่ในกรณีที่โหลดโค้ดไปนั่งดู และทดลองคอมไพล์อย่างเดียว เราจะไม่ได้ประสบการณ์การเจอ error เลย ซึ่งการเจอ bug หรือ error มันเป็นเรื่องปกติของการเขียนโปรแกรมากๆ และยิ่งถ้าหัดเขียนโปรแกรมด้วยภาษาที่ไม่คุ้นเคยด้วยแล้ว มันจำเป็นมากที่เราจะต้องคุ้นเคยกับสิ่งเหล่านี้  การเจอ error บ่อยๆจะเป็นประโยชน์ในระยะยาวครับเพราะเมื่อเราคุ้นเคยกับมัน ต่อไปเราก็จะสามารถแก้ปัญหาโปรแกรมที่เราเขียนขึ้นเองได้ นั่นเอง

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

Source Code ทั้งหมดผมเอาไว้ที่ Git hub ตาม link นี้นะครับ https://github.com/macfeteria/Objective-C-Demo ( ณ วันที่ผมเขียนจะมีแค่บทที่ 8 ส่วนบทที่ 1 – 7 จะตามมาทีหลัง )

สำหรับผู้ที่ไม่เคยใช้ Github มาก่อนผมมีวิธีการโหลด Source code อย่างง่ายๆดังขึ้นตอนต่อไปนี้

Git

เมื่อเปิด link ขึ้นมาก็จะพบกันหน้าเวปดังรูป หลังจากนั้นจะเห็นปุ่มด้านซ้ายมือที่เขียนว่า Zip ( อยู่ใกล้ๆกับ Clone in Mac) เพื่อทำการ  download หลังจากนั้นก็จะได้ source code เป็น zip ไฟล์มาครับ อย่างไรก็ตามวิธีการนี้ เมื่อผมทำการ update code เช่นเพิ่ม source code ของบทอื่นๆเข้าไป ก็ต้องโหลด source zip file ใหม่ครับ ( ดูเวลาได้ครับครับว่า update ล่าสุดเมื่อไหร่ )

ขอให้สนุกกับการเขียนโปรแกรมครับ 🙂