Home Automation : Part 1

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

ผมว่าเปลี่ยนใหม่ดีกว่า ถ้าหากเราเรียกมันใหม่ด้วยภาษาที่ไม่ได้ฟังเวอร์วังอลังการ มันควรจะใช้คำว่า Home Automation หรือ ระบบบ้านอัตโนมัติ น่าจะดูตรง และสื่อความหมาย มากกว่าที่จะใช้คำว่า Smart Home แล้วมาเรียกเป็นภาษาไทยแบบเท่ๆว่า บ้านอัจฉริยะ นี่ถ้าเติม 4.0 ไปก็คงจะดู digital เข้ากับสมัยนี้มาก :p

เข้าเรื่องเลยดีกว่า คือพอดีว่าผมกำลังซื้อบ้านใหม่ และด้วยความที่ผมก็คุ้นเคยกับ Embedded System , IOT แล้วก็พวก Mobile App มาบ้าง ก็เลยสนใจอยากทำระบบ ควบคุม ต่างๆภายในบ้าน ด้วยมือถือดูบ้าง เผื่อว่าวันหนึ่งอยู่ต่างประเทศ อยากจะเปิดไฟรอบบ้านเพื่อเพิ่มความปลอดภัย หรือ ลืมรดน้ำต้นไม้ก็สั่งให้มัน รดน้ำเอง รวมไปถึงระบบกล้อง CCTV กันขโมย อะไรแบบนั้น ผมเลยเริ่มต้นลองหาข้อมูลในกูเกิ้ลศึกษาดู แต่ก็พบว่า ข้อมูลภาษาไทย หรือเวปไทยนั้น มีข้อมูลน้อยมากๆ คือ เวลาที่หาข้อมูลเนี่ย พวกเวป Smart Home ในไทยก็มีหลายเวปนะ แต่ว่า ขายของกันอย่างเดียว ประมาณว่า อยากได้แบบนั้น แบบนี้ ก็โทรสอบถามที่บริษัท เสร็จแล้วเค้าก็คิดราคามาให้ อะไรทำนองนั้น หรือไม่ก็มีเป็นคลิป demo ให้ดูว่า เออ อุปกรณ์มันเชื่อมต่อกับมือถือได้ เปิด ปิด ไฟได้ โดยที่เราก็ยังไม่ได้รู้เลยว่าหลักการทำงานยังไง ใช้ระบบอะไร เกิดอยากจะซื้ออุปกรณ์มาเพิ่มมันเชื่อมต่อกันได้ไหม และสุดท้ายที่ผมจะเจอบ่อยก็คือ เวปโปรเจคของทาง Arduino  หรือ Raberrry Pi ทำเป็นโครงงาน ต้องซื้ออุปกรณ์เสริม มาบัดกรี ทำวงจร เขียนโปรแกรม ปิดเปิดไฟ อะไรทำนองนั้น ซึ่งดูแล้วมันออกไปทางโครงงานทดลองมากกว่า ยังไม่เห็นว่ามีใครเอาไปใช้งานจริงจัง แบบติดทั้งบ้าน ผมก็ไม่แน่ใจว่าถ้าเอามันมาใช้งานแบบจริงจัง มันจะโอเคไหม ? เสียแล้ว ซ่อมยังไง อะไรแบบนั้น อันที่จริงมันก็พอจะมีเวปที่อธิบายเรื่องพวกนี้บ้าง ในเชิงของวิชาการ แต่มันทาง IOT กับไฟฟ้าซะเยอะมาก อธิบายแบบหลักการไฟฟ้า ซึ่งคนทั่วๆไป  หรือแม้กระทั่งคน IT เองก็ไม่น่าจะเข้าใจได้ง่ายสักเท่าไหร่

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

Home Automation

เล่าให้ฟังแบบเบสิกจาก Fundamental กันก่อนละกันว่า  Home Automation หรือ Smart Home ? เนี่ยมันคืออะไร

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

ในโลกของ Home Automation นั้นมีบริษัทผู้ผลิตอุปกรณ์ไฟฟ้าต่างๆมากมาย เช่น หลอดไฟ ,สวิตช์  ปลั๊ก เซ็นเซอร์ต่างๆ ซึ่งบริษัทต่างๆเหล่านี้ได้ร่วมมือกันก่อตั้งเป็นกลุ่ม (เรียกว่า Alliance) และกำหนด มาตรฐานต่างๆที่ใช้ในการ เชื่อมต่ออุปกรณ์ต่างๆเข้าด้วยกัน หรือที่เรียกว่า Protocol ซึ่งมันก็มีหลายมาตรฐาน เพราะแต่ละบริษัทก็ร่วมมือกันตั้งกลุ่มของตัวเอง มันก็คล้ายๆกับ ไฟฟ้า นั่นแหละครับ บางประเทศใช้ 220V บางประเทศใช้ 110V  หรืออย่างปลั๊กไฟ ถ้าหากไปยุโรปก็ใช้ปลั๊กแบบหัวกลม สามขา ถ้าเป็นที่อังกฤษ ก็อีกแบบ ญี่ปุ่น ไทย ก็ใช้ขาแบนสองขา  ถ้าหากเอาอุปกรณ์ที่มีขา ไม่เหมือนเต้ารับ มันก็ใช้กันไม่ได้ อะไรแบบนั้น เช่นเดียวกัน Home Automation มันก็ต้องมีการกำหนดวิธีการเชื่อมต่ออุปกรณ์ต่างๆ เช่นเดียวกัน

Protocol

จากการค้นข้อมูลมา พอจะสรุปได้ว่า Protocol ที่เค้าใช้กันก็จะมีหลักๆคือ

  • WiFi
  • Zigbee
  • Apple HomeKit
  • Z-Wave
  • X10
  • อื่นๆ (Insteon, Bluetooth, Thread)

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

ก่อนที่จะไปดูแต่ละอัน ลองคิดกันเล่นๆครับว่า ถ้าเดาจากชื่อเลย เนี่ย พวกคุณจะใช้อะไร ?

เดาว่า ก็น่าจะเป็น WiFi ใช่ไหมครับ ?

WiFi

ผมก็เหมือนๆกับคนทั่วๆไปแหละครับ ที่เวลาคิดเรื่อง ระบบความคุมในบ้าน ผ่านมือถือ นี่คงคิดเรื่อง ระบบ WiFi ก่อน เพราะว่าเราคุ้นเคยกับสัญญาณ แบบนี้อยู่แล้ว  ถ้าหากลองค้นหา คำว่า “ควบคุมไฟผ่านมือถือ” ใน Google  เนี่ยจะเจอเวปเกี่ยวกับโปรเจค Arduino หรือ Raspberry Pi ควบคุมไฟ มากมาย ซึ่งโปรเจคเหล่านี้มักจะเป็นการควบคุมผ่านทาง  WiFi แทบทั้งสิ้น คือประมาณว่า เอา Raspberry Pi ต่อ WiFi แล้วก็มี บอร์ด ความคุมไฟ จากนั้นเราก็สั่งงานผ่านตัว Raspberry อีกที อะไรทำนองนี้

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

ตามที่ผมค้นเจอในเวป ก็พอจะมีบริษัทในไทย  ที่ทำอุปกรณ์พวก Home Automation (แบบ SME) อยู่บ้างนะครับ ซึ่งแทบจะทั้งหมด จะใช้สัญญาณแบบ Wifi หมดเลย ส่วนหนึ่งเพราะว่ามันทำง่าย มีบอร์ดราคาถูกให้ลองทำเล่นกัน ก็เลยไม่แปลกใจที่มีโปรเจคอย่าง Raberry Pi หรือ Arduino เต็มไปหมด แม้ว่ามันจะพัฒนาง่าย ทำเองก็ได้ แต่ปัญหาของ  Wifi คือ เมื่อเราเชื่อมต่อ อุปกรณ์หลายตัว มันจะตอบสนอง (response) ช้าลง และการใช้สัญญาณ  WiFi เนี่ยมันใช้พลังงานมากในการส่งและรับสัญญาณ ซึ่งแทบจะเป็นไปไม่ได้เลยที่จะพัฒนาอุปกรณ์ที่ใช้ถ่านไฟฉายหนึ่งก้อน แล้วให้มันทำงานอยู่ได้สัก 1 ปี เพราะอย่างที่บอกไปว่ามันกินไฟ ผมไม่ได้บอกว่า อุปกรณ์ที่ใช้สัญญาณนี้มันไม่ดีนะ เพียงแต่มันไม่ได้รับความนิยมจากปัญหาที่ผมบอกไป

Apple HomeKit

สำหรับ แอปเปิ้ลโฮมคิท นั้น เปิดตัวมาได้ 2-3 ปีแล้ว ตัวของ Apple HomeKit นั้นใช้  Wifi ร่วมกับ Bluetooth ข้อเสียหลักๆ มันก็เหมือนๆกับ Wifi นั่นแหละครับ แถมมันผูกไว้กับ Apple เจ้าเดียว แล้วก็อุปกรณ์ต่างๆที่ออกมารองรับ ก็น้อยมากๆ เมื่อเทียบกับเจ้าอื่นๆ ในส่วนข้อดีของ Apple HomeKit คือ มันสามารถเชื่อมต่อกับ Siri ได้ แล้วก็ควบคุมอุปกรณ์ผ่านทาง iOS ได้โดยตรง ซึ่งถ้าหากที่บ้านมีทั้ง Apple TV , iPhone , iPad , Apple Watch เป็นสาวกเต็มตัวขนาดนี้แล้ว ก็อาจจะเป็นทางเลือกที่ดี

X10 (RF 433)

สำหรับโปรโตคอลแบบนี้ถือว่าค่อนข้างเก่า เพราะเกิดมานานแล้ว ตั้งแต่ปี 1975 หลักการของมันก็คือใช้สัญญาณ วิทยุความถี่ RF 433 เป็นตัวส่งสัญญาณ คืออะไรก็ตามที่ผมเห็นว่ามันใช้คลื่น 433 นี่ขอรวมเอาไว้ในหมวดนี้หมดเลยละกัน แม้ว่าบางอันอาจจะไม่ได้ใช้ Protocol X10 ก็ตาม พวกโครงงาน Raspberry Pi หรือ Arduino ก็นิยมนำมาใช้เหมือนกัน ข้อดีของมันคือ อุปกรณ์ส่วนมากจะราคาถูก แต่เนื่องจากความถี่ย่านนี้ ค่อนข้างต่ำ มันจึงถูกรบกวนได้ง่าย (มี noise ในสัญญาณเยอะ) และไม่ค่อยเสถียร นอกจากนี้ปัญหาหลักๆของ X10 คือมันช้ากว่าโปรโตคอลอื่นๆ และไม่มีการ encryption ข้อมูลเลย เหมือนๆกับ remote รถยนต์ ,ทีวี ,แอร์นั่นแหละครับ  ไม่มีการเข้ารหัสข้อมูล ซึ่งเราอาจจะไปเอารีโมทบ้านข้างๆ มาเปิดแอร์ บ้านเราได้ ซึ่งอันนี้ก็แบบเดียวกัน และอุปกรณ์ใหม่ๆที่รองรับ  X10 นั้นก็มีให้เห็นบ้าง ซึ่งมักจะเป็นอุปกรณ์จากจีน ดังเช่น BROADLINK , SONOFF (เจ้านี้ทำ Wifi ด้วย)

หรืออย่างของไทย ก็มี GRATIA (เข้าไปดูในเวปก็เห็นทำให้หมู่บ้านดังๆ หลายเจ้าอยู่ ขอนอกเรื่องนิดหนึ่ง ถ้าเข้าไปดูในเวป

นี่ผมเห็นบางหน้ามี แฝง Google Ad-sense อยู่ด้วย ไม่แน่ใจว่า ฝังเอง หรือว่าคนทำเวปแอบเนียนใส่มาให้)

Zigbee

Zigbee ออกมาตามมาตรฐานของ IEEE 802.15.4 ใช้ความถี่ที่ 915 MHz หรือใช้ความถี่ 2.4 GHz (ความถี่เดียวกับ Wifi) โปรโตคอล Zigbee นี้มีการเข้ารหัสด้วย AES128 และในปัจจุบันคือ version 3 มันได้ถูกออกแบบมาสำหรับ Home Automation ตั้งแต่แรก ดังนั้นมันจึงใช้พลังงานต่ำ และมีการทำงานเป็นลักษณะเครือข่าย mesh คือมันจะเชื่อมต่ออุปกรณ์ใกล้ๆตัวได้มากกว่า 1 อย่าง แล้วเมื่อมีการส่งสัญญาณ อุปกรณ์ต่างๆก็จะคอยทวนสัญญาณ กันไปเป็นทอดๆ และเนื่องจากมันมีการเข้ารหัส ก็ไม่ต้องกังวลใจในระดับหนึ่งว่าจะมีใครแอบมาเปิด อุปกรณ์ไฟฟ้าของคุณหรือเปล่า

ซึ่งเจ้าใหญ่ๆที่ทำก็จะมี LG, Logitech, Samsung รวมไปถึง Philips อย่างเช่น  Philips Hue lights ถ้าสังเกตดูจะเห็นว่า บริษัทส่วนมากจะมาทาง เอเชียกันหมดเลย ส่วนบริษัทคอมพิวเตอร์จากจีนที่หันมาทำอุปกรณ์ ที่เราพอจะคุ้นกับชื่อ ก็จะมี Xiomi ซึ่งก็ได้ทำ Xiomi Aquar Switch ออกมา รวมไปถึงลำโพงสั่งงานด้วยเสียง (ภาษาจีน) ข้อเสียเท่าที่ผมหาข้อมูลมาได้ก็คือ อุปกรณ์ที่ต่างยี่ห้อกัน มักจะทำงานร่วมกันไม่ค่อยราบลื่น หรือใช้กันไม่ได้ (ซึ่งผมก็ไม่เคยใช้ เลยบอกไม่ได้เหมือนกันว่าจริงหรือเปล่า)

Z-Wave

ตัวนี้ก็ออกมาตามมาตรฐานของ IEEE เช่นเดียวกันกับ Zigbee มีการเข้ารหัสเช่นเดียวกัน ได้ออกแบบมาสำหรับ Home Automation เหมือนกันดังนั้นมันจึงกินไฟน้อย และ Z-Wave ก็มีการทำงานเป็น mesh network เช่นเดียวกัน มันใช้ความถี่ในช่วง 800-900 MHz โปรโตรคอลนี้พัฒนามาตั้งแต่ปี 2001 ซึ่ง ณ ตอนนี้ ก็ได้พัฒนามาเป็น Z-Wave Plus เนื่องจากโปรโตคอลนี้มีบริษัทใหญ่ๆ สนับสนุน เป็นจำนวนมาก อย่างเช่น GE Electronic , Samsung , Honeywell, Bosh, Belkin  ดังนั้น มันจึงมีอุปกรณ์รองรับมากมาย เมื่อเทียบกับโปรโตคอลอื่นๆ

Insteon, Bluetooth, Thread

สำหรับโปรโตรคอลอื่นๆก็มีหลายอย่างครับ เช่น Insteon แต่อุปรกรณ์รองรับน้อย หรืออย่าง Thread นี้ก็พัฒนามาจาก Google อุปกรณ์ที่ใช้งานก็จะมี แต่ของ Nest (ถูก Google ซื้อไป) หรือ อย่าง Bluetooth นี่ก็ไม่ค่อยมีคนใช้ทำ Home Automation สักเท่าไหร่

What’s next ?

เราต้องกังวลไหม กับการเลือก โปรโตคอล จริงๆมันก็ไม่มีคำตอบตายตัวนะครับว่า จะใช้อะไร ถ้าเป็นสาวก Apple เลือกใช้ HomeKit ก็อาจจะโอเค ถ้าอยากเชื่อมต่อกับอุปกรณ์อื่นๆ อย่างเช่น sensor หลายอย่าง ก็อาจจะเลือกเอา zigbee , z-wave หรือถ้ามีงบน้อย หันไปมอง RF433 ก็อาจจะโอเค หรือถ้ามาสาย Hack อยากทำเอง ก็ลองหา Rasberry Pi , Arduino มาต่อเองทำให้มันควบคุมผ่าน Wifi ก็ได้ แล้วแต่ต้องการเลย

จากที่เล่าให้ฟังทั้งหมดนั้น ตัวผมเอง ตัดสินใจเลือกใช้ Z-Wave ด้วยเหตุผลคือ มีผู้ผลิตเครื่องใช้ไฟฟ้าทำอุปกรณ์รองรับเป็นจำนวนมาก คือผมไม่ได้ต้องการแค่ควบคุมไฟ แต่อยากจะเชื่อมต่อพวก sensor อื่นๆ ด้วย การใช้ Z-Wave น่าจะเหมาะสมสุดละ  แต่เดี๋ยวไว้ Blog หน้า ผมจะมาเล่าให้ฟังว่า เห้ยยย มันไม่ได้ง่ายเลย กว่าที่จะมาเขียนๆ และสรุปให้ฟัง และแม้ว่าผมจะเลือก Z-Wave ที่มีอุปกรณ์หลายอย่างสุด แต่มันก็ยังเจอปัญหา  เดี๋ยวมาเล่าให้ฟังในครั้งหน้า ว่าผมเจออะไรมาบ้าง (ไม่ได้น่ากลัวหรอก แต่มันทำเอาผมสับสนอยู่หลายวัน)

Vapor

ไม่ได้เขียน blog ทาง  technical หลายเดือน เพราะในช่วงนี้ผมต้องเขียน api backend  สำหรับ mobile app ตัวหนึ่ง หลังจากการลองผิด ลองถูกอยู่นาน ก็เลยเลือกเขียนด้วย Vapor และบทความนี้ ผมคงไม่ได้เขียน tutorial การใช้ vapor อย่างเช่นให้แสดง Hello world อะไรง่ายๆแบบนั้น แต่ผมจะมาเล่าให้ฟังถึง ปัญหา , สิ่งที่เจอ , feature ต่างๆจากที่ได้ลองเขียน Vapor มาประมาณเดือนหนึ่ง

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

คือในช่วงหลายเดือนที่ผ่านมา ผมได้ทำโปรเจคอยู่ตัวหนึ่ง ซึ่งเป็นโปรเจคใหญ่ที่ประกอบไปด้วยโปรเจคย่อยๆสามอย่างหลักๆด้วยกันคือ อย่างแรกเป็น api backend ทำหน้าที่เป็นตัว core service หลัก ในส่วนต่อมาคือ web front end  และสุดท้ายคือ mobile app ซึ่งสองตัวหลังนี้จะเชื่อมต่อไปยัง api backend ตัวเดียวกัน

ในช่วงที่เริ่มโปรเจค ด้วยความที่ไม่เคยทำ backend มาก่อน จึงได้ตัดสินใจเลือกที่จะใช้ Go Language ตามคำแนะนำของเหล่าทวยเทพ และเหล่า Gopher เซียน backend ว่ามัน เจ๋งงงง สุดยอด .. ดีกว่า  NodeJS, เป็น type safty, ทำงานได้เร็วมาก, concurrency เจ๋งๆ,  blah blah ๆ ชาบู Google อะไรก็ว่ากันไป

ด้วยความที่ไม่เคยเขียน Go มาก่อน ก็ต้องมาเริ่มต้นเขียน  Go และเรียนรู้ คอนเซ็ปของ Go อย่างเช่น go pointer ที่ไม่เหมือน c pointer หรือการที่มันเป็น paradigm แบบ structure ไม่ใช่แบบ OOP ที่คุ้นเคย รวมไปถึงสไตล์การเขียนอะไรย่อๆ อย่างชื่อตัวแปร ตามสไตล์ Go ซึ่งมันขัดกับสาย Swift ที่ชอบเขียนชื่อยาวๆ (แอบ แซะไปเยอะ 555+) จะอะไรก็ตาม นั่นไม่ใช่ปัญหาใหญ่สำหรับผม เพราะผมเรียนรู้มันได้

แต่ปัญหาหลักๆที่ผมเจอคือ ปริมาณงานที่ต้องทำมันเยอะมาก .. มันทำไม่ทัน เมื่อมันทำไม่ทันดังนั้น ผมจึงตัดสินใจที่จะหา Developer และ Freelance เพิ่ม แต่ปัญหาที่ใหญ่มากคือ .. คนที่เขียน Go มีน้อยมากกกกก ย้ำว่า น้อยยยยมาก  ในระยะเวลกลายเป็นว่า โปรเจคมันดีเลย์ไปหลายเดือนมาก เพราะคนไม่พอ จะไปจ้างคนเขียน ก็หาคนยากมากกก นี่ผมใช้เวลาไป 3 เดือน ยังไม่ได้ซักคน

ทำไงดีละ ?

อย่างที่บอกไปคือ โปรเจคมันทั้งหมด 3 ส่วนคือ  web front end กับ backend  แล้วก็มีส่วน mobile app ดังนั้น ผมจึงเอา api บางส่วนที่ mobile ต้องใช้งาน แยกออกมาเขียนเป็นอันใหม่ กลายเป็น backend 2 ตัว (เหมือนงานจะเพิ่ม แต่เดี๋ยวผมมีเหตุผลที่แยกออกมา ซึ่งจะกล่าวต่อไป) ในส่วนของ web front end ก็ยังเชื่อมต่อกับ backend ที่เขียนด้วย  GO เหมือนเดิม จะมีก็แต่ mobile app ที่มันจะเชื่อมต่อกับ backend ตัวใหม่ที่เขียนด้วย swift

การเริ่มต้นใหม่นี้ ผมเลือกเอา Swift มาเขียนเป็น backend ก็นับว่าความเสี่ยงอยู่มาก เพราะด้วยตัวภาษา Swift เองที่มันเปลี่ยนอยู่ตลอด และยังเป็นเรื่องค่อนข้างใหม่สำหรับการนำเอา swift มาใช้เขียนเป็น backend ผิดกับภาษา GO, Node ที่ได้ออกแบบมาสำหรับ การเขียน backend โดยเฉพาะ

มีคนถามผมนะว่า ในเมื่อมันเสี่ยง ทำไมเลือกเอา Swift ละ ไม่ใช้ Node , PHP , Ruby, JAVA บลาๆๆๆๆ ?

ผมเลือกใช้ Swift ด้วยปัจจัยหลักๆคือ

  • Node, PHP, Ruby สำหรับผม ต้องเรียนรู้ใหม่ กว่าจะทำความเข้าใจ เขียนให้คล่อง โปรเจคก็คงเลื่อนไปอีก
  • แม้ว่าจะเขียน Java พอได้ และ Java ก็มีเฟรมเวิร์คทาง backend หลายตัวเช่น spring boot แต่ผมไม่ชอบ JAVA เป็นการส่วนตัว (ผมเขียน Android ด้วยนะ แต่ใช้ Kotlin) ดังนั้นการเลือกใช้ Java จึงไม่ใช่คำตอบสำหรับผม
  • จำนวนคนที่เขียน Swift เป็นนั้น มีเยอะกว่า Go ในกรณีที่เราต้องจ้าง Freelance , Outsource นั้น หาคนง่ายกว่ามาก
  • Backend ที่จะเขียนใหม่ เป็นของ mobile ถ้าหากต้องแก้ไข ก็ให้ Mobile Dev แก้ไขทันที เพราะใช้ภาษาเดียวกัน ( Full-Stack )

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

Vapor

ก่อนหน้านี้ผมเคยลอง Kitura มาสักพัก แต่หลายๆของ Kitura มันยังไม่ค่อยโอเค เท่าไหร่ อย่างเช่น การเชื่อมต่อ postgres และสุดท้ายก็นั่นแหละ มันก็มาลงเอยด้วยการใช้ vapor และหลังจากการเขียน Vapor มาสักพัก ผมจะเล่าถึงประสบการณ์ ที่ได้ใช้ Vapor เป็น API และสิ่งต่างๆที่ได้เจอออกเป็นหัวข้อละกันนะครับ และเนื่องจากผมใช้มันเป็น API Backend ไม่ได้ใช้เป็น Web Server ดังนั้นในส่วนที่เกี่ยวข้องกับ web อย่าง server rendering , web template นี่ผมขอไม่พูดถึงนะครับ

Tools

Vapor มีเครื่องมืออำนวยความสะดวกมาให้ คือ Vapor Command Line ซึ่งมันจะช่วยให้เราเริ่มต้นสร้างโปรเจคได้ง่าย เลือกได้ว่าจะเอา template แบบไหน เป็น web หรือ แค่ api และมันยังมีคำสั่งในการ update package , dependency ต่างๆ รวมอยู่ในตัวเอง รวมไปถึงการสร้าง xcode project คืออันที่จริงเราไม่ต้องใช้ xcode project เพราะ backend มันมักจะถูก compile และทำงานบน linux (คงไม่มีใครใช้ Mac OS เป็น Server กันเท่าไหร่จริงไหม ?) แต่เราต้องวาง source code folder อะไรต่างๆให้ให้ถูกต้อง แต่เหตุผลหลักที่เรายังต้องการ xcode project เนี่ย ก็เพราะว่า เราพัฒนาบน Mac เป็นหลัก การใช้ Xcode เป็นเครื่องมือในการเขียน code มันดีกว่าการไปเขียนด้วย text editor ตัวอื่นๆ และถ้าหากเราไม่ใช้ command line tool  คุณก็ต้องมาจัดการ กับ dependency และ source code ใน xcode project ด้วยตัวเอง ซึ่งมันเสียเวลา ดังนั้นการที่มีเครื่องมือมาให้ นับว่าเป็นข้อดีอย่างมาก

Code Style

ในการเขียน backend นั้นจะมี framework หลักๆ อยู่หลายเจ้า อย่างเช่น Kitura ของ IBM หรืออาจจะเป็น Perfect และ Zewo อะไรก็ว่ากันไป แต่ถ้าหากเทียบกันแล้ว Vapor นั้นมีการเขียน coding style ที่ดูเหมือนจะเป็นสไตล์ swift มากกว่าเจ้าอื่นๆ .. อย่างกรณีของ Kitura นั้น ได้ออกแบบมาให้เหมือนกับ express ของ Node JS ดังนั้นแล้ว วิธีการในการเขียนมันก็เลย เหมือนเขียน NodeJS  ผมว่า Vapor นี้มันเข้ากับสไตล์ของผมมากกว่า

Database Support

ในการเขียน backend แน่ๆคือมันต้องเชื่อมต่อกับ database สักตัว ข้อดีที่เห็นได้ชัดมากคือ มันมี framework ที่เรียกว่า fluent ซึ่งเราไม่ต้องไปจัดการเขียน code พวก sql เอง เราสามารถสร้าง model เพื่อให้มัน จัดเก็บลง database ได้เลย  และมันก็รองรับ postgres , mongo, sqlite โดยจะทำงานผ่านสิ่งทีเรียกว่า provider และข้อดีอีกอย่างของ fluent คือเขียน unit test ง่าย (ถ้าใครเคยเขียน  unit test ที่เชื่อมต่อกับ database จะเข้าใจว่ามันปวดหัวแค่ไหน)

JSON Suport

ข้อดีอีกอย่างของ fluent คือมันแปลง json เป็น model ได้ค่อนข้างง่าย รวมไปถึง การเปลี่ยน model กลับไปเป็น json ก็ง่าย มันสะดวกมากเวลาที่จะตอบ response กลับไปเป็น json

Authentication

การยืนยันตัวตน เป็นฟีเจอร์ที่แทบจะทุก service ต้องมี ซึ่งใน vapor มันจะทำงานผ่านทาง provider (เหมือนกับกรณี database) และมันก็รองรับการ authen หลายอย่างมาก ไม่ว่าจะเป็นจะเป็นแบบ username – password หรือว่า ใช้ token ก็ได้ และรองรับ JWT ด้วย ซึ่งตรงนี้ผมว่ามันค่อนข้างสะดวก ผมยังไม่เคยลองทำพวก third party authen นะ อย่างเช่น facebook , google ว่ามันทำงานได้ดีแค่ไหน

Route

การสร้าง Route ของ Vapor นั้นก็ค่อนข้างจะง่าย ไม่ว่าจะเป็นแบบ Rest หรือแบบ static path การเข้าถึง query หรือ parameter ของ request ที่เข้ามาก็มีฟังก์ชั่นมาครบ หรือถ้าหากต้องการจะกำหนด สิทธิการเข้าถึงแต่ละ path ก็ทำได้ค่อนข้างสะดวก

REST

หากต้องการจะให้ api เป็น แบบ rest ตัวของ vapor เองก็ทำได้ง่ายๆผ่านทาง controller builder ยิ่งถ้าใช้ร่วมกับ fluent แล้ว มันเป็นอะไรที่แจ่มมาก เพราะมันลดงานในการเขียน code ลงไปได้เยอะมาก แค่กำหนดว่า PUT , POST , UPDATE เรียกฟังก์ชั่นอะไรก็จบละ (คือมันลดการเขียน code DB sql แล้วยังลดการเขียน code ในส่วนของ route อีก)

Middleware

ใน vapor มี middleware ให้ใช้งานอยู่หลายตัว อย่าง redis ,facebook auth , realm และการเขียน middle ware ขึ้นมาใช้งานเอง ผมว่ามันง่ายนะ เพราะว่ามันมี protocol รองรับไว้อยู่แล้ว

Deployment

ในส่วนของการ deploy นั้น ตัว vapor เราจัดการ environment ได้ด้วย config ไฟล์ ซึ่งใน Vapor นี้มัน แยก มาให้เราเลยว่า เป็น development, staging หรือว่า production มันทำให้ เรากำหนดสิ่งต่างๆที่จำเป็นได้สะดวกมาก อย่างเช่นว่า ตอนพัฒนา ให้มันไปต่อกับ DB เครื่องตัวเอง แต่ตอน deploy จริงๆให้มันไปต่อกับ AWS แบบนี้ รวมไปถึงการจัดการ secret key ต่างๆ มันก็แยกให้เรา

หรือถ้าอยากจะ deploy เป็นแบบ container ผ่านทาง docker ก็ทำได้ คือตัว vapor มันมี docker file ที่ community ทำไว้ให้อยู่แล้ว ดังนั้นเราเลยไม่ต้องไปเริ่มเขียน docker file จากศูนย์

Debug

จากประสบการณ์ในการเขียน GO และ NodeJS ผมบอกได้คำเดียวสองอย่างนี้ ห่วยแตกในการ debug มาก คือในช่วงแรกๆ นี่ผมถามคนที่เขียน backend หลายคน (ทั้ง Go, NodeJS) นะว่า debug กันยังไง เค้าบอกว่า ใช้ print log ดูค่าเอา ผมนี่ถึงกับร้อง WTF !!!! คือส่วนตัวผมไม่ชอบเลยกับการที่ต้องมาดู log ว่าค่า มันเป็นอะไร แม้ว่า Go มันจะมี Debugger อย่าง Delve อยู่ แต่มันต้องมา config ให้มันทำงานร่วมกันผ่าน IDE ได้ ( ใช้ Gogland IDE อาจจะง่ายกว่า VS Code หน่อยหนึ่ง) และประสิทธิภาพของ debugger นี่ก็อ่อนด้อยมาก ในขณะที่ Swift นั้นการ debug มันง่ายมาก ถ้าหากเราทำผ่าน Xcode

Unit test

เท่าที่ลองใช้งาน ตัว vapor มัน build in พวก function ในการทดสอบ route (request / response) อยู่แล้ว ไม่ต้องไปเขียน XCTest กับแบบเพียวๆเท่าไหร่ และก็อย่างที่ได้บอกไปว่า ถ้าหากใช้ fluent การเขียน unit test จะทำได้ง่ายมาก เพราะว่า เราไม่ต้องให้มันไปเชื่อมต่อกับ database server จริงๆ แค่กำหนดให้มันสร้าง db ใน memory ในตอนที่เรา run testing เท่านั้นเอง ซึ่งในบางครั้ง มันลดการเขียน mock ไปด้วยนะ

Document / Community / Sample / Tutorial

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

Feature อื่นๆ

อันที่จริงมันมีอีกหลาย feature ที่ผมยังไม่เคยลองใช้งาน อย่างเช่น session , core หรือการใช้ให้มันเป็น web server ดังนั้นในส่วนนี้ก็เลยบอกไม่ได้ว่า เป็นยังไง

vapor.cloud

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

ข้อเสียละ ?

ข้อเสีย อย่างแรกของมันคือ เค้าบอกว่า มันทำงานได้ช้ากว่าตัวอื่นๆ ซึ่งก็มีคนลอง bench mark   ซึ่งก็มีผลว่า Vapor 2 ทำงานได้ค่อนข้างช้ากว่าคนอื่น เร็วสุดก็ Go และมั้ง แต่ว่าในส่วนนี้ผมไม่ค่อยแคร์เรื่อง performance สักเท่าไหร่ เพราะว่า จำนวนผู้ใช้งานอยู่แค่หลักพัน ไม่ได้ทำ server ที่จะรองรับผู้ใช้งาน หลักล้านคน ข้อเสียอย่างที่สองคือ ยังไม่มีค่อยมีคนเอา swift เป็น backend เจอปัญหาอาจจะต้องหาทางแก้เอาเอง

สรุป

ถ้าคุณสามารถใช้ firebase หรือพวก service สำเร็จรูปอื่นๆได้ก็ไม่ต้องเขียนเองหรอกครับ แต่ถ้าต้องเขียน backend เอง ผมว่า Vapor เป็นทางเลือกที่ดี ตัวหนึ่งเลยนะครับ เหมาะมากสำหรับทีม ที่มี iOS Dev เยอะๆ

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

Review Steelcase think – รีวิวเก้าอี้ steelcase think

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

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

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

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

ผมเคยนั่งเก้าอี้ที่เคยนั่งตอนที่ทำงานที่ออฟฟิศ เป็นเก้าอี้ยี่ห้อ Logica ผมอยากได้เก้าอี้แบบในออฟฟิศบ้าง ก็เลยคิดจะซื้อใหม่ แต่ปัญหาคือว่า ไม่รู้ว่า ยี่ห้อนี้มันซื้อที่ไหน ก็ไปดูตามพวก SB Furniture บ้าง แต่ลองนั่งเก้าอี้ในโซนออฟฟิศ ก็คิดว่าของ SB มันไม่ใช่แบบที่ต้องการเลย

แล้วบังเอิญว่าได้ไป CDC จะไปดูเฟอร์นิเจอร์ ก็เลยแวะไป ดูเก้าอี้ สักหน่อย ในนั้นมันจะมี ร้านขายเฟอร์นิเจอร์สำนักงานสองร้านคือ Modern Form กับ Perfect อะไรสักอย่างนี่แหละ .. คือผมก็แวะ ไปที่ perfect ก่อนนะ ชอบเก้าอี้ตัวหนึ่งในนั้นมาก ราคาประมาณ 7,900 แต่ยังไม่ตัดสินใจซื้อ คือมันก็ราคาแพงอยู่ ก็เลยกะว่าเดินดูอีกสักร้านก่อน เผื่อมีตัวเลือกเลือกที่ถูกกว่า

จนกระทั่งมาเจอกับเก้าอี้ Steelcase รุ่น Think ในโชว์รูมของ Modern Form เห็นมันลดราคาเหลืออยู่ราวๆ 10,000 บาท คนขายบอกว่าเป็นเก้าอี้ ออกแบบตามหลัก Ergonomic เหมาะกับการทำงาน ก็เลยไปลองนั่งดู

สรุปก็เลย ซื้อ Steelcase Think มาแทนเก้าอี้ที่เล็งไว้ก่อนหน้านี้ จากตั้งงบเก้าอี้ไว้ แค่ 5000 คราวนี้ บานปลายกลายเป็นหมื่นเลย เอาละ ไหนๆ ก็ซื้อมาแล้ว มาดูกันว่า เก้าอี้ราคาขนาดนี้มันได้อะไรมาบ้าง

Review

ข้อดี

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

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

ในส่วนของที่วางแขนก็ปรับสูงต่ำได้เช่นกัน

นอกเหนือไปจากการปรับระดับความสูง เรายังสามารถ ปรับให้มันเอนเข้า-ออก ได้ตามชอบ แต่ข้อเสียคือ มันไม่สามารถล๊อกตำแหน่งได้

ในส่วนของ เบาะรองนั่ง นั้นนุ่มมากๆ และยังสามารถปรับ ให้มันชิด หรือห่างพนักพึงหลังได้

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

ตัวฐานล้อเป็นพลาสติก แอบเสียดายว่ามันน่าจะเป็นโลหะมากกว่า ในส่วนของล้อ ก็หมุนลื่นดี

ข้อเสีย

จากรูปจะเห็นว่า ที่วางแขนกว้าง ถ้าปรับให้มันกว้างสุด มันจะกว่าตัวโต๊ะ ทำให้ไม่สามารถเลื่อนเก้าอี้เข้าไปได้ (โต๊ะซื้อที่ IKEA ตัวนี้ก็ใช้งานดีนะ) ถ้าจะให้มันพอดีกับโต๊ะ ต้องปรับที่วางแขนให้เข้ามาอีก

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

สรุป

เป็นเก้าอี้ที่ดีมากๆ ตัวหนึ่ง แต่ราคาแพงเอาเรื่องอยู่ ตัวที่ผมซื้อมานี่เป็น Steelcase Think V1 ผมอยากได้สีดำมากกว่า สีเทา แต่คนขายบอกว่า บริษัทไม่นำเข้ามาแล้ว แล้วก็เหลือไม่กี่ตัว และคนขายเชียร์ให้ซื้อ V2 แต่ราคามันอยู่ที่ 17,000 แต่เมื่อก้มดูเงินในกระเป๋าแล้ว ไม่ไหวแพงไป แล้วก็อีกอย่างที่ตัดสินใจซื้อตัวนี้เพราะมันรับประกัน 12 ปี แต่ตัวใหม่ รับประกันแค่ 3 ปี

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

หลักสูตรอบรมการเรียนโปรแกรมด้วยภาษา Swift จากเริ่มต้นสู่มือโปร

ในที่สุดก็เสร็จแล้วนะครับ กับคอร์สหลักสูตรการเขียนโปรแกรมด้วยภาษา Swift  มีความยาวกว่า 10 ชม. ผมกล้าพูดได้เต็มปากว่า ไม่น่าจะมีหลักสูตรในไทยที่ไหน สอนละเอียดขนาดนี้ เพราะมันอัดแน่นด้วยเนื้อหาแทบจะครบทุกๆอย่างของภาษา Swift ตั้งแต่ขั้นเริ่มต้นอย่างการประกาศตัวแปร ไปจนถึงเรื่อง Closure , Memory Management หรือ Generic

หลักสูตรที่ผมทำขึ้นมา ไม่ใช่ให้เขียนโค้ดตามอย่างเดียว แต่เน้นไปยัง “Fundamental” อธิบายถึงที่มาที่ไป รวมไปถึง concept ต่าง ซึ่งจะทำให้เข้าใจในการทำงานของส่วนต่างๆ ได้อย่างแท้จริง

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

ราคาเต็มอยู่ที่ 6400 บาท แต่ในช่วงเปิดคอร์สนี้ผมมีคูปองส่วนลดให้

สำหรับนักเรียน นักศึกษา ผมให้คูปองพิเศษ ลด 50% ให้ครับ ไม่ต้องไปแย่งกับคนอื่น 🙂 เพียงถ่ายรูป บัตรนักศึกษา และส่ง message มาทาง fb – fan page หรือจะส่ง email มาที่ macfeteria แอท gmail เพื่อยืนยันว่าเป็นนักศึกษาจริงๆ

และสำหรับผู้ที่ไม่มีบัตรเครดิต ส่ง email มาหาผมได้ครับ เดี๋ยวบอก รายละเอียดวิธีการสั่งซื้อให้

เนื้อหามีประมาณ 20 กว่าบทได้แก่

  • Variable
  • Operator
  • Making Decision
  • String
  • Collection ( Array , Dictionary )
  • Loop
  • Switch
  • Function
  • OOP
  • Initializer
  • Closure
  • Memory Management
  • Structure
  • Enumeration
  • Protocol
  • Extension
  • Error Handling
  • Generic

ในแต่ละบทยังแบ่งย่อยออกเป็นอีกหลายๆเรื่องนะครับ ลองเข้าไปดู Course ได้ครับที่

https://www.udemy.com/swift-th

ปล 1. ผม update course ให้ตลอดนะครับ หากมีเนื้อหาใหม่ๆเพิ่มเติม
ปล 2. ผมทำคูปองมาให้แล้ว ก่อนซื้อโปรดใช้คูปอง นะครับ

Swift String กับภาษาไทย

วันก่อนๆ มีคนโพสในกลุ่มของ iOS Dev Thai เกี่ยวกับปัญหาภาษาไทยของ swift string ว่ามันไม่สามารถค้นหาคำได้อย่างที่ต้องการ ยกตัวอย่างเช่น

จากตัวอย่างง่ายๆนี้จะเห็นว่า เราสามารถหาคำว่า “ชี” ได้  แต่ในขณะที่ “ช” ตัวเดียวนั้นกลับหาไม่เจอ

ว่าแต่ทำไม มันหาไม่เจอละ ?

ปัญหาของมันก็คือว่า Swift นั้นใช้ Grahpheme ซึ่งมันจะ เอา สระ วรรณยุกต์ และ ตัวอักษร มารวมเป็นตัวเดียวกัน คือพูดง่ายๆว่ามันนับตามช่องไฟของตัวอักษร

ถ้าหากเรานับจำนวนตัวอักษร มันก็จะนับได้แบบนี้

ก็จะเห็นว่า ไม่ว่าจะเป็น ก , กู , กู้ มันก็นับได้ 1 เหมือนกัน

ในภาษาจำพวกภาษาอังกฤษ ตัวอักษณ e กับ é เขามองเป็นตัวอักษรคนละตัวอักษร

จากโค้ดข้างบน มันก็ทำงานถูกละ เพราะ e กับ é มันคนละตัวอักษร

แต่ในกรณีของภาษาไทย  เราไม่ได้นับ ช กับ ชี เป็นตัวอักษรคนละตัวกัน แต่เราบอกว่า มันคือ

  • ช ที่มี สระ อี

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

เราจะแก้ปัญหานี้ยังไงดี

วิธีการแรก คือ ใช้เมธอด localizedStandardCompare เมธอดนี้ มีใช้ใน iOS9

เมธอดนี้ อาจจะแก้ปัญหาเรื่องที่ว่า มันหา “ช” ไม่เจอ

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

อย่างเช่นมี “ก” ตัวเดียว แต่ถ้าหาด้วย “กู้” มันก็จะบอกว่า เจอเหมือนกัน เช่นตัวอย่างนี้

 

วิธีการที่สองคือ เปรียบเทียบ ตาม character ไปทีละตัว โดยใช้เมธอด range(of:) แล้วก็กำหนด option ให้เป็น literal ซึ่งเราอาจจะเขียนออกมาเป็น extension ง่ายๆ แบบนี้

จะเห็นว่าผลลัพธ์นั้นให้ความถูกต้องมากกว่าวิธีการแรก
วิธีการแรก อาจจะเหมาะกับการค้นหาแบบ คร่าวๆ อย่างเช่นการ search แต่ถ้าหากต้องการผลลัพธ์ที่ถูกต้องวิธีที่สองน่าจะเหมาะสมกว่า

หวังว่าจะช่วยให้หลายคนหายสงสัยเกี่ยวกับ String ใน Swift นะครับ

เขียนโปรแกรมกันเถิดจะเกิดผล Programming and technology