Category Archives: Talk

Review Harman/Kardon Aura

เอาละวันนี้ผมจะมารีวิว Harman/Kardon Aura นะครับ เพิ่งได้มาใหม่ๆ เลย คือจริงๆแล้วอาทิตย์ก่อน ผมไป Homepro (สาขาที่ผมไปคือ พระราม 3)  จะไปซื้อน้ำยาทำความสะอาดเครื่องซักผ้า แต่ดันผ่านบูทเครื่องใช้ไฟฟ้า คือบางสาขา Homepro มันมีส่วนขายเครื่องใช้ไฟฟ้าอยู่ เดินไปเห็นป้ายลดราคาลำโพงรุ่นนี้อยู่ 30% ไม่รอช้ารีบเข้าไปดูราคาว่ามันจริงป่าวว่ะ สรุปว่า เออมันลดจริงๆ จาก 15K เหลือ 11K โดยประมาณ สรุปว่าลดไป 4 พันบาท

แต่ก่อนจะซื้อ ผมก็ดูใน net ก่อนนะว่า ราคาจริงๆเค้าขายกันเท่าไหร่ ก็ลอง search ดูเห็นมีในเวป อย่าง jib ก็ขายที่ 15,900 บาท แล้วก็มีใน Lazada ขายแค่ 11,000 เหมือนกัน แต่พอแล้วพอเข้าไปดู มันเป็นคนละรุ่นกัน คือตัว ที่ขายอยู่มันจะเป็น  Aura Studio ซึ่งมันจะตัด พวก airplay ออกไป

จากการหาข้อมูลราคาคร่าวๆ ก็เลยตัดสินใจ ซื้อมา คือจริงๆมันก็มีลำโพงรุ่นอื่นๆเหมือนกันนะ ที่ลดราคา บางตัวซื้อหนึ่งแถมหนึ่งอย่าง JBL (คือลำโพง 4 พันแถมอีกตัวในราคา 2 พันกว่าบาท คุ้มโคตร) แต่ว่าผมสนใจรุ่นนี้เป็นพิเศษ คือส่วนตัวผมไปลองลำโพงตัว 4-5 พัน แล้วเสียงมันงั้นๆ เหมาะกับพกเอาไปเที่ยวมากกว่า เอามาไว้ฟังจริงจัง

มาดูกันเลย กล่องก็หน้าตาแบบนี้ ด้านบนขวา บอกไว้ว่า มันได้ Reddot Design ด้วยนะ (คือมันก็สวยจริงแหละ ถึงได้รางวัล)

aura1

ด้านหลังของกล่องก็ประมาณนี้

aura2

ส่วนด้านบนของกล่องจะเขียนไว้ชัดเจนเลยว่า รุ่นนี้ใช้ได้ทั้ง Airplay / Wifi / Bluetootch / AUX  แต่อย่างที่ผมได้บอกไป ถ้าเป็นรุ่น Aura Studio มันจะไม่มี Airplay แล้ว

aura3

จากนั้นก็เปิดกล่องออกมา

aura4

aura5

ภายในกล่องจะมีสายไฟ Adapter มาให้ พวกสาย Aux 3.5 ไม่แถมนะครับ ถ้าใครอยากจะต่อแบบมีสาย ก็ต้องซื้อสายมาเอง

aura6

และนี่ก็คือโฉมหน้าของ Aura ใสๆ วัยรุ่นชอบ

IMG_8275

ในส่วนด้านหลังจะเห็นว่ามี ช่องเสียบต่างๆ รวมไปถึงช่องต่อไฟ

aura7

เอาไปวางคู่กับ Macbook และ จอ Dell ก็ลงตัวทีเดียว

aura10

ดูใกล้ๆอีกรอบ

aura9

ใส กิ๊ก บาดใจ

สรุปทดสอบโดยรวม

  • จากการใช้งานโดยทั่วๆไป เสียงดีมากๆ เปิดดังสุด ก็ให้เสียงไม่แตก เบสยังนิ่ง เสียงแน่นมาก จริงๆผมแนะนำให้ไปร้าน ไปลองฟังก่อนนนะ ลำโพง เรื่องเสียงนี่แล้วแต่สไตล์ความชอบส่วนตัวเลย แต่โดยรวมตัวนี้ ใครฟัง ก็บอกว่าเสียงดี
  • การลด เพิ่มเสียง เป็นระบบสัมผัส ไม่ต้องกดปุ่ม แค่เอานิ้ว ลูบๆไปตามขอบๆ ก็ลดเสียง เบาเสียงได้แล้ว
  • การเชื่อมต่อ Bluetooth ทำได้ดี
  • การเชื่อมต่อ Airplay ก็ดี แต่บางทีมันกระตุก (ในกรณีที่เครื่องทำงานอย่างอื่น หรือเปิด net โหลดหนักๆ) เข้าใจว่าเป็นเพราะ router wifi ที่ผมใช้มันอาจจะไม่ดีเท่าไหร่ ( ของแถมมากับ AIS Fiber)
  • เสียง Airplay ดีกว่า Bluetooth นิดหนึ่ง เชื่อว่าคนทั่วไป แยกไม่ออก
  • ถ้าต่อ Bluetooth เสียงทุกอย่างมันจะออกที่ลำโพงหมด อย่างเช่นถ้าเปิดฟังเพลงจาก youtube ก็จะได้ยินผ่านลำโพง
  • ถ้าใช้ Airplay จะใช้ได้กับพวก iTune หรือโปรแกรมที่รองรับ Airplay ในกรณีเปิดฟังเพลงผ่าน youtube เสียงจะไปออกที่ mac แทน
  • มี iOS Application ให้ใช้ แต่ผมยังไม่ได้ลอง
  • ถ้าเทียบกับ Bose SoundLink III ผมว่าตัว Bose นั้นเสียงดีกว่าตัวนี้ นิดหนึ่ง และ bose มีขนาดเล็กกว่า แต่ Bose นั้นต่อได้เพียงแค่บลูทูช และไม่มีระบบสัมผัส  และถ้าตั้งเอาไว้ที่บ้าน ผมว่าตัวนี้มันดูสวยงามกว่าเยอะ

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

และสำหรับวันนี้ก็เท่านี้ครับ

 

Update เพิ่มเติม 28 / Aug / 2017

พอดีว่า Spotify เพิ่งจะเปิดตัวในไทย ผมเลยลองสมัครใช้งานดู แต่ว่าด้วยข้อจำกัดของ account ฟรี ที่ไม่สามารถเชื่อมต่อลำโพงตัวนี้ .. ผมเลยตัดสินใจ จ่ายเงินแบบ premium ไป เพื่อที่จะฟังเพลงผ่านลำโพงนี้ .. แต่มันทำให้ผมค้นพบความสามารถอีกอย่างของลำโพง ที่ผมเพิ่งจะรู้คือ คือ เราสามารถฟังเพลงจาก spotify แม้ว่าเราจะปิดคอมพิวเตอร์ เพราะมันจะไป stream จาก internet .. อย่าง เมพพพพพ … แต่ว่าเราต้องเชื่อมลำโพงในแบบ air play นะครับ

Review Dell U2414H

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

จอภาพมันก็มีหลายแบบมากมายในตลาด ทั้งเล็ก ใหญ่ ราคาแพง ถูก หลายยี่ห้อมากมาย ดังนั้น ก่อนจะไปเลือกซื้อ หรือหาอะไร ผมก็ตั้งหลักไว้ว่า

  • ต้องมี port HDMI หรือ Display , Mini Display เพื่อใช้ต่อกับ Macbook Retina
  • มีประกันให้อุ่นใจ
  • งบไม่เกิน 10,000 บาท
  • ขนาดไม่เล็ก ไม่ใหญ่ไป (สำหรับผม 27″ ใหญ่ไป  และจอ 20″ ก็เล็กไปสำหรับเขียนโค้ด )

อันที่จริงมันก็มีจอหลายรุ่นที่ตรงตามที่ผมอยากได้ แต่ก็มาลงเอยกับ Dell U2414H เพราะว่า

  • เคยใช้จอ Dell มาก่อน จากประสบการณ์คิดว่ามันโอเค
  • รุ่นนี้ประกัน 5 ปี ( ถ้าเลือกเอา 3 ปีก็ถูกกว่านิดหน่อย )
  • ผมซื้อในราคา 8 พันบาท แต่ไปรับของเอง (ถ้าสั่งซื้อในเวปออนไลน์ ก็ประมาณ 9 พัน ส่งฟรี)
  • Onsite service
  • Spec ต่างๆของจอ อยู่ในขั้นดี
  • มันมีช่องต่อ usb จากจอ

Open Box

_DSC0106

ตัวที่ผมได้มานี้คือ Dell UltraShape U2414H (Rev A03) คือจอภาพรุ่นนี้จะมี Rev 1 , 2 , 3 ถ้าจะซื้อก็ต้องดูด้วยนะครับว่าเป็น Rev ไหน เพราะ Rev 3 คือรุ่นใหม่สุด (ณ เวลาที่ผมเขียน)

_DSC0107

เมื่อดูข้างๆกล่อง ตรงที่ผมขีดสีแดงเอาไว้ มันบอกว่า รุ่นนี้ ประกัน 5 ปี (U2414H ปกติจะประกัน 3 ปี)  เอาละอย่ามัวเสียเวลากันเลย เริ่มแกะกล่องกันเลยดีกว่า

_DSC0109

หลังจากแกะกล่องออกมา ก็จะพบสายไฟที่ให้มา ประกอบไปด้วย

_DSC0113

  • สาย power
  • สาย usb
  • สาย display port

_DSC0133

_DSC0131

คือมันไม่แถมสาย HDMI มาให้แต่ให้ สาย Mini Display ไว้ต่อกับ Macbook ก็ถือว่าโอเค

ฐานตั้งที่ให้มาก็ดูแข็งแรงดี

_DSC0114

_DSC0115

หลังจากแกะห่อออกมาละ ด้านหลังของจอภาพก็ประมาณนี้

_DSC0116

รายละเอียดต่างๆของการผลิต ก็บอกไว้หลังจอ และที่ผมได้มา มันก็เขียนไว้ว่าผลิต มกราคม 2016  ในส่วนของ serial number ก็ตรงกับข้างกล่อง

_DSC0119

ด้านหน้าจอ ก็อย่างที่เห็น ขอบบาง

_DSC0124

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

_DSC0123

เมื่อประกอบกับฐานเสร็จ ก็จะเป็นแบบนี้

_DSC0127

จอมันจะปรับเลื่อนขึ้นลงได้ และบิดองศาก้มเงิย ได้ พอประมาณ

_DSC0129

ถ้าหากไม่ชอบการวางจอภาพแนวนอน จะเปลี่ยนเป็นแนวตั้งก็ได้

_DSC0130

ในส่วนของภายนอก ก็พอมองเห็นภาพละ ต่อไปก็ลองเอาไปต่อกับ macbook  กันเลย

_DSC0160

จอ Dell U2414H นี้ไม่ใช่จอแบบความละเอียดสูงเหมือน retina display ดังนั้นแล้ว ความคม  (dpi ) จะเอาไปสู้ จอ macbook คงไม่ได้แน่ๆ

_DSC0159

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

Untitled-2

และในส่วนของการปรับแต่งก็เหมือนๆ จอทั่วๆไป ปรับโทนสี ความสว่าง เลือก input source ว่าจะรับสัญญาณจาก hdmi หรือ diplay port ได้

_DSC0161

รูปเปรียบเทียบกับ Macbook 13″

_DSC0165

สรุปแล้ว ผมว่ามันเป็นจอที่เหมาะกับการเขียนโปรแกรมมาก เพราะ

  • มีพื้นที่ให้เขียนโค้ดเยอะกว่า macbook retina
  • สีสันของภาพ คุณภาพของจออยู่ในขั้นดีมาก
  • ใช้ usb 1 ช่อง ต่อจาก macbook  ไปเข้าจอ แต่เราจะได้ช่อง usb หลังจอภาพ เพิ่มมา 3 ช่อง
  • ราคาคุ้มค่ากับที่ต้องจ่ายไป

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

สำหรับผมก็ขอจบการ review  เพียงเท่านี้

Semantic Versioning

ทุกคนน่าจะเข้าใจคำว่า version เป็นอย่างดี แต่เคยสังเกตไหมว่า เลขแต่ละตัวของมันคืออะไร เช่น

version

อย่าง atom ก็บอกไว้ว่า version 1.3.2 คนทั่วๆไปก็คงไม่ได้สนใจว่า เลขเหล่านี้คืออะไร เข้าใจแค่เพียงว่า ตัวเลขเยอะขึ้นก็คือ version ใหม่กว่าเดิม แต่ถ้าคุณเป็น Developer เรื่องของ version จะกลายเป็นสิ่งสำคัญมาก เพราะเมื่อเขียนโปรแกรมไปสักพัก เราอาจจะต้องใช้ Library จากข้างนอก ที่เราไม่ได้เป็นเขียนขึ้นมาเอง เมื่อเลือก Library หรือ API แล้ว แน่นอนว่าไลบารีต่างๆที่เราเลือกใช้ ก็มักมีการ update เป็นเวอร์ชันใหม่ ซึ่งโดยปกติเราก็จะเปลี่ยนไปใช้เวอร์ชั่นใหม่ถูกไหม เพราะ library อาจจะมีการแก้ bug เพิ่ม feature อะไรก็ว่ากันไป  …. แต่หลายๆครั้งเราก็ต้องพบว่า อ้าวนี่เราต้องแก้ไขโค้ดใหม่ เพราะ API , Library เหล่านั้น ได้เปลี่ยนแปลง  บางฟังชั่นได้ยกเลิกไป หรือฟังชั่นที่เคยใช้งานใช้งานประจำ ต้องการพารามิเตอร์เพิ่มเติม อะไรแบบนี้  คำถามคือ เราจะรู้ได้ยังไงว่า ไลบารี่ที่เค้า update ใหม่เนี่ย โค้ดของเราจะยังใช้งานได้ โดยไม่ต้องแก้ไขอะไร ?

โอเค หลายคนอาจจะบอกว่า โปรเจคเล็กๆ แก้โค้ดของเราให้เป็น API ตัวใหม่ก็จบละ แต่ถ้าเป็นโปรเจคใหญ่ๆ มีโค้ดซับซ้อน การไปไล่แก้คำสั่งต่างๆย่อมปวดหัวแน่นอน และในมุมกลับกัน ถ้าหากเราเป็นคนที่เขียน library , api  เหล่านั้นเสียเองละ

โอเค .. ในวันแรกที่ปล่อย library ให้คนอื่นใช้งาน ก็ตั้งเป็น 1.0 ใช่ไหม ? ต่อมาพบว่ามันมีบั๊ก แก้ไขโค้ดเสร็จ ต้องการจะปล่อย lib ตัวใหม่ ก็ต้องปรับ เลข version กันสักหน่อย แต่ก็ไม่รู้จะตั้งเป็นเลขอะไรระหว่าง 1.1 หรือเปลี่ยนเป็น 2.0 ไปเลย เราจะมีหลักการยังไงในการตั้งเลข version ?

หรือเคยสังเกตกันไหมว่า บางทีเราใช้ library ที่โหลดมาจากเน็ท เค้าจะมีเลขบอกไว้ เช่น LibA 4.0 ต่อมาเมื่อมีการปรับปรุงแก้ไข bug ก็เปลี่ยนเลขเป็น 4.2 แล้วเคยคิดไหมครับว่า ทำไมมันไม่เป็น 5.0 หรือ 4.1 ละ ?

เมื่อหลายๆปีก่อน ผมเองก็เป็นคนหนึ่งที่เขียนเลข version แบบมั่วๆ โดยไม่มีหลักการอะไรเหมือนกัน อยากได้อะไรก็ตั้งเอาเอง เช่น 1.2.0 beta อะไรแบบนี้ เห็นมันเท่ดี แม้ว่าการเขียนเลข version นั้นไม่ได้มีแนวทางตายตัว ว่าต้องเขียนแบบนี้ถึงจะถูกต้อง อย่างไรก็ตามมันมีหลักการที่เป็นที่นิยมใช้อยู่ ซึ่งหนึ่งในนั้นคือ Semantic Version

เลข Semantic Version จะมีความสำคัญอย่างมาก สำหรับ Developer เพราะมันจะช่วยให้เราเลือก Version ของ Library ได้ถูกต้อง และถ้าหากเราเขียน Library ให้คนอื่นเอาไปใช้ยิ่งต้องเขียนเลข version ให้ดี ซึ่งอย่างกรณี JKNotificationPanel ที่เป็น cocoapod library ของผมเอง นั้นก็ตั้งเลข version ตามแบบ semantic นี้เหมือนกัน

วันนี้ก็เลยจะขอพูดถึง Semantic Version และหลักการของมัน อย่างคร่าวๆเพื่อให้เราสามารถเขียนเลข version ให้มีความหมาย มากกว่า แค่บอกว่า library , api ที่เราใช้อยู่นั้น ใหม่ หรือ เก่า

Semantic Version

การเขียน semantic version นั้นมักจะใช้ในการเขียน Library และ API ต่างๆ ซึ่งเลข version ที่เป็น semantic version นั้นจะประกอบไปด้วยเลข 3 ส่วนคือ  x.y.z ( ไม่มี z ก็ได้ )

โดยที่เลขแต่ละตัวนั้นหมายถึง

  • X คือ Major  Version
  • Y คือ Minor  Version
  • และสุดท้าย Z คือ Patch Version

แต่ก่อนที่จะไปทำความเข้าใจการเขียนเลข เหล่านี้จะขออธิบายเพิ่มเติมเกี่ยวกับศัพท์ที่จะยินอยู่บ่อยๆสักหน่อย นั่นคือ backward compatibility

คำว่า Backward compatibility คือ การทำงานเข้ากันได้กับ API เดิม เช่น สมมติว่า โปรเจคเราใช้ LibA 1.0 ซึ่งมีฟังก์ชั่น Sum( a, b ) ที่รับค่า integer สองตัวคือ a และ b และในเวลาต่อมา LibA ได้ออกเวอร์ชั่นใหม่เป็น 1.2  และปรับปรุงให้ฟังก์ชั่น Sum นั้นสามารถรับค่า double ได้

ถ้าโค้ดของเราที่เรียกฟังก์ชัน Sum ยังทำงานได้ โดยที่ไม่ต้องเปลี่ยนแปลงอะไร นั่นคือไม่ต้องเปลี่ยนค่า a,b เป็น double สามารถใช้ integer ต่อไปได้ นั่นหมายถึงว่า libA ตัวใหม่นี้รองรับ backward compatibility

เอาละ เมื่อเข้าใจคำศัพท์แล้ว ต่อไปก็มาดูหลักการกันเลย

อันที่จริงการตั้งตัวเลข semantic นี้มีหลักการ ที่เขียนไว้ใน http://semver.org/ อยู่แล้ว ไปอ่านกันได้ แต่โดยสรุปอย่างย่อแล้ว มันมีหลักการง่ายๆคือ

  • เลข x.y.z นี้จะต้องไม่เป็นค่าติดลบ คือ จะไม่เขียน -1.0.0 อะไรแบบนี้
  • ค่าจะต้องไม่เป็น 0 คือ เขียนเลข 0.0.0 ไม่ได้
  • ค่าจะต้องเพิ่มขึ้นเสมอ เช่นตอนนี้ใช้ 1.4 เมื่อเปลี่ยน version ก็ต้องมีค่ามากขึ้น จะเขียน 1.3 ไม่ได้
  • ถ้าเลข Major Version มีค่าเป็น 0 นั่นหมายถึงว่า เป็น version ที่กำลังเริ่มต้นพัฒนา API ต่างๆอาจจะเปลี่ยนแปลงได้เสมอ
  • การเปลี่ยนเลข Patch Version จะใช้กับการแก้ไข bug ที่ทำให้การทำงานของ API, Function ของ library นั้นไม่ถูกต้อง เช่นฟังชั่น Sum ส่งค่าลบเลข มาแทน ผลการบวกเลข ในกรณีนี้จะต้องทำการเปลี่ยนเลข Patch  เช่นจาก 1.0.0 เป็น 1.0.1 เป็นต้น
  • Minor Version จะเปลี่ยนก็ต่อเมื่อ มีการเพิ่ม Feature , API ใหม่ๆ แต่ยังคงรองรับ api เก่า (backward compatibility) และถ้าหากเปลี่ยนเลข Minor Version แล้ว เลข Patch จะต้องเปลี่ยนเป็น 0
    เช่น 1.1.3 ก็เปลี่ยนเป็น 1.2.0
  • Major Version จะเปลี่ยน เมื่อ มีการเพิ่ม Feature หรือ  API แต่ไม่รองรับ backward compatibility และเมื่อเปลี่ยนเลข Major ใหม่ ตัวเลข Minor , Patch จะต้องเปลี่ยนเป็น 0
    เช่น 1.1.3 ถ้าหากเปลี่ยนเป็น 2.0.0 หมายถึงว่า lib นี้ได้เพิ่ม feature และไม่รองรับ backward นั่นเอง
  • ในกรณีที่เป็น pre-release ( ยังไม่สมบูรณ์ แต่ออกมาให้ลองใช้ก่อน ) อาจจะเขียน ตัวหนังสือ หรือตัวเลขต่อท้ายได้ เช่น 1.0.0-alpha , 1.0.0-beta.2 และแน่นอนว่าเวอร์ชั่นที่ไม่มี prelease ต่อท้ายคือเวอร์ชั่นที่ใหม่กว่า เช่น (เก่าสุด) 1.0.0-alpha  < 1.0.0-beta < 1.0.0 < 1.0.1 (ใหม่ล่าสุด)

ทีนี้พอจะเข้าใจแล้วใช่ไหมครับว่า เลข version นั้นมีความสำคัญยังไง และเราก็ควรจะใช้ semantic version นี้ให้เป็นประโยชน์

เอาละครับก่อนจากกัน ลองตอบตัวเองกันสักหน่อยว่า

Swift 2.0 กับ Swift 2.2 นั้นหมายถึงอะไร

เชื่อว่าหลังจากอ่านบทความนี้จบ คุณก็ตอบได้ใช่ไหมละครับว่า 2.2 การเพิ่ม feature ใหม่ๆ และรองรับ backward compatibility คือพูดง่ายๆว่า ถ้าหากเราเขียนโค้ดด้วย Swift 2.0 มันจะยังทำงานกับ Swift 2.2 ได้ โดยที่ไม่ต้องเปลี่ยนแปลงอะไร แต่จะถูกแจ้งว่า โค้ดบางส่วน กำลังจจะ deprecate ( ยกเลิก ) ในอนาคต นั่นเอง

Hand wire keyboard

ย้อนกลับไปสัก 5 ปีที่แล้ว เมื่อผมได้เริ่มใช้ Mechanical Keyboard อย่าง Filco ตั้งแต่นั้นมาผมก็เริ่มหลงไหลไปกับ keyboard มากขึ้น เมื่อเริ่มเข้าสู่ความเป็น “คนบ้า keyboard” ก็เกิด idea ว่าอยากจะทำ keyboard เองสักอัน ก็เริ่มหาข้อมูล อ่านเวปนั่นนี่เรื่อย ก็พบว่ากว่าจะได้ keyboard สักอันมาเนี่ยต้องออกแบบแผ่น PCB เสียก่อน ก็ไอ้แผ่นสีเขียวๆที่มีลายวงจรนั่นแหละ ซึ่งแผ่นวงจรนี้จะเป็นตัวเชื่อมต่ออุปกรณ์ต่างๆเข้าไว้ด้วยกัน ถ้าจะออกแบบแผ่น PCB เองทั้งหมดก็รู้สึกว่ามันใช้เวลา และต้องลงทุนลงแรงไปศึกษาค่อนข้างเยอะ แต่เมื่อศึกษาไปเรื่อยๆ ก็พบว่า เห้ยยยยย จริงๆแล้วมันไม่ต้องทำ PCB ก็ได้นี่หว่า ทำแบบ hard wire ก็ได้ นั่นเลยเป็นที่มาของโปรเจค hand wire keyboard นี้

Hand wire keyboard

แล้ว hand wire มันคืออะไรละ ? อย่างที่ได้บอกไปแล้วว่าปกติแล้ว อุปกรณ์ electronic มันก็จะวางอยู่บน PCB แน่นอนว่าใน mechanical keyboard มันก็มี pcb เหมือนกัน ส่วน hand wire keyboard มันคือก็คือ keyboard ที่ไม่มี pcb ใช้แค่สายไฟเชื่อมต่ออุปกรณ์ต่างๆเท่านั้นเอง

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

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

What you need to get start

อย่างแรกที่คุณต้องมีคือ .. ใจรัก และอย่างที่สองคือ งบสัก 4000 – 5000 บาท  .. ห๊าา อะไรนะ ทำไมแพงงี้อ่ะ ? ครับแพง ผมไม่เถียง เพราะในเงินจำนวนนี้ ต้องนำไปใช้ซื้ออุปกรณ์เพื่อมาประกอบ เป็น keyboard ซึ่งก็จะมี

สวิตช์ ( MX Switch )

สวิตช์ในโปรเจคนี้เลือกใช้ Cherry MX Switch ถ้าไม่อยากใช้ยี่ห้อนี้จะเลือก MX Clone ยี่ห้ออื่นก็ได้ เช่น Kail, Gaote , Gateron หรือ Geetech ก็แล้วตามสะดวก อยากได้ switch สีไหน ก็เลือกได้ตามใจ ส่วนจำปุ่มที่ใช้ ก็ขึ้นอยู่กับ laybout ที่ต้องการ และราคาของ cherry switch จะตกประมาณปุ่มละ 30 บาท

สเตบิไลเซอร์ (MX Stabilizer Kit)

คืออุปกรณ์ที่ทำให้ปุ่มที่มีความยาวมากหน่อยเช่น space bar นั้น มีความมั่นคงเวลากด ซึ่ง stabilizer นี้ก็จะมีด้วยกันสองแบบคือ cherry mx และ costa ในโปรเจคนี้ ผมเลือกใช้ cheery mx stabilizer ราคาประมาณ 200 บาทต่อชุด คือสำหรับปุ่ม enter , backspace , shift และ space bar

ไดโอด (Diode)

ตามจำนวนปุ่ม ราคาประมาณ อันละ 1 บาท

สายไฟ

ขนาดเล็ก 0.3 – 0.5 สัก 6 เมตร เอาหลายๆสีหน่อยก็ได้ จะได้แยกง่าย ราคาประมาณเมตรละ 5 บาท สำหรับโปรเจคนี้จะใช้ประมาณ  6 เมตร

เพลท (Keyboard Plate)

ในเมื่อเราทำ hand wire และไม่มีแผ่น pcb ให้วางอุปกรณ์ เราจึงต้องมี plate เพื่อใช้สำหรับยึดอุปกรณ์เช่นสวิตช์ โดย plate ที่ว่านี้มันก็คือแผ่นเหล็กที่ วางอยู่ด้านบนก่อน PCB ชั้นหนึ่ง ซึ่งมันจะมีหน้าที่เป็นตัวรองรับสวิตช์ อันที่จริงแล้ว keyboard นั้นไม่จำเป็น ต้องมีแผ่น plate นี้ก็ได้ แต่ส่วนมากจะใส่ไว้เพื่อทำให้แข็งแรงมากขึ้น อย่าง filco ก็มี plate แต่ poker นั้นไม่มี plate แต่อย่างใด ราคาประมาณ 500 – 1000 บาท

เคส หรือ bottom plate

ถ้าสมมติว่าจะออกแบบ hand wire keyboard ให้เป็นแบบ full keyboard , ten key less ( tkl) หรืออาจจะเป็นแบบ 60% ก็สามารถซื้อเคส หรือนำของเก่ามาใช้ได้ แต่เนื่องจากโปรเจคนี้ keyboard layout นั้น ไม่มีเคสรองรับ เราจึงต้องทำ bottom plate ขึ้นมาด้วย

ปุ่มกด (key caps)

เลือกตามใจชอบเลย จะเป็น abs หรือ pbt ก็ได้ราคาประมาณ 800 บาทขึ้นไป

Development Board

นี่คือหัวใจหลักของโปรเจคนี้ เราต้องใช้ development board เพื่อกำหนดว่าปุ่มไหน ทำงานอย่างไร และในโปรเจคนี้ ก็ได้เลือกใช้ Teensy 2.0 ซึ่งมีราคา 800 – 1200 บาท

อุปกรณ์ในการบัดกรี ( Soldering Tools)

ก็อย่างเช่น หัวแร้ง ตะกั่ว ถ้าไม่อยากซื้อใหม่ ตอนนี้ใน กทม ก็มีพวก maker club ให้เข้าไปใช้บริการ ก็ลองหาๆข้อมูลดูครับ

Keyboard Matrix

ก่อนที่ จะไปลงมือทำ เราควรจะเข้าใจก่อนว่า การทำงานของ keyboard นั้นทำอย่างไร ? การทำงานของ keyboard นั้นไม่ได้ซับซ้อน หลักการง่ายๆก็คือว่า สวิตช์จะเชื่อมต่อกับ ขาของไมโครคอนโทรเลอร์ เช่น ปุ่ม A อาจจะเชื่อมกับขา (pin) ที่ 1 ส่วนปุ่ม B เชื่อมกับ pin ที่ 5 ถ้าหากกดปุ่มสวิตมันก็จะเชื่อมสัญญาณไฟฟ้า (เหมือนที่เปิดสวิตหลอดไฟนั่นแหละ) เมื่อไฟฟ้าไหลผ่านได้ มันก็จะวิ่งไปยังขาของไมโครคอนโทรเลอร์ และไมโครคอนโทรเลอร์ก็จะเป็นผู้กำหนดว่า สัญญาณาเข้ามาขาที่ 1 นี้ให้ส่งสัญญาณไปบอกกับคอมพิวเตอร์ว่าคือ กดตัว A อีกที

อย่างที่ได้อธิบายไป ว่า ปุ่มแต่ละอันต้องเชื่อมต่อกับ pin  ของไมโครคอนโทรเลอร์  แต่เนื่องจากว่าจำนวน pin ของ micro controller นั้นมีจำกัด ถ้าจะแยก 1 switch ต่อ 1 pin ก็จะทำให้ micro controller ของเรานั้น ราคาแพง และมีขนาดใหญ่ ดังนั้น แล้วเค้าจึงได้ออกแบบใหม่ ให้ปุ่มหลายๆอันเชื่อมต่อกันเป็นแถวแนวตั้ง (col) และแนวนอน (row) เรียกว่า keyboard matrix เมื่อกดปุ่ม สัญญาณจะถูกส่งออกมาว่า กดจาก row และ col ไหน จากนั้นไมโครคอนโทรเลอร์ ก็ประมวลผลและส่งต่อไปยังคอมพิวเตอร์  ฉะนั้นแล้ว จำนวนขา ที่ใช้ ก็จะเหลือเพียงแค่จำนวน row กับ col ทั้งหมดนั่นเอง

Designed your own keyboard

ในการออกแบบ keyboard นั้นเราต้องวาง layout ของ keyboard กันก่อน ว่าอยากให้ปุ่มอะไรอยู่ตรงไหน และถ้ายิ่งมีปุ่มเยอะ ก็จะยิ่งแพง ดังนั้นแล้วแทนที่เราจะทำ keyboard layout แบบปกติที่มี 104 ปุ่ม เราก็จะออกแบบ layout ใหม่เพื่อให้ปุ่มกด ลดลง แต่ยังได้ฟังก์ชั่นการใช้งานเหมือนเดิม ด้วยการเขียน firmware เข้าไป

ผมก็ได้วาง layout ประมาณนี้

keyboard-layout

จาก layout จะเห็นว่าจำนวนของปุ่มกดมีเพียงแค่ 68 ปุ่ม เมื่อวาง layout เสร็จเรียบร้อยแล้ว จากนั้น ก็เริ่มสร้าง top plate จาก layout ที่ได้มา ซึ่งก็จะมีหน้าตาประมาณแบบนี้

plate

เมื่อได้ plate แล้ว ( ทั้ง top , mid , bottom ) ก็สั่งให้โรงงาน laser cut ตัดแผ่น อลูมิเนียมตามแบบที่เราได้ทำไว้ ซึ่งปกติ มักจะใช้อลูมิเนียมความหนา 1.5 – 2 mm.

1

ในรูปด้านล่าง ก็คือ bottom plate ซึ่งจะมี น๊อตสูงประมาณ 10 mm ไว้เป็นตัวเชื่อมต่อกับ top plate

3

Choose your MX Switch

เมื่อมี plate แล้ว ต่อไปเราก็จะเริ่มนำ switch ที่ต้องการมาประกอบเข้ากับ plate

4

จาก switch ที่ผมมีในตอนนี้คือ เขียว (MX Green) , ขาว (MX White) และ ใส ( MX Clear ) ก็ตัดสินใจว่าจะเอา MX Clear มาใช้ และแน่นอนว่า ต้องเตรียม Stabilizer ไว้สำหรับ space bar , enter , backspace และ shift ด้วย

6

เมื่อทุกอย่างพร้อมแล้ว ก็เริ่มต้นด้วย switch ตัวแรกกันก่อน

7

เวลาที่ใส่ปุ่มเข้าไปในช่อง ให้สังเกตว่า ตัวหนังสือ Cherry จะอยู่ด้านบน

_DSC0189

เมื่อกลับด้าน ถ้าหาก pin สวิตช์ด้านซ้ายบน อยู่สูงกว่าบนขวา ก็แสดงว่าใส่ถูกต้องละ เมื่อเรียงจนเต็ม plate แล้วก็จะได้ดังรูป

_DSC0204

ถ้ากลับด้านมาก็จะเป็นแบบนี้

_DSC0206

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

Soldering

เมื่อปุ่มได้วางบน plate เรียบร้อยในขั้นตอนต่อไปก็เริ่มการบัดกรีไดโอทเข้ากับสวิตช์

_DSC0211

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

_DSC0223

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

เมื่อเชื่อมต่อไดโอดเสร็จแล้ว ต่อมาก็เริ่มเชื่อมในส่วนแนวตั้งเข้าด้วยกัน ในขั้นตอนนี้เราจะใช้สายไฟเป็นตัวเชื่อม

_DSC0225

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

_DSC0229

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

_DSC0266

ในส่วนปลายแถวแนวนอน (row) ก็เช่นกัน  _DSC0255

หากทุกอย่างเรียบร้อยดี เราก็จะเริ่มนำสายไฟ ที่ต่อจากสวิตช์เชื่อมเข้ากับ ไมโครคอนโทลเลอร์

_DSC0245

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

_DSC0263

Firmware

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

Case

เพื่อความสวยงาม ก็จะใช้ อะคีลิก เป็นตัวขั้นกลางระหว่าง top plate และ bottom plate และอย่างที่ผมได้บอกไป ถ้าหาก ทำ keyboard แบบ tkl , 60% หรือ full สามารถนำเคสที่มีอยู่แล้ว หรือจะซื้อใหม่มาใส่ก็ได้

_DSC0274

Put it all to gather

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

_DSC0281

เมื่อทุกอย่างทำเสร็จแล้ว ก็มาถึงขั้นตอนสุดท้าย คือ การใส่ keycaps และเราก็จะได้ keyboard  อันแสนสวยงามนี้

_DSC0293

Summary

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

สำหรับคนที่สนใจอยากจะทำแบบบ้าง .. ยินดีให้คำปรึกษา จะส่ง email หรือ pm มาได้ทาง facebook ก็ได้ครับ

Experiences with test driven development

เมื่อหลายเดือนก่อน ผมได้เขียนเกริ่นเกี่ยวกับ TDD ไป และผมก็ได้บอกกับผู้อ่านว่า ตัวผมเองนั้นเพิ่งจะเริ่มหัด TDD เลยไม่อาจจะบอกได้ว่า มันดีหรือไม่ดีอย่างไร แต่ ณ วันนี้ ผมได้เขียนโปรแกรมแบบ TDD ด้วยภาษา Swift ตั้งแต่เดือน เมษายน จนถึงปัจจุบันเดือนกันยายน เป็นเวลา 6 เดือน รวมไปถึงได้เปลี่ยนวิธีการพัฒนา software ไปเป็น agile และเห็นความเปลี่ยนแปลงต่างๆที่เกิดขึ้น จึงอยากจะนำมาแชร์ให้ฟังว่ามันมีอะไรดีและไม่ดีบ้าง

ข้อดี

  • ช่วยให้การ refactor นั้นง่ายมาก
  • การ debug โปรแกรม น้อยลงมากๆ
  • โปรแกรมมีคุณภาพมากกว่าเดิมเยอะมาก
  • Continuous Integration / Delivery และ Automate Testing

ข้อเสีย

  • ต้องมีเวลาในการเรียนรู้ พอสมควร
  • ในบางครั้งมีความซับซ้อนในการออกแบบโปรแกรม มากกว่าเดิม
  • เขียนโค้ดมากขึ้น (ก็แหงละ ต้องเขียน test นี่)
  • ต้อง maintain test suit

อธิบายเพิ่มเติมกับข้อดีก่อนละกัน คือ เมื่อเราเขียนโค้ดไปเยอะๆเนี่ย บางครั้งโค้ดที่เขียนมันก็อ่านยาก เพราะ ณ จังหวะที่เราเขียนโค้ด บางทีก็ไม่ได้คิดถึงว่า มันจะอ่านง่ายหรือเปล่า วางโครงสร้างแบบนี้ดีหรือยัง คิดแค่เพียงว่า จะให้ผลลัพธ์มันออกมายังไง สุดท้ายโค้ดที่เขียนมันก็ทำงานได้ แต่กลับอ่านยาก บางครั้งแทบจะอ่านไม่รู้เรื่อง โครงสร้างโปรแกรมวางมั่วไปหมด .. เมื่อเริ่มเกิดปัญหาเหล่านี้ สิ่งที่จะทำต่อมาก็คือ เรียบเรียงโค้ดใหม่ ให้มันทำงานเหมือนเดิมแต่อ่านง่ายขึ้น มีโครงสร้างที่ดีขึ้น หรือที่เรียกว่า Refactoring แต่ปัญหาหลักของการ refactoring คือ โค้ดที่เขียนใหม่ มักจะทำงานไม่เหมือนเดิม ที่มันไม่เหมือนเดิม ก็เพราะว่าโค้ดใหม่ของเราอาจจะเขียนไม่ครอบคลุม ลืมนั่นนี่ หรืออาจจะไม่เข้ากับ component อื่นๆ สุดท้ายก็กลายเป็น bug สร้างปัญหาให้เราซะอย่างนั้น แต่การที่เราเขียนโปรแกรมด้วย TDD มันจะบังคับให้เราเขียน Test Case ก่อน นั่นก็หมายความว่า โค้ดที่เราเริ่มเขียนใหม่ มันต้องผ่าน test เสมอ ดังนั้นแล้ว เราจะแทบไม่มีปัญหาเกี่ยวกับการ refactoring เลย และเราจะมั่นใจมากขึ้นกว่าเดิมว่าโค้ดใหม่มันจะไม่ทำให้โปรแกรมพัง

การ debug โปรแกรมก็ลดลง ผมเชื่อว่าหลายคนเสียเวลาหลาย ชม. เพื่อดีบักโปรแกรม ที่มันเสียเวลาดีบักนาน ก็เพราะว่าส่วนมากแล้วเราไม่รู้ว่าปัญหามันเกิดขึ้นที่ตรงไหน มีอะไรหลุดจากที่เราเขียน แต่ปัญหาเหล่านี้จะลดน้อยลง เพราะเรามี test case รองรับไว้แล้ว ถึงแม้ว่า test case มันจะไม่ครอบคลุมในทุกๆส่วน แต่มันช่วย safe ตัวเราจากความสะเพร่าในการเขียนไปหลายอย่างทีเดียว ยกตัวอย่างที่เป็นประสบการตรงก็คือ ในช่วงแรกๆที่เริ่มเขียน TDD ผมคิดว่าการเขียน test case บางอย่างมันดูง่อย และรู้สึกว่ามันไม่มีประโยชน์ คือผมเขียนเคสที่ใช้ทดสอบการแปลงตัวเลขไปสตริง โค้ดที่ใช้สำหรับแปลงตัวเลขไปเป็นสตริงมันง่ายมาก คิดว่าคงไม่มี bug หรอก .. ใช่มันง่ายมาก และ test case นี้ก็ดูง่ายและแทบไม่มีประโยชน์เลย แต่ test case ง่ายๆแบบนี้กลับช่วยตัวผมไว้ เพราะใครจะไปคิดว่าโปรแกรมมันก็ทำงานได้ดี ใน Simulator และ iPhone 6 แต่พอไปทำงานใน iPhone 5 กลับทำโปรแกรมพัง ซะอย่างนั้น .. ปัญหาที่เกิดก็คือ iPhone 5 เป็น 32 bit ส่วน Simulator และ iPhone 6 เป็น 64 bit .. ค่าตัวแปรมันเลยมีขนาดไม่เท่ากัน เมื่อแปลงค่าเป็นสตริงผลลัพธ์เลยเลยผิด ใครจะไปคิดว่า แค่การแปลงตัวเลขเป็นอักษรง่ายๆแค่นี้ มันจะมีปัญา ถ้าไม่มี test ผมอาจจะต้องใช้เวลาหลาย ชม เพื่อหาว่า ทำไมโปรแกรมมันถึงพัง และอาจจะแก้ปัญหาผิดจุด

เมื่อโปรแกรมเรามี bug น้อยลง โปรแกรมมันก็มีคุณภาพมากกว่าเดิม คงไม่มีใครชอบใช้โปรแกรมที่มี bug เยอะๆหรอก จริงไหม ? ต่อให้มันมีฟีเจอร์ดีแค่ไหน ถ้ามันเกิด error บ่อยๆ ก็คงไม่แฮปปี้ที่ใช้โปรแกรมของเรา การที่เขียนโปรแกรมด้วย TDD มันทำให้โปรแกรมมี bug น้อยลงเนื่องจากเรามี test นั่นแหละ

และสุดท้ายคือ การทำ Continuous Integration (CI) มันจะง่ายมาก หลายคนอาจจะเพิ่งเคยได้ยิน CI ผมก็จะขออธิบายคอนเซ็ปคร่าวๆให้ฟังก็คือว่า  CI เนี่ยมันคือการรวมโค้ดกันบ่อยๆ คือเมื่อเราเขียนโปรแกรมใหญ่ๆ มันต้องมีคนเขียนหลายๆคน แต่ละคนก็รับผิดชอบคนละส่วน ทีนี้ปัญหามันก็จะเกิดตอนเอาโค้ดของแต่ละคนมารวมกันนี่แหละ .. เพราะสมมติว่า ต้องเขียน feature A แต่จะเขียนโค้ดที่ master branch ก็ไม่ได้เพราะว่า อาจจะทำโค้ดหลักพัง ดังนั้นนาย ก. จึงแยกโค้ดจาก master branch ไปเขียน branch feature แต่กว่าที่นาย ก จะเขียนเสร็จก็ใช้เวลา 3 วัน และการที่จะเอาโค้ดของนาย ก. มารวมกับโค้ดของคนอื่น .. มันก็จะเกิดปัญหาที่ว่า โค้ดหลัก master branch ได้เปลี่ยนไปแล้ว โค้ดของนาย ก. ก็ต้องแก้ไขเพื่อให้มันทำงานร่วมกับ master ได้ .. แต่ถ้า นาย ก. เอาโค้ดที่เขียนไปในแต่ละวันมารวมเข้ากับ master branch บ่อยๆละ .. ก็แน่นอนว่า นาย ก. คงไม่เกิดปัญหาแบบที่ได้กล่าวไป นั่นก็คือการทำ Continuous Integration .. แต่การที่จะทำให้โค้ดของ นาย ก. มารวมกับ master ได้บ่อยๆนั้น ไม่ใช่เรื่องง่าย เพราะว่า โค้ดที่นาย ก. เขียนไป อาจจะทำ master พังก็ได้ ดังนั้นแล้ว .. ถ้าหากนาย ก. ได้เขียน test ไว้ ก็จะเพิ่มความมั่นใจได้ว่า โค้ดที่นาย ก. เพิ่มเข้ามาจะไม่ทำให้ของเก่าพังนั่นเอง นอกจากนี้ เมื่อมี CI เราก็จะสามารถทำ automate test ได้ง่ายขึ้นกว่าเดิม

พูดข้อดีมาเยอะแล้ว ก็ใช่ว่ามันจะไม่มีข้อเสีย

ข้อเสียอย่างแรกก็คือ มันต้องใช้เวลาในการเรียนรู้ คือ TDD คอนเซปมันง่ายนะ แต่เอาจริงๆแล้ว ยังมีอีกหลายอย่างที่ต้องทำความเข้าใจ เพราะเมื่อเริ่มเขียน TDD สิ่งที่จะตามมาก็คือ ต้องเข้าใจ Stub / Mock เพราะเป็นส่วนที่ช่วยให้เราเขียน test ได้ง่ายขึ้น .. เมื่อเขียน stub/mock เป็นแล้ว ต่อมาก็ต้องเข้าใจเรื่อง dependency injection และ Inversion of Control คือสิ่งพวกนี้มันใช้เวลาในการเรียนรู้ค่อนข้างมาก ที่ผมบอกว่าค่อนข้างมาก ก็เพราะว่าในช่วงแรกนั้น เราอาจจะไม่เข้าใจว่าทำไมจะต้องเขียน mock / stub หรือใช้พวก dependency injection พวกนี้ กว่าที่จะเข้าใจและเห็นปัญหา มันใช้เวลาเรียนรู้สักพักใหญ่ๆ คือมันไม่ใช่แค่ว่าอ่านแล้วเข้าใจนะ แต่มันต้องเขียนไปสักพักถึงจะเข้าใจว่า อ้อออออ มันมีประโยชน์แบบนี้เอง

ข้อเสียอย่างที่สองก็คือ โปรแกรมมันอาจจะซับซ้อนมากกว่าเดิม อ้าวทำไมเป็นอย่างนั้นละ .. เพราะเวลาที่เราเขียนโปรแกรมด้วย TDD สิ่งที่ต้องคิดเป็นอย่างแรกก็คือ เราจะออกแบบให้โปรแกรมเรามัน testable ได้อย่างไร .. คือพอคิดแบบนี้แล้ว บางทีเราต้องเขียนส่วนต่างๆเพิ่มมากขึ้นกว่าแต่ก่อน อย่างเช่น stub / mock คือมันก็ทำให้โปรแกรมมันซับซ้อนขึ้น

TDD ทำให้เขียนโค้ดมากขึ้น แต่โค้ดพวกนั้นไม่ได้เป็นส่วนเกี่ยวข้องกับโปรแกรม เพราะมันเป็นโค้ดในส่วนของ test และโดยเฉลี่ย เราจะต้องเขียนโค้ดมากกว่าเดิม 20% ( เสียเวลาเขียนโค้ดแต่มันก็ลดเวลาในการ debug นะ) และอีกอย่างคือ ถ้าหากผลลัพธ์ที่เราต้องการเปลี่ยนแปลง เราก็จะต้องคอยปรับ test suit ของเราด้วย

สรุป

TDD เป็นสิ่งที่ดีมาก และควรจะหัดเรียนรู้ เพราะมันช่วยให้ชีวิตดีขึ้นหลายๆด้าน โดยเฉพาะ Quality ของ Code และ Product ของเรา แต่ก็ต้องยอมรับว่า สำหรับผู้ที่จะเริ่ม TDD นั้น ไม่ใช่เรื่องที่จะเริ่มได้ง่ายเลย เพราะมันมีหลายอย่างที่ต้องทำความเข้าใจ ( ถ้ามีคนสอนจะเป็นไวกว่ามากครับ ) นอกจากนี้ยังต้องใช้เวลาในการที่จะเรียนรู้ว่า การเขียน test ให้ดีนั้นต้องเขียนแบบไหน ทำยังไง

โดยส่วนตัวผมคิดว่า แม้ว่า TDD จะเป็นวิธีการที่ดีมากในการเขียนโปรแกรม เพราะมันเพิ่มคุณภาพและลด bug ของโปรแกรม แต่มันก็ไม่ได้เหมาะกับงานทุกอย่าง ที่เห็นได้ชัดๆ ก็คือ การเขียนเกมส์  คือไม่ใช่ว่า TDD มันไม่ดีนะ แต่ว่ามันไม่เหมาะกับงานแบบนี้ ลองจิตนาการว่า เราจะเขียน test สำหรับ particle system หรือจะเขียน test ทดสอบว่า เกมส์มัน lag แบบนี้ วัตถุชนกันในแบบ 3D หรือมุมกล้องแบบนี้ผู้เล่นมองไม่เห็น เกมส์มัน lag อะไรแบบนี้ .. คิดออกไหมว่าจะเขียนโค้ดของการ test มันจะออกมายังไง ? และเกมส์โปรแกรมเมอร์ ก็มีวิธีการอื่นที่ให้ผลเหมือนอย่าง TDD เช่น Assertions

แล้วผมจะเขียน TDD ต่อไหม ? .. เขียนครับ และผมก็แนะนำให้พวกคุณเขียนด้วย เพราะมันช่วยให้เราพัฒนาตัวเองได้เยอะครับ แต่ถ้าต้องเขียน เกมส์ ก็คงไม่ได้ใช้ TDD ผมคิดว่าวิธีการต่างนั้นไม่ว่าจะเป็น TDD, automate test หรือ CI อะไรนั้นดีหมด แต่ต้องเลือกสิ่งที่เหมาะสมกับการใช้งานครับ