Let it “Burn”

ไม่ค่อยได้เขียนเรื่อง Software Development สักเท่าไหร่ (ทั้งที่จริงๆ เป็นเรื่องที่เดินสายพูด เดินสายบรรยาย สอน และถนัดที่สุดแล้วในบรรดาเรื่องทั้งหมด) แต่เมื่อคืนน้องในทีมพัฒนา Sticgo (http://www.sticgo.com) Startup ที่ผมเป็น Mentor อยู่ในโครงการ True Incube (http://incube.truecorp.co.th) ดันเอา Chart อะไรบางอย่างขึ้นใน Facebook แล้วพี่ Roofimon (www.roofimon.com) เข้ามาบอกเลย “บาป” แล้วก็งงว่ามันคือ Chart อะไร ผมก็เลยสัญญากับพี่รูฟไปว่าจะเขียนเรื่อง Chart ตัวนี้ใน Blog ด้วยความเป็นลูกผู้ชาย ก็เลยต้องรักษาสัญญาซะหน่อย

เป็นที่รู้และเข้าใจกันดี ว่าการพัฒนาซอฟต์แวร์ตัวหนึ่งมันไม่ใช่เรื่องเล็กๆ มันมีเครื่องไม้เครื่องมือมีกระบวนการมี Mindset อะไรหลายต่อหลายอย่างเอาไว้ให้เราใช้ในการช่วยพัฒนาซอฟต์แวร์

Mindset โบราณที่ลอก Metaphor มาจากการก่อสร้าง หรือที่เรียกว่ากระบวนการแบบ Waterfall ก็มีเครื่องมือหลากหลาย และตัวหนึ่งที่เราต้องเจอกันมาตลอดก็คือ “Gantt Chart” ซึ่งไอ้เจ้า Gantt Chart ตัวนี้เป็นเครื่องมือนำ “แผนการทำงาน” มาวางต่อเนื่องบน Timeline เพื่อดูว่าเราวางแผนการทำงานอย่างไร อะไรต้องทำก่อนทำหลังอะไร แล้วเวลาที่จะใช้คือประมาณเท่าไหร่ ฯลฯ

สิ่งที่ Gantt Chart ตอบได้อย่างชัดเจนก็คือ การให้เห็นแผนการทำงาน ระยะเวลาของงาน และปริมาณงานที่เสร็จไปแล้ว ซึ่งนี่คือสิ่งที่จำเป็นมากในการทำงานอะไรก็ตามในโลกความเป็นจริงที่เราต้องอยู่กับชาวบ้าน ทำงานกับคนอื่น (ลูกค้า เจ้านาย ฯลฯ) เพราะว่ามันจะมีความถามเราตลอดเวลากับคำถามต่อไปนี้ “แล้วจากนี้จะทำอะไร ต่อจากนั้นทำอะไร ใช้เวลาประมาณเท่าไหร่ เหลืองานอีกเยอะมั้ย เสร็จไปแล้วเท่าไหร่” ฯลฯ (ซึ่งพวกนี้จะเกี่ยวข้องกับค่าจ้างเราด้วยนะ)

แน่นอนว่า ในโลกบางใบ คนหลายคนต้องการที่จะเห็นรายละเอียดทั้งหมดเหล่านี้ Up-Front ซึ่งหมายความว่าเห็นรายละเอียดของแผนการดำเนินการ ระยะเวลา และงบประมาณทั้งหมดก่อนที่จะเริ่มดำเนินการ ซึ่งในขณะที่แนวคิดแบบนี้ใช้ได้กับงานบางประเภท มันกลับไม่เหมาะเอาซะเลยกับการพัฒนาซอฟต์แวร์ โดยเฉพาะอย่างยิ่งการพัฒนาซอฟต์แวร์ที่ “เป็นของใหม่ ไม่มีใครทำมาก่อน” ซึ่งมันมี Unknown เยอะ (ถ้าเป็นโปรแกรมประเภท Data Entry ธรรมดาๆ นี่อีกเรื่อง อันนี้พอจะประมาณได้จากประสบการณ์ แต่ต้องมีประสบการณ์เยอะพอที่จะทำได้นะ — บอกตรงๆ ว่าโดยทั่วไป ต่อให้เป็นผมหรือเก่งกว่าผมก็มองเห็นทุกอย่าง Up-Front ขนาดนั้นไม่ได้หรอก)


1.jpg

Continue reading

A New Kind of Design (จากการสอน “Design for iOS7”)

** เนื้อหาของบทความนี้ ตัดทอนมาจากการสอน “Design for iOS7 Workshop” ที่ผมจัดเมื่อปลายเดือน ต.ค. 2556 ที่ Hubba **

เกริ่นก่อน…

เมื่อพูดถึง iOS7 สิ่งหนึ่งที่มักจะโผล่มาในการสนทนาและเป็นประเด็นเสมอ ก็คือเรื่องของ “การออกแบบ” ซึ่งหลายต่อหลายคนจะพูดเป็นเสียงเดียวกันว่า “iOS 7 ใช้ Flat Design” และได้ทิ้ง “Skeuomorphic Design” ซึ่งเป็นเอกลักษณ์ในการออกแบบของ iOS มาตลอดไปแล้ว และเป็นประเด็นต่อเนื่องสะท้อนจากนักออกแบบหลายคนให้ได้ยินบ่อยๆ ว่า “แบบนี้ออกแบบให้สวยงามน่าดึงดูดยากจังเลย”

ก่อนที่จะไปต่อ ผมขอบอกเสียงดังๆ ตรงนี้ก่อนเลยครับ ว่า

“iOS7 ไม่ใช่แค่ Flat Design และไม่ได้ทิ้ง Skeuomorphic!
ตรงข้าม …. iOS7 นี่แหละ โคตร Skeuomorphic เลย!!
มันไม่ใช่ Flat vs Skeuomorphic ตั้งแต่ต้นแล้ว!!!”

ห๊ะ?!?!? iOS7 เนี่ยนะ Skeuomorphic?!?!?! บ้าหรือเปล่า?!?!?

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


1.jpg

Continue reading

ว่าด้วย iOS 7 “Developer Beta”

[update 29/06] เพิ่มกรณีตัวอย่างของแอพที่เจ๊ง และเพิ่มบทส่งท้ายจากการเขียนเพิ่มเติมของคุณ Prem Sichanugrist ผ่านทาง Facebook


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

แล้วมันมีเรื่องอะไรให้ผมต้องเขียนถึงล่ะครับ ก็ในเมื่อมันเป็นเรื่องปกติ๊ปกติขนาดนั้น?

เรื่องของเรื่องก็คือ เมื่อไม่นานมานี้ Apple ได้ประกาศ iOS รุ่นใหม่ คือ iOS 7 ซึ่งมีการเปลี่ยนแปลงแบบล้างบางในเรื่องการออกแบบและการใช้งานหลายๆ อย่าง ซึ่งเป็นการเปลี่ยนแปลงใหญ่ขนาดที่ทาง Apple เองบอกว่า “ใหญ่ที่สุดตั้งแต่ออกไอโฟนมา” เลยทีเดียว และแน่นอนว่าก็เช่นเดียวกับการเปลี่ยนแปลงทุกครั้ง Apple ก็จะออกรุ่นทดลองใช้มาให้ทดลองใช้ก่อน

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

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

ก็…. มันไม่ใช่ “Beta” ปกติน่ะสิครับ …..


dev_beta.png

ครับ มันคือ “Developer Beta” ไม่ใช่ Public Beta หรือ Consumer Beta แล้วมันหมายความว่ายังไงล่ะ?

Continue reading

จุดยืน ต้นทุน มูลค่า ซอฟต์แวร์ และ “แอพตู้”

เคยสัญญาว่าจะเขียนภาคต่อของบทความ “ต้นทุน/มูลค่า” ที่แท้จริงของซอฟต์แวร์” ที่เป็นประเด็นต่อเนื่อง แต่ไม่มีเวลาและไฟพอที่จะเขียน แต่พักหลังๆ เนื่องจากตัวเองได้ involve กับการบ่มเพาะและสร้าง Startup Tech Industry ในประเทศไทยค่อนข้างมาก ก็เลยคิดว่าถึงเวลาที่ผมจะต้องเขียนเรื่องนี้ต่อเสียที

จากบทความก่อน ที่ผมลงท้ายว่า

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

มันเป็น The price we all have to pay … สิ่งที่พวกเราทุกคนต้องจ่ายด้วยกัน

ที่จริงแล้วผมต้องการจะสื่อถึงอะไรกันแน่หรือสื่อถึงอะไรบ้างเหรอ อะไรคือ “สิ่งที่เราทุกคนต้องจ่าย” แล้วทำไมเราถึงต้องแคร์กับมัน?

ต้องบอกก่อนนะครับว่า ผมไม่ได้สนใจเรื่อง “รายได้ของการขายโปรแกรมให้กับ End User” เป็นหลักด้วยซ้ำไป เมื่อผมเขียนบทความนั้น ดังนั้นประเด็นเรื่อง “การลงแอพตู้ทำลายรายได้ของนักพัฒนาหรือไม่” จึงไม่ใช่ประเด็นหลัก แต่ผมเห็นปัญหาภาพใหญ่กว่านั้น ว่าโดยทัศนคติแล้ว พวกเรา “ตีค่า”​ ซอฟต์แวร์ หรือคอนเทนท์ กันอย่างไร มีมูลค่าเท่าไหร่ เป็นเพียงของแถม เป็นสิ่งที่ไม่มีมูลค่า หรือตรงกันข้าม

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

  • เกิดอะไรขึ้นกับเรื่อง Tablet ป.1 ครับ? ต้นทุนเรื่องมูลค่าของโปรแกรมที่จะต้องพัฒนาขึ้นมารองรับอยู่ที่ไหน แล้วเนื้อหาล่ะ ผมเห็นแต่สนใจเรื่องฮาร์ดแวร์กันซะจนไม่ได้สนใจเรื่องพวกนี้เลย แล้วก็นำมาซึ่งการเร่งพัฒนาและการแปลงเนื้อหาอย่างฉาบฉวยไม่ได้คิดหน้าคิดหลังกันเท่าไหร่
  • เกิดอะไรขึ้นกับการพัฒนาระบบฐานข้อมูล การพัฒนาโปรแกรมด้านบริการหลายต่อหลายตัวครับ? เราไม่ได้สนใจเรื่องคุณภาพของข้อมูล คุณภาพเรื่องการใช้งาน ฟังก์ชั่นการทำงาน อะไรกันเลย เราละเลยเรื่องพวกนี้มากมาย เราคิดว่าต้นทุนของซอฟต์แวร์มันมีแค่การเขียนมันขึ้นมาเท่านั้น ซึ่งมันน้อยกว่าความเป็นจริงมากมาย
  • เกิดอะไรขึ้นกับงานอีกหลายงาน ที่คิดว่าต้นทุนทางการพัฒนาซอฟต์แวร์มันน้อย แล้วเราต้องลงเอยกับระบบห่วยๆ มากมายมหาศาลที่มันมีผลกับชีวิตของพวกเราในระยะสั้นและระยะยาวไม่แพ้อย่างอื่นเลย

Continue reading

“ต้นทุน/มูลค่า” ที่แท้จริงของ “ซอฟต์แวร์”

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

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

ผมว่าคนบ้านเรามันประหลาดแท้ ผมเคยได้ยินความฝันเฟื่องมาเยอะว่าเราอยากจะมีนักพัฒนาที่ประสบความสำเร็จระดับโลก อยากมี Bill Gates เมืองไทย อะไรประมาณนั้น และเรามักจะรู้สึกหน้าใหญ่ใจโตเสมอ เวลาที่ยืดว่า “คนไทยเก่ง” เมื่อเด็กเราได้รางวัลเหรียญทองโอลิมปิคหรืออะไรก็ตาม

แต่มันไปไหนกันหมดล่ะ? จริงๆ เรื่องนี้ผมเคยเขียนเปรยๆ ไปนิดหน่อยในบทความเก่าๆ เรื่องคอมเมนท์เพิ่มเติมถึงบทสัมภาษณ์ผมที่ลงกรุงเทพธุรกิจ และที่ผมไปออกรายการแบไต๋ไฮเทค ว่ามันมีปัจจัยอะไรบ้างที่ทำให้สังคมอื่นๆ เค้าเจริญเหนือเราได้ ทั้งๆ ที่วัดกันตัวต่อตัว คนที่เก่งที่สุดของเราก็ไม่ได้แย่อะไรกว่าใครเค้าเลย (ซึ่งผมก็เข้าใจว่ามันไม่ได้วัดกันแค่คนที่เก่งที่สุด แต่มันต้องวัดกันทั้ง community)

การที่เราไปไหนไม่ได้ เพราะว่าเรา “ตีค่าของซอฟต์แวร์ต่ำเกินไป” ย้ำอีกครั้งนะครับ เราตีค่ามันต่ำเกินไปมาก ที่ๆ เค้าเจริญเค้ารู้กันมานานแล้ว อย่างที่ Steve Jobs เคยพูดเสมอว่า “It’s Software, Stupid” น่ะแหละ สิ่งที่สำคัญทีสุดในคอมพิวเตอร์ คือ “ซอฟต์แวร์” ครับ ไม่ใช่ฮาร์ดแวร์ หรือคอนเทนท์ (Content) อย่างที่หลายคนเข้าใจ ถ้าซอฟต์แวร์อ่อนซะอย่างเดียว ฮาร์ดแวร์จะดีแค่ไหน มันก็ด้อยไปด้วย ถ้าซอฟต์แวร์ห่วยซะอย่างเดียว ต่อให้เตรียมคอนเทนท์ดีแค่ไหน มันก็กากทั้งนั้น เพราะการใช้งานคอนเทนท์มันก็ต้องผ่านซอฟต์แวร์ (แต่ที่เราพูดถึงคอนเทนท์โดดๆ ได้ ก็เพราะว่าสำหรับมีเดียหลายๆ อย่าง มันมักมีซอฟต์แวร์ดีๆ อยู่แล้ว ทำให้มองถึงคอนเทนท์ดีๆ ได้ แต่ถ้าต้องการพัฒนาคอนเทนท์เฉพาะทาง เช่น Interactive Learning ทั้งหลาย ไม่มีซอฟต์แวร์ดีๆ มันก็ทำไม่ได้

อะไรบ้างที่มันตามมา? ผมเห็นความพยายามในการหา “ของเถื่อน/ของโจร” (ผมใช้คำว่า “ของเถื่อน/ของโจร” นะ ไม่ใช่คำว่า “ของฟรี”) ของคนหลายคนแล้วผมเศร้าใจนะ แล้วพวกนี้ก็มักจะมีแต่ความเห็นแก่ตัวเต็มไปหมด ยกตัวอย่างให้เห็นชัดๆ มั้ยล่ะ

  • บางคนต้องการทำร้านขายหนังสือออนไลน์ ขายเพลงออนไลน์ ขายนี่นั่นโน่นออนไลน์ แล้วกลัวแทบเป็นแทบตายกับการที่คนอื่นจะมาก๊อปปี้ของๆ ตัวเอง แต่ขอโทษนะ ดันถามหา crack, serial โปรแกรม เอา iPhone ไปลงโปรแกรมตามมาบุญครอง
  • มันเคยมีคนอยากให้ผมพัฒนาซอฟต์แวร์บน iPhone ให้นะ แล้วก็กลัวเหลือเกินว่าคนอื่นจะ crack ไปใช้ แล้ววันหนึ่งเขามาถามผมว่าจะเอาโปรแกรมไปทดสอบบนเครื่องพวกเขาได้มั้ย ผมบอกวิธีการไปว่าต้องทำแบบนี้นั้นโน้นก่อน เค้าบอกว่า “เครื่องพวกผม jailbreak ทั้งบริษัท” พอถามไปถามมา ก็หากันแต่ของเถื่อนจากมาบุญครอง แถมจ่ายเงินอีกตะหากนะนั่นน่ะ
  • ช่างภาพหลายคนนะ จะเป็นจะตายเวลารูปถูกคนเอาไปใช้ แต่ขอโทษนะ ถ้ากูใช้ Photoshop/Lightroom เถื่อนได้ กูเก่ง กูฉลาด กูไม่โง่เสียเงิน
  • อาจารย์มหาลัยหลายคน เด็กลอก paper ด่าเด็กแทบเป็นแทบตาย บอกว่าจะไม่ให้จบ แต่ท่านก็ขโมยโปรแกรมชาวบ้านเค้าใช้ เจอหน้ากันทีไรถามหาแต่วิธีใช้โปรแกรมแบบไม่ต้องจ่ายเงิน ทำได้มั้ย หา serial ให้หน่อย crack ให้หน่อย
  • คนที่ปล้นมาให้คนอื่น ก็ชอบบอกว่า “เป็นคนไทยต้องช่วยกัน เราไม่ช่วยกันใครจะช่วยเรา เราก็ต้องเอามาแบ่งปันกันใช้”

ไอ้อันสุดท้ายนี่แหละ ที่ทำให้ผมรู้สึกเจ็บปวดที่สุด ว่าทำไมมันถึงมีความคิดที่เห็นแก่ตัวกันได้มากมายขนาดนี้ … บางครั้งผมถึงกับตั้งคำถามว่า “จะเป็นอย่างไร ถ้าคนหมู่มาก เห็นแก่ตัว” ..​ “จะเป็นอย่างไร ถ้าการโหวต การลงความเห็นของคนหมู่มาก มันมาจากรากฐานความเห็นแก่ตัวของแต่ละคน ..” มันจะทำให้เกิดเรื่อง “รวมหัวกันปล้น” อะไรสักอย่าง แล้วยังคงเหมือนเป็นความชอบธรรม ได้ไหมล่ะ?

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

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

ถ้า 30 บาทที่จะจ่ายให้นักพัฒนา มันเยอะแยะมากมายมหาศาลมากนักล่ะก็ ลองคิดอะไรกันดูเล่นๆ มั้ยครับ ว่าเดือนๆ นึงเราเอาเงินไปทำอะไรบ้าง ที่มันพอๆ กัน

  • เคยให้เงินทิปเด็กเสิร์ฟกันเดือนละกี่บาทครับ? บางคนเงินทอนไม่เก็บกันทีละสิบกว่าบาท ป๋ามากครับ จ่ายได้ไม่ยาก (ยิ่งเด็กเสิร์ฟสวยนี่ยิ่งยัดแบงค์ยี่สิบลงไปด้วยไม่ยากเลย) ทำแบบนี้ทุกมื้อเป็นเงินเท่าไหร่ อย่าบอกนะครับ ว่าเด็กเสิร์ฟฐานะยากจน ทำงานหนักต้องนี่นั่นโน่น แล้วโปรแกรมเมอร์ล่ะครับ เราไม่ได้ทำงานเหรอ เรารวยนักเหรอ เด็กเสิร์ฟมีเงินเดือน แต่เราหลายคนไม่มีเงินเดือนแบบประจำ ก็มีแค่เงินจากการรับจ้างทำงาน กับเงินจากการกดซื้อโปรแกรมทีละ 30 บาทเท่านั้นนะครับ อย่าลืมข้อนี้ไป การมีคอมใช้ก็ไม่ได้แปลว่ารวยนะ มันก็สิ่งจำเป็นสำหรับการทำงานของพวกเราน่ะแหละ
  • หนักกว่านั้นครับ เคยโชว์ป๋าด้วยการให้เงินขอทานเวลาเดินข้ามสะพานลอยกับแฟนมั้ยล่ะ? ลองคิดๆ ดูซิ ว่าเท่าไหร่ ถ้าทำเลดีๆ หน่อย รายได้ต่อเดือนอาจจะมากกว่าโปรแกรมเมอร์บ้านเราโดยเฉลี่ยซะอีกนะครับ
  • แย่กว่านั้นหน่อย เราเคยให้เงินคนที่ “หาของโจรมาขาย” กันเท่าไหร่กันเหรอครับ ลง app ที่ขโมยมาครั้งละ 500 บาท ได้ app เต็มเครื่อง ที่เราก็ไม่ได้ใช้หรอก ใช้จริงๆ จังๆ ก็อาจจะแค่ 7-8 ตัว ถ้าจ่ายให้นักพัฒนาตรงๆ ก็ไม่ต่างอะไรกันมากมายนักหรอก

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

แล้วไอ้ข้อสุดท้ายนี่มันต่างกันตรงไหนล่ะ?

หลายคนคิดง่ายๆ ตื้นๆ แค่ “เงินออกจากกระเป๋าเราเท่ากัน ให้ได้มากที่สุดดีกว่า ไม่เข้ากระเป๋านักพัฒนาเลยก็ช่างมันประไร” แต่ลองมองถัดไปสักนิดนะ นักพัฒนาได้เงินไปแล้วเอาไปทำอะไรเหรอครับ ก็ต้องเอาไปศึกษานี่นั่นโน่นเพิ่มขึ้น เอาไปเพิ่มทรัพยากรในการทำงาน ไม่ว่าจะเป็นคน ความรู้ หรือเครื่องที่พอจะทำงานได้ดีขึ้น หรือจ้างคนมาเป็น customer service คอยตอบคำถามผู้ใช้ ฯลฯ อย่าคิดว่าเอาไปซื้อเรือยอร์ชซื้อรถสปอร์ตแบบไร้สาระกันทุกคนสิครับ (จริงๆ ถ้ามีเงินไว้ละลายเล่นเมื่อไหร่ หลายคนอาจจะทำงั้นนะ แต่โปรแกรมเมอร์แทบจะ 100% ของบ้านเรา ไปไม่ถึงจุดนั้นเด็ดขาด แค่ไม่อยู่ในภาวะเดือนชนเดือน ก็หรูพอควรแล้ว)

ผมก็เห็นว่าคนไทยควรช่วยกันนะ แต่เราอยากได้อะไรล่ะ? เราอยากได้สังคมนักพัฒนาที่เก่งๆ กันหรือเปล่า เราอยากได้คนไทยที่เก่งไม่น้อยหน้าใครในโลกบ้างไหม? … ไปๆ มาๆ ผมเชื่อว่า “เราไม่อยากได้มันหรอก” ทำไมน่ะเหรอ ก็เพราะคนไทยมันไม่ช่วยกันเองไงล่ะครับ แล้วเราจะได้นักพัฒนาเก่งๆ สังคมนักพัฒนาเก่งๆ แบบที่เราฝันมาจากไหน (หรือว่าผมฝันไปคนเดียววะ)

ทีนี้เราจะเห็น “ค่า” จริงๆ ของซอฟต์แวร์ล่ะครับ … cost จริงๆ ที่พวกเราทุกคนต้องจ่ายก็คือ วงการที่นักพัฒนาถีบตัวเองไม่ขึ้น scale ตัวเองไม่ได้ สร้างทรัพยากรในการรองรับงานที่ใหญ่ขึ้น มี demanding สูงขึ้นไม่ได้ เพราะทุกอย่างต้องใช้เงิน ใช้ใจและมาม่าอย่างเดียวไม่ได้ (ขนาดมาม่ายังต้องซื้อเลย) ซึ่งยิ่งจะทำให้เราเสียศักยภาพในการแข่งขันในภาพรวมมากขึ้นๆ ทุกวัน

คุณภาพของสิ่งที่สำคัญที่สุดในเรื่อง IT อย่างซอฟต์แวร์ นับวันเรายิ่งจะล้าหลัง … เรากดราคาฮาร์ดแวร์สู้จีนไม่มีทางได้ เราจะพัฒนาอะไรล่ะครับ ถ้าไม่ใช่ซอฟต์แวร์กับคอนเทนท์ (ซึ่งมักต้องการซอฟต์แวร์เป็นตัวขับเคลื่อน)

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

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

นักพัฒนา มันก็คนเหมือนๆ กับทุกคนน่ะแหละครับ ต้องกินข้าว ต้องมีชีวิต ต้องจ่ายค่าเช่า ต้องเลี้ยงครอบครัว ต้องแบกภาระของครอบครัว ถูกครอบครัวฝากความหวัง ฯลฯ เหมือนกับพวกคุณทุกคนน่ะแหละครับ

ผมอยากจะตะโกนดังๆ ตรงนี้เหลือเกินครับ

นักพัฒนาไทย มันไประดับโลกไม่ได้หรอก ไม่ใช่เพราะมันไม่เก่ง แต่เพราะคนไทยด้วยกันเองไม่ช่วยกันสนับสนุน ปากบอกอยากได้คนเก่ง อยากให้คนไทยไม่แพ้ใครในโลก แต่ก็ปล่อยให้มันตายไป ใจไม่ช่วยสร้าง

มันไปไหนไม่ได้หรอกครับ เพราะวุฒิภาวะ (maturity) และทัศนคติ (mindset) ของ “สังคมผู้ใช้” ของเราไปไม่ถึง ไม่สนับสนุนให้พวกเราไปได้ ไม่ยอมให้ไป และต้องการให้นักพัฒนามันตายกันหมด

ถ้าจะอ้างว่า “เป็นคนไทยต้องช่วยกัน” … ผมก็อยากจะกราบทุกท่านตรงนี้ ว่าท่านพูดได้โดนใจผมเหลือเกิน

แล้วพวกเราล่ะ … ไม่ใช่ “คนไทย” กระนั้นหรือ? แล้วทำไมท่านไม่ช่วยเราบ้าง?

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

มันเป็น The price we all have to pay … สิ่งที่พวกเราทุกคนต้องจ่ายด้วยกัน

ด้วยความเคารพ
รวิทัต ภู่หลำ, ศิลปินซอฟต์แวร์ นักเขียน และอาจารย์มหาวิทยาลัย


[อัพเดท 10/07/2555] ป.ล. ผมเขียนเรื่องนี้ ตั้งใจเพื่อเป็น wake up call ด้วยส่วนหนึ่ง ดังนั้นจะแรงหน่อย และผมต้องการชี้ให้เห็นภาพที่มันใหญ่ขึ้นอีกนิดหน่อย ของอุตสาหกรรม IT ว่ามันเป็นเรื่องของพวกเราหลายต่อหลายคน รวมถึงผู้บริโภคด้วย มากกว่าแค่นักพัฒนา

นาฬิกาปลุก มันต้องดังหน่อย ต้องแรงหน่อย ไม่งั้นคงจะหลับกันต่อไป แล้วมันก็จะกลับมาเดินปกติต่อไป จนถึงเวลาที่จะต้องปลุกอีกครั้ง

ก่อนที่มันจะกลายเป็นนาฬิกาตาย … เมื่อถ่านมันหมดไฟ และใจมันหมดลาน

หัดเขียนโปรแกรมยังไงให้เก่ง?

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

ก่อนอื่น ต้องทำความเข้าใจพื้นฐานก่อน ว่า

“การเขียนโปรแกรม”​ มันเป็นเรื่อง “Skill การสื่อสาร”

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

ปัญหาอันดับแรกๆ ที่ผมพบก็คือ “คิดเป็นขั้นตอนไม่เป็น”

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

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

ดังนั้นในการสื่อสาร เราจะมีปัจจัยตั้งต้นคือ “ชีท” และ “กลุ่มคน”​ และปลายทางที่เราต้องการคือ “ทุกคนในกลุ่ม ได้รับชีทที่ถ่ายเอกสารแล้ว” ถ้าจะสื่อสารเป็นกระบวนการแบบโปรแกรม หรือฟังก์ชั่นทางคณิตศาสตร์ ก็จะได้ลักษณะนี้

จำนวน = นับ(คนในกลุ่ม)
ชีทที่ถ่ายเอกสารแล้ว = ถ่ายเอกสาร(ชีท, จำนวน)
คนที่ได้รับชีท = แจกจ่าย(ชีทที่ถ่ายเอกสารแล้ว, คนในกลุ่ม)

เป็นต้น

ปัญหาอันดับต่อไปที่ผมพบก็คือ การให้ความสำคัญกับตัวภาษาโปรแกรมมากไปในตอนแรก (แต่น้อยไปในระยะหลังจากนั้น)

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

ผมนึกถึงตอนที่ตัวเองไปเรียนที่ญี่ปุ่น ที่ผมอ่านอะไรจากการ์ตูนได้ (ผมเรียนภาษาญี่ปุ่นจากการอ่านการ์ตูนแทบจะล้วนๆ) ก็จะหาเรื่องทดลองใช้เลย ไม่ว่าจะเป็นการลองถามทางคนในรถไฟฟ้า การแกล้งหลงทางแล้วถามตำรวจ ฯลฯ ซึ่งมันได้ผลโคตรดี ถึงได้มีคนบอกว่า เวลาไปเรียนต่างประเทศ อยากจะเป็นภาษาเร็วๆ ต้องปิ๊งสาว (หรือเพศที่สนใจ อะไรก็ได้) สักคน เพราะเราจะต้องหาเรื่องใช้ภาษา ไม่ว่ารู้น้อยรู้มากแค่ไหนก็จะหาเรื่องสื่อสารตลอดเวลา แล้วมันจะเป็นเร็ว

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

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

ตัวอย่างง่ายๆ ผมเชื่อว่าแทบทุกคนรู้จัก

printf("Hello, world\n");

(หรืออะไรก็ได้ที่เทียบเท่ากัน ซึ่งแตกต่างกันไปตามภาษา) ซึ่งมักจะได้เรียนกันในคลาสแรก ไม่ก็หนังสือบทแรก แต่จะมีกี่คนเชียวที่ “เล่น” กับมันต่อ เอาไปหัดสื่อสารมันต่อ ลองหาดูว่าจะประยุกต์หรือพลิกแพลงมันอย่างไรได้บ้าง เช่น จะลองให้แสดง

Name            Lastname        Sword
Byakuya         Kuchiki         Senbonsakura
Sousuke         Aizen           Kyokazuigetsu

โดยช่องว่างให้เว้นว่างทั้งหมด 2 Tab และให้ได้โดยใช้ printf เพียงตัวเดียว ทำได้หรือไม่ อย่างไร อะไรทำนองนี้

======================================

สรุปสั้นๆ การเขียนโปรแกรมก็เหมือนกับการสื่อสาร คิดว่าทำอย่างไรให้สื่อสารเก่ง ก็ทำแบบนั้นกับการเขียนโปรแกรม หลายคนอยากจะพูดภาษาอังกฤษเก่ง แต่เจอฝรั่งทีไรวิ่งหนีทุกที ให้พูดก็ไม่ยอมพูด แล้วมันจะเก่งได้อย่างไร ต่อให้วันๆ นั่งท่องไวยากรณ์ นั่งท่องศัพท์ ก็ไม่เคยมีประโยชน์ … พูดในฐานะคนที่พูดได้ 3 ภาษา ฟังออก 4 อ่านออก 6 ภาษา (แต่เป็นงูๆ ปลาๆ ไม่ค่อยแข็งแรงเท่าไหร่ซะ 3) นะครับ

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

สุดท้ายคือ ให้ “ลงมือทำ” เพราะความ “อยากได้” มันไม่เคยมีประโยชน์เลย ถ้าไม่ “ลงมือทำ”

======================================

เรื่องสุดท้าย … แต่ก่อนอื่นต้องขอเล่าเรื่องตัวเองให้ฟังสักหน่อย ผมมีวิธีการเรียนเขียนโปรแกรมอยู่อย่างหนึ่ง ซึ่งโดยส่วนตัวแล้วมันเวิร์กสำหรับผม คือ

หัดให้ “มือ” เขียนโค้ด อย่า copy & paste เด็ดขาด และอย่าใช้สมองคิดโค้ดโดยไม่จำเป็น

เวลาผมจะหัดเขียนโปรแกรมในภาษาใหม่ และหัดจากหนังสือ ไม่ว่าจะเป็นหนังสือใครเขียน (และแน่นอน ว่าผมลองทำแบบนี้กับหนังสือตัวเองด้วย) ผมจะ “อ่านเนื้อหาผ่านๆ” ก่อน 1 เที่ยว จากนั้น “พิมพ์” โค้ดเหล่านั้นเองด้วย “มือตัวเอง” ผมจะไม่เคย copy & paste โค้ดในช่วงของการเรียนรู้เลย เพราะว่าสิ่งที่สำคัญที่สุดคือ มือผมต้องโค้ดเป็น

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

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

ซึ่งนี่คืออีกปัญหาที่ผมพบ ซึ่งเป็นปัญหา “ใหญ่ที่สุด” คือ ผู้ฝึกเขียนโปรแกรม ต้องการได้ผลลัพธ์สำเร็จรูปเร็วเกินไป ฉาบฉวยเกินไป ต้องการโค้ดที่เอาไป copy & paste ได้ กด compile & run เห็นผลลัพธ์ แล้วคนขยันหน่อย ก็อาจจะกลับมานั่งอ่านโค้ดบ้าง นอกนั้นก็ปล่อยๆ มันไป เพราะได้ผลแล้ว

ปัญหาที่ว่าน้ีก็คือ “โค้ดไม่เคยผ่านมือ” และ “ไม่ได้เป็นคนเริ่มเอง” (แต่เริ่มจากโปรเจคที่เสร็จแล้ว ที่คนอื่นเริ่มไว้ให้แล้ว) ซึ่งทำให้เวลาต้องทำงานจริงๆ จะเริ่มต้นอะไรเองไม่เป็นเลย และโค้ดเองไม่เป็นเลย มือมันจะไม่ขยับ และต้องไปเปลืองแรงสมองคิดโดยใช่เหตุถึงเรื่องโค้ด แล้วหลายคนก็จะ Blank .. ตายตรงนี้

ผมมีข้อสังเกต ว่าถึงระบบการศึกษาบ้านเรามันจะไม่ได้แย่ลงกว่าเดิมเท่าไหร่ แต่ทำไมคนเดี๋ยวนี้เขียนโปรแกรมแย่ลงกว่าเมื่อก่อนมาก ก็เพราะมันเริ่มต้น “ง่ายเกินไป” และ “ฉาบฉวยเกินไป” มีโค้ดอยู่แล้ว copy & paste ง่าย แค่ Ctrl+C, Ctrl+V ก็จบแล้ว หรือไม่ก็ download งานที่เสร็จแล้วมา unzip แล้วใช้งานได้เลย ดังนั้นโค้ดจะไม่ผ่านมือเลย ซึ่งนี่คือเรื่องที่หลายคนอาจมองว่ามัน “เล็กน้อย” แต่จริงๆ แล้วนี่คือเรื่องที่ “ใหญ่ที่สุด” เรื่องหนึ่ง

สมัยผมหัดเขียน C++ 98 (ที่เป็น Standard แรกที่มี STL) ผมซื้อหนังสือ The C++ Standard Template Library ของ Nicolai Josuttis มานั่งอ่านผ่านๆ ทั้งเล่มก่อน 1 เที่ยว และ “นั่งลอก” โค้ดทุกบรรทัดด้วยมือตัวเอง ทั้งเล่ม จากนั้นค่อยพยายามศึกษารายละเอียดอีกครั้งในเบื้องลึก

ซึ่งนี่เป็นวิธีเดียวกับที่ผมศึกษา Perl, Ruby, Objective-C, Mathametica, Haskell, OCaml, Scheme และภาษาอื่นๆ ที่ผมเขียนเป็น และเขียนพอเป็น

และนี่แหละ เป็นสาเหตุที่ผม “ไม่อยากให้โค้ด” สำหรับโปรแกรมจากหนังสือคู่มือเขียน iPhone App ของผม ซึ่งพิมพ์โดยสำนักพิมพ์ Provision

สรุปสั้นๆ: อยากเขียนโปรแกรมเก่ง ต้องหัด “เขียน” โปรแกรมครับ อย่าหัดแต่รันโปรแกรมที่คนอื่นเขียนแล้ว

======================================

หวังว่าคงจะเป็นประโยชน์บ้าง …​ จริงๆ แล้วเนื้อหาบทความนี้ คัดมาจาก “บทแรก” ของหนังสือเล่มใหม่ที่ผมกำลังเขียนอยู่ (ยังไม่มีชื่ออย่างเป็นทางการ แต่ประมาณ “คิดและโค้ด ผ่านภาษา Objective-C”) โดยดัดแปลงให้เหมาะกับการเป็นบทความบนเว็บ

รออ่านนะครับ ผมหวังว่าจะเป็นหนังสือที่ดี(นะ)

หนังสือ iPhone App: 3 บทใหม่ (ที่เคยคิดจะเอาใส่หนังสือเล่ม 2)

เนื่องจากก่อนหน้านี้ผมได้เขียนหนังสือ “คู่มือเขียน iPhone App” ซึ่งออกมาในช่วงคาบลูกคาบดอก ระหว่างรอการเปลี่ยนแปลง จาก iOS 4 เป็น iOS 5 และ Xcode 4 เป็น Xcode 4.2 ซึ่งเป็นการเปลี่ยนแปลงระดับ “Major Change”

ใจจริงผมอยากจะเขียนให้อิงกับ iOS 5 และ Xcode 4.2 เป็นหลักตั้งแต่ต้น แต่ในขณะนั้นไม่มีใครบอกได้ว่าทั้งสองตัวนี้จะออกมาเมื่อไหร่ และด้วยเหตุผลหลายๆ อย่าง รวมถึงความต้องการของสำนักพิมพ์ ที่อยากจะออกสู่ตลาดเร็วๆ ในขณะที่ยังไม่มีเจ้าอื่นออกมา (ซึ่งผมเข้าใจเหตุผลนี้ และไม่มีปัญหาใดๆ ทั้งสิ้น) ทำให้เราตัดสินใจทำมันออกมาเป็น “iOS 4 และ Xcode 4” เพื่อให้ออกมาได้ก่อน และหลายคนได้เริ่มก่อน

และด้วยเหตุผลของ NDA ทำให้ผมไม่สามารถที่จะเขียนถึงรายละเอียดอะไรของ iOS 5 และ Xcode 4.2 ได้เลย

ทีนี้ปัญหาก็เลยเกิดขึ้น เมื่อ iOS 5 ออกมาแล้ว และ Xcode 4.2 ออกมาแล้ว (และไม่สามารถหา Xcode 4.0, 4.1 ได้ง่ายๆ อีกต่อไปแล้ว เพราะ Xcode ที่อยู่บน Mac App Store มันเป็น 4.2) ปัญหาง่ายๆ มันก็เลยเกิดขึ้น เพราะว่ามันมีการเปลี่ยนแปลงมากมาย อย่างที่ผมบอกไว้ ทั้งในระดับตัวภาษา Objective-C, iOS SDK และตัว Xcode เอง โดยเฉพาะอย่างยิ่งเมื่อ Default Settings ทุกอย่างนั้นกำหนดให้ใช้ความสามารถใหม่โดยปริยาย

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

สำหรับท่านที่ไม่สนใจจะศึกษาเพิ่มเติม หรืออยากจะทำตามหนังสือเล่มแรกอย่างเดียว ผมมีคำแนะนำว่า เวลาสร้างโปรเจคใหม่ ให้เลือก “ไม่ใช้ Storyboard” และ “ไม่ใช้ Automatic Reference Counting” เสมอครับ

ตอนนี้ผม “พับ” โครงการที่จะเขียนหนังสือเล่ม 2 ออกตีพิมพ์เรียบร้อยแล้วครับ แต่จะ “เขียนใหม่ทั้งหมด” เป็น iOS Development Series โดยไม่เหลือเยื่อใยกับของเดิม เป็นการเขียนใหม่ 100% ทั้งตัวอย่าง เนื้อหา เรียบเรียง โดยจะทำเป็น e-Book only และขายผ่านเว็บไซต์ของ Code App และอาจจะผ่าน App ซึ่งออกแบบมาเฉพาะสำหรับหนังสือเล่มนี้ เท่านั้น โดยมีเนื้อหาแบ่งเป็นหลายเล่ม ตั้งแต่เริ่มต้นเขียนโปรแกรมด้วย Objective-C เต็มๆ เล่มเลยทีเดียว

อดใจรอกันสักหน่อยนะครับ

[ประกาศ] iOS SDK 5 & Xcode 4.2 Training

ทีมงาน Code App จัด Training สำหรับ iOS 5 SDK & Xcode 4.2 ครับ จัดเต็ม 4 วัน 17, 18, 24, 25 ธันวาคม รายละเอียดดูได้จากเว็บไซต์ของ Code App ครับ

พัฒนา iOS Application ด้วย iOS 5 SDK & Xcode 4.2

หลังจากนี้จะมี Training ระดับ intermediate และ advanced แบบเจาะเฉพาะเรื่องมาเรื่อยๆ ครับ เช่น Data Persistent & Core Data, Web Services, Core Image, Social Network Applications เรื่องละ 1-2 วัน คอยติดตามนะครับ แต่สำหรับแต่ละเรื่องพวกนี้จะไม่ลงพื้นฐานแล้ว จะเจาะเข้าเรื่องเลย เพราะว่าผมไม่อยากทำ Training แบบกว้างๆ เรื่อยๆ แต่ไม่ได้อะไรแบบลงลึกเท่าไหร่

สำหรับคอร์สนี้ ลงทะเบียนได้ในลิงค์ข้างบนครับ

ชี้แจง: “คู่มือเขียน iPhone App”

หนังสือเล่มแรกของผม “คู่มือเขียน iPhone App” ก็ได้ออกวางตลาดเรียบร้อยแล้ว ก็หวังว่าจะช่วยเป็นจุดเริ่มต้นเล็กๆ น้อยๆ สำหรับหลายๆ คนที่อยากจะหัดเขียนโปรแกรม หรือแอพ เพื่อใช้งาน iPhone, iPad, iPod touch กันได้บ้าง


iphoneapps.gif

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

บางครั้งที่ผู้อ่านหลายท่าน พิมพ์โค้ดตามหนังสือ และเกิด Error หรือ Warning ขึ้นมา ทั้งๆ ที่พิมพ์ตามตรงเป๊ะทุกตัวอักษรแล้ว และเมื่อเกิดเรื่องเช่นนั้นขึ้น บางครั้งผู้อ่านบางท่าน อาจจะเริ่มทึกทักว่าหนังสือผมผิด หรือหนังสือผมลืมโน่นลืมนี่ ฯลฯ

ผมขอชี้แจงอะไรบางอย่างตรงนี้ครับ โดยอ้างอิงตัวอย่างจาก e-mail ที่ผมตอบผู้อ่านผมบางท่าน (ขอสงวนชื่อผู้อ่านนะครับ ว่าผมตอบใคร)

กรณีแรก ผู้อ่านประสพปัญหาจากโค้ดในหน้า 157

การวางตำแหน่งต่างๆ ต้องประมวลความรู้เองจากหน้า 121 ครับ ผมเขียนว่า

“ก่อนจะใช้งานสิ่งใดๆ ต้องประกาศสิ่งนั้นก่อน” ดังนั้น …. (พร้อมกับบอกวิธี)

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

ลำดับ Code ที่ปรากฏในหนังสือ สะท้อนลำดับความคิดของผมครับ ไม่ได้สะท้อนลำดับของโค้ดในไฟล์
การที่ผมเขียน Code หนึ่งๆ ทีหลัง ไม่ได้แปลว่าจะต้องปรากฏภายหลังในไฟล์ครับ เราอาจต้อง
ใส่ Interface ของมันไปก่อนใน .h หรือว่าอาจจะต้องเขียน private interface เสียก่อน หรือว่าอาจจะใช้
วิธีการประกาศไว้ก่อน ก็ได้

กรณีที่สอง ผู้อ่านประสพปัญหาจากโค้ดในหน้า 78

Code ที่คุณเขียน และบอกว่ามีปัญหา อยู่ในหนังสือหน้า 78 นะครับ

ลองย้อนไปอ่านดูในหน้า 64 ครับ ตั้งแต่บรรทัดแรกเลย ว่าผมเขียนว่าอะไร และผมมีตัวอย่างให้ดูแล้วด้วย (เรื่อง @synthesize)
ซึ่งจะว่าไป ก็สืบมาตั้งแต่ขั้นตอนการเขียนที่บอกไว้ตั้งแต่หน้า 59 :-)

เป็นความตั้งใจของผมครับ ที่ผู้อ่านจะต้อง “นำความรู้ที่อ่านผ่านไปแล้ว และเห็นตัวอย่างไปแล้ว มาประมวลใช้เอง”

ทีนี้คงจะไม่มีทางลืม @synthesize สิ่งที่กำหนด @property เลยสินะครับ ดีกว่าให้พิมพ์ตามๆ ไปอย่างไม่รู้เรื่องอะไร
เพราะว่ามีหลายคนที่เคยเจอมา อ่านหนังสือไม่ละเอียด ไม่คิด จะดูแต่ code อย่างเดียว และพิมพ์ตามอย่างเดียว
ถ้า code ทำงานได้หมด ไม่เจอปัญหาจากการอ่านไม่ละเอียดและไม่คิดเลย ก็จะ take everything for a grant
(ขออภัย นึกภาษาไทยไม่ออก … ประมาณว่า มองข้ามโน่นนี่ นึกว่าเป็นเรื่องเล็กๆ) ทำให้แก้ปัญหาต่างๆ ไม่ได้ในที่สุด

สิ่งที่คุณเจอ และการแก้ปัญหาของคุณ เป็นเจตนาของผมทีี่อยากให้เกิดขึ้นครับ

มาถูกทางแล้วครับ ยินดีด้วย

ดังนั้น เพื่อ Make Statement ให้ชัดเจนตรงนี้ ผมขอบอกอีกครั้งนะครับ (ซึ่งเป็นการเขียนซ้ำข้อความที่ผมเขียนไว้ในหน้า 14 ของหนังสือ ซึ่งหลายท่านอาจจะอ่านข้ามไปแบบไม่สนใจเท่าไหร่)

หนังสือเล่มนี้จะไม่มี “การรวมโค้ด” ของโปรแกรมเอาไว้ที่หน้าใดหน้าหนึ่ง ให้พิมพ์ตามหรือลอกเฉพาะส่วนของโค้ดได้ โดยไม่อ่านเนื้อหาและความคิดอันเป็นที่มาของโค้ด

นอกจากนี้ โค้ดหลายส่วนที่ซ้ำหรือคล้ายกับที่เคยผ่านมือกันมาแล้ว บางส่วนผู้อ่านจะต้องเขียนเพิ่มเติมเอง

ผมไม่ปฏิเสธครับ ว่าลักษณะการเขียนหนังสือของผมนั้น ได้รับอิทธิพลจากหนังสือต่างประเทศ ทั้งอเมริกาและญี่ปุ่น เป็นอย่างมาก

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

หลายต่อหลายคน หัดเขียนโปรแกรมตามตัวอย่าง คอมไพล์ผ่าน ทำงานได้ ตามตัวอย่างเป๊ะๆ ก็หลงระเริง คิดว่าเข้าใจแล้ว ทำได้แล้ว พอเขียนจริง ต่อให้เป็นโปรแกรมง่ายๆ ไม่ต้องยาก (แค่เปิดไฟล์ นับคำในไฟล์ว่ามีกี่คำ ที่ผมชอบใช้เวลาสอนหนังสือที่ ม.ศิลปากร) ก็เริ่มต้นไม่ถูก พอเขียนแล้วเจอปัญหาเล็กน้อย ก็ไปต่อไม่เป็น เจอข้อความจาก Compiler ก็กลัว ฯลฯ

ขอให้ค่อยๆ พยายามๆ ครับ อ่านหนังสือให้ละเอียด ใช้เวลากับมันให้มากสักนิด เพื่อรากฐานที่มั่นคง

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

และ … คาดเข็มขัดนิรภัยให้แน่นนะครับ เพราะว่าเมื่อพื้นฐานของทุกคนแน่นแล้ว “เล่ม 2” จะเร็วกว่านี้ หนักกว่านี้ ยากกว่านี้ แน่นอน เพราะจะเป็นสิ่งที่ผมทิ้งท้ายไว้ในบทสุดท้าย (บทที่ 16) แต่ถ้าไม่มีสิ่งที่เป็นความรู้ “ระดับสูงขึ้นไป” เลยล่ะก็ การเขียน App หลายตัวสำหรับ AppStore ปัจจุบันนั้นทำไม่ได้แน่นอนครับ

iOS หรือ Android?

เร็วๆ นี้ผมไปบรรยายเรื่อง Mobile Application Development ให้กับแลบ MSCIM ซึ่งก็มีคำถามน่าสนใจ ว่าจะทำบน iOS หรือ Android ดี

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

มันก็เลยมีคำถามน่าสนใจตามมาว่า “งั้นจะซื้อ iOS หรือ Android แพลตฟอร์มดี?” เพื่อให้ตัวเองได้เริ่มต้นเป็น “ผู้ใช้” และ “เพื่อทำความคุ้นเคยกับแพลตฟอร์มสำหรับพัฒนา app ต่อ” ได้

ผมมีข้อคิดแบบนี้ก็แล้วกัน

  • เขียน app ลง iOS จริงๆ มันต้องทำบน Mac ด้วย ดังนั้นถ้าไม่มี Mac หรือไม่ได้วางแผนจะซื้อ Mac ภาษีสำหรับการคิดจะซื้อ iOS แพลตฟอร์มมาเพื่อพัฒนาโปรแกรม ก็ลดน้อยลงไปด้วย (แต่ใช้ VMWare ก็ได้นะ แต่ผมเองก็ไม่เคยใช้ Xcode บน OS X บน VMWare สำหรับการพัฒนาลงเครื่องเหมือนกัน)
  • เช่นเดียวกัน (แต่ตรงกันข้าม) เท่าที่ผมทราบนะ เครื่องไม้เครื่องมือสำหรับพัฒนา Android บน Mac มันค่อนข้างจะสู้แพลตฟอร์มอื่น (เช่น Windows) ไม่ได้นะ
  • จะเอา app ลงเครื่องจริง สำหรับ iOS ต้องเสียตังค์ $99 ให้กับ Apple นะ นอกจากมหาวิทยาลัยจะมีคอร์สสอน iOS Development และ register กับ Apple (ไม่มีค่าใช้จ่าย) ก็จะให้ น.ศ. เอา app ลงเครื่องได้ แต่ขายไม่ได้ ถ้าจะขาย ก็ต้องเสียเงินเอง
  • ผมไม่มีข้อมูลเรื่องนี้สำหรับ Android
  • iOS vs Android ถ้ามองในมุมมองนักพัฒนาแล้ว มันมีข้อดีข้อเสียต่างกันนะ ในแง่ของ Hardware Diversity แล้ว iOS เหนือกว่าเยอะ เพราะว่ามันแทบไม่มี diversity … ซึ่งสำหรับนักพัฒนาที่ต้องเขียนโปรแกรม support อะไรต่ออะไรแล้ว diversity เยอะเป็นเรื่องไม่ค่อยจะดีเท่าไหร่ แค่ iPhone 3Gs กับ iPhone 4 ที่มีความละเอียดหน้าจอต่างกัน ต้องเตรียมภาพ 2 resolution ไหนละจะ iPad อีก แค่นี้ก็รำคาญแย่แล้ว
  • แต่สุดท้าย มันต้องเริ่มด้วยการเป็น “ผู้ใช้” ก่อน แล้วจะเริ่มจากการใช้อะไรดี?
  • ข้อแนะนำง่ายๆ คือ หน้าด้านไปยืนเล่นเรื่อยๆ ว่าชอบอะไรมากกว่ากัน ต่อให้มันดีแค่ไหน ถ้าใช้แล้วไม่ชอบ มันก็แค่นั้นแหละ ความชอบมันวัดแทนกันไม่ได้เสียด้วยสิ ไปยืนเล่นเลย ถ้าร้านเริ่มมองหน้า ก็เปลี่ยนร้าน
  • ลองใช้โปรแกรมพื้นฐานทั้งหลายทั้งแหล่ โทรเข้าโทรออกทำไง ดูปฏิทินทำไง เล่นเน็ตทำไง download โปรแกรมเพิ่มทำไง พอใจความเร็วมั้ย ฯลฯ เอาแค่นี้แหละ ลองสัก 1-2 สัปดาห์ ก็น่าจะรู้แล้ว ว่าชอบอะไร
  • อย่าลืมเรื่อง form factor ด้วยนะ เอาให้เหมาะมือ เอาให้ถือสบาย เพราะว่ายังไงเราก็ต้อง “ถือ” มันเวลาใช้งาน หยิบขึ้นมา ถือไว้นิ่งๆ สัก 5 นาทีเป็นอย่างน้อย ถ้ารำคาญ ก็ไม่ต้องเอา จากนั้นลองเอานิ้วโป้งลูบให้ทั่วหน้าจอ ถ้ามีส่วนไหนลูบไม่ถึง หรือว่าฝืนมือ ก็ไม่ต้องเอา เพราะว่านี่คือการใช้งานพื้นฐาน ว่างั้น
  • อย่าลืมคิดถึงเรื่องคุณภาพของ app ไว้ด้วยนะ จิตใต้สำนึกของผมมันบอกว่า iOS app บน AppStore จะมีคุณภาพ “โดยเฉลี่ย” และมีความ consistency ในเรื่องการใช้งานมากกว่า Android app บน Market ด้วยเหตุผลเรื่อง “ความเปิด” ของการให้นำ app ขึ้น store ดังนั้นมองจากมุมของ “คนที่ต้องเรียนรู้ลักษณะของ app” (ย้ำนะ จากมุมนี้เท่านั้น ไม่ใช่จากมุมมองของ consumer ทั่วไป) แล้ว iOS มีภาษีดีกว่ามาก
  • อย่ารอรุ่นใหม่มากนัก เพราะว่าต้องรอต่อไปเรื่อยๆ เล่นก่อนก็ได้เรียนรู้ก่อน

ประมาณนี้แหละ หวังว่าจะเป็นประโยชน์บ้างนะครับ

ป.ล. บรรยายโคตรสนุก สนุกมากๆ

Update 1: ที่สำคัญนะครับ อย่ามัวแต่เถียงกัน หรือก่อสงครามว่าอะไรดีกว่ากัน มือถือที่ดีที่สุด คือมือถือที่เราชอบที่สุด ใช้ประโยชน์ได้สูงสุด อย่าเอา spec มาเถียงกัน อย่าฉะกันว่าไอ้นั่นไม่มีนี่ ไอ้นี่ไม่มีนั่น ตัวเองคิดว่าอะไรดี ก็ไม่ต้องไปบอกให้คนที่ไม่เห็นด้วยเขาเห็นด้วย ถึงจะเถียงชนะ คุณก็ไม่ได้เงินหรือว่าเครดิตอะไรจากทั้ง Apple ทั้ง Google อยู่ดี ทำประโยชน์อะไรให้ชาวโลกก็ไม่ได้ เสียเวลาเปล่าๆ เอาเวลาทำแบบนั้น ไปนั่งหัดเล่น หัดเขียน app ดีกว่า อาจจะได้เงินใช้บ้าง ได้ทำประโยชน์จริงๆ ให้คนที่อยากใช้ app เราบ้าง