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

“การเขียนโปรแกรม”​ มันเป็นเรื่อง “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”) โดยดัดแปลงให้เหมาะกับการเป็นบทความบนเว็บ

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

ใจจริงผมอยากจะเขียนให้อิงกับ 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 แล้วเจอเครื่องมือใหม่มีปัญหา โดยเอาออกมาให้อ่านก่อนแบบฟรีๆ ทุกคน ไม่ว่าจะเป็นผู้อ่านเล่มแรกของผมหรือไม่ก็ตาม ดังนี้

• บทที่ 3: การโปรแกรมที่เปลี่ยนไปของ Objective-C จากอดีตถึงปัจจุบัน ซึ่งจะเน้นหนักไปที่เรื่อง Automatic Reference Counting (ARC) ซึ่งทำให้หลายต่อหลายคนงง ในเรื่องการเขียนโค้ด
• บทที่ 4: ปฏิวัติการออกแบบและสร้างโปรแกรมด้วย Storyboard เป็นการใช้เครื่องมือในการออกแบบโปรแกรมตัวใหม่ คือ Storyboard ซึ่งมาช่วย/มาแทน Interface Builder ของดั้งเดิม
• บทที่ 5: ลูกเล่น & แม่ไม้ ในการสร้าง Table View เป็นการใช้ Storyboard ในการสร้าง Table View และ Navigation-based Application พร้อมเครื่องใหม่ในการทำ Cell Prototyping และ Static Cell

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

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

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

พัฒนา 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 แบบกว้างๆ เรื่อยๆ แต่ไม่ได้อะไรแบบลงลึกเท่าไหร่

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

หลังจากหนังสือเล่มนี้วางตลาดไปได้ไม่นาน ก็มี 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 ปัจจุบันนั้นทำไม่ได้แน่นอนครับ

ส่วนหนึ่งก็มาจากความเห็นส่วนตัวของผมเอง ว่าอย่าไปสนใจข้อมูลเชิงการตลาด หรือสถิติทั้งหลาย ว่าใครขายดีกว่ากัน แพลตฟอร์มไหนโตเร็วกว่ากัน มากมายนัก อย่าไปสนใจ 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 เราบ้าง

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

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

ลองแบ่ง phase การทำงานเป็นแบบนี้ครับ

1. นั่งคิดคร่าวๆ ว่าโปรแกรมจะมีการใช้งานอย่างไร ต้องทำอะไรได้บ้าง ไม่ต้องมากไม่ต้องมาย
2. จากนั้นนั่ง list มันออกมาเล่นๆ ว่าจะทำแบบนั้นได้นี่ ภายในโปรแกรมจะต้องมีความสามารถอะไรบ้าง (ไม่ใช่ความสามารถที่ผู้ใช้งานจะได้ใช้นะ หมายถึงว่าต้องเขียนให้มันทำอะไรได้บ้าง)
3. ดูว่าอะไรที่เราทำเป็นแล้ว อะไรที่ยังทำไม่เป็น checklist ง่ายๆ
4. เปิดโปรเจคใหม่หลายๆ โปรเจค ตามเรื่องที่เรายังทำไม่เป็น หัดเล่นเป็นเรื่องๆ ไป เล่นโน่นเล่นนี่ เล่นให้มันพังไปเลยก็ได้ ไม่เป็นไร เพราะว่านี่คือการลองเล่นกับโปรเจคที่ไม่เกี่ยวกับงานเราสักนิด จะเขียนโค้ดให้มันเละแค่ไหนก็ได้ อีกสามสี่วันอ่านไม่รู้เรื่องก็ได้ ไม่ต้องมีโครงสร้างอะไรมากมาย ลุยมันไปเลยไม่ต้องคิดมาก
5. แต่ว่าเป้าหมายของโปรเจคเล็กๆ ที่เปิดใหม่เหล่านั้นต้องชัดเจนนะ ว่าจะเรียนรู้เรื่องอะไร กำหนดเวลาให้ตัวเองไว้ด้วย กำหนดผลลัพธ์ที่ชัดเจนไว้ด้วย
6. เมื่อ checklist เต็มแล้ว (คือ ทุกตัวทำเป็นหมดแล้ว) ค่อยมาวาง architect ของโปรแกรม/โปรเจคที่อยากได้ ว่าจะออกมายังไง เพราะว่าตอนนี้เราน่าจะมีประสบการณ์แล้วว่าอะไรมันทำได้ทำไม่ได้ อะไรมันต้องทำงานร่วมกับอะไรยังไง รับค่าอะไร รีเทิร์นอะไร ประสิทธิภาพเป็นยังไง ฯลฯ

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

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

เสียน้อย (เปิดโปรเจคใหม่ เรียนรู้มันทีละเรื่อง) มันเสียยาก แต่เสียมาก (โค้ดในโปรเจคมั่ว โปรเจคไม่มีโครงสร้างแก่น เป็นแบบปะผุ ฯลฯ) มันเสียง่าย นะครับ

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

คำตอบคือ “ส่ง crash log ให้เค้าด้วย” … แล้วไอ้ crash log ที่ว่านี่ อยู่ตรงไหนล่ะ?

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

สำหรับโปรแกรม iPhone, iPod touch, iPad นั้น ปกติแล้วเครื่องจะเก็บ log ไว้ตลอดเวลา และเมื่อเรา sync เครื่องกับ iTunes นั้น log เหล่านี้ก็จะถูก sync ลงเครื่องด้วย โดยจะอยู่ในที่ต่อไปนี้ครับ:

1. บน Mac:

   ~/Library/Logs/CrashReporter/MobileDevice/ชื่อไอโฟน/

2. บน Windows XP:

   C:\Documents and Settings\\Application Data\Apple computer\Logs\CrashReporter\ชื่อไอโฟน\

3. บน Windows VISTA:

   C:\Users\\AppData\Roaming\Apple computer\Logs\CrashReporter\MobileDevice\ชื่อไอโฟน\

Crash log จะถูกเก็บอยู่ในนั้นครับ โดยให้สังเกตนิดหน่อย ว่าถ้ามี folder (directories) ชื่อ “ชื่อไอโฟน” กับ “ชื่อไอโฟน.symbolicated” ล่ะก็ ให้เลือก .symbolicated นะครับ มันจะมีข้อมูลที่เป็นประโยชน์กับนักพัฒนาที่มากกว่าใน folder “ชื่อไอโฟน” เฉยๆ

สำหรับรูปแบบของ Crash log จะถูกเก็บในไฟล์รูปแบบนี้: ชื่อapp_วันเวลา_ชื่อเครื่อง.crash เช่น PetdoComics_2010-09-04-175745_Rawitats-iPhone-4.crash หรือ TwitterFonPro_2010-08-30-103513_Rawitats-iPhone-4.crash เป็นต้น (ข้อมูลจริงจากบนเครื่องผม)

ตัวอย่างครับ

• รูปแสดงตัวอย่างที่อยู่และตำแหน่งของ crash log (บน Mac OS X)

  

• การเปิด crash log ดู จะเห็นข้อมูลที่เป็นประโยชน์กับผู้พัฒนา เช่นโปรแกรมมัน crash เมื่อเรียกอะไรขึ้นมาทำงาน ขณะนั้นมีอะไรทำงานอยู่บ้าง ฯลฯ (ตัวอย่างของ Echofon)

  

ดังนั้น สำหรับ App ผมทุกตัว ส่งมาได้นะครับ contact อยู่ในหน้า App ของ iTunes อยู่แล้ว :-D

เป้าหมายง่ายๆ คือ “ต้องไม่ช้ากว่าหรือลำบากกว่าการหยิบกระดาษขึ้นมาจดๆๆ” ดังนั้นฟีเจอร์อะไรก็ตาม ที่จะทำให้มันไม่บรรลุเป้าหมายนี้ (พวกที่โดยส่วนตัวผมคิดว่าเป็น Nice to have แต่อาจจะใช้บ้างไม่ใช้บ้าง) ผมหั่นทิ้งเรียบ และโฟกัสกับการทำยังไงก็ได้ ให้มันไม่ช้ากว่า ลำบากกว่าการดึงกระดาษขึ้นมาจด …​ ต้องดึงมาใช้งานและเก็บลงกระเป๋าได้ในเวลาน้อยที่สุดเท่าที่จะทำได้ … ผมคิดว่า ถ้าต้องการฟีเจอร์ที่ผมตัดทิ้งไปเหล่านั้น มีทางเลือกอีกเยอะมาก ใน App Store ครับ

Screenshot จาก iTunes App Store

โปรแกรมมี 2 รุ่นครับ คือ รุ่นจ่ายเงิน ($0.99) และ รุ่นฟรี ซึ่งจะจำกัด Favorite Items ไว้ที่ 10 items และใช้ iAd support (แต่ไม่มีผลกับ account ประเทศไทย เพราะ iAd ยังมาไม่ถึง ถ้าไม่ใช่ account อเมริกา ก็ไม่มี Ad โผล่มา) และสุดท้าย ต่างกันที่ไอคอน รุ่นจ่ายเงินเป็นสีดำ Metallic ออกแบบโดยใช้ Theme แบบ MacBook Pro ส่วนรุ่นฟรี เป็นสีขาวเรียบๆ แบบ MacBook

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

ล่าสุด โปรแกรมนี้ถูกรีวิวโดย AppDiscover Blog ใน entry Buying List by Rawitat Pulam ครับ ขอ Quote ไว้ตรงนี้ด้วยก็แล้วกัน

Buying List is a sweet little list building app for the iphone by Rawitat Pulam. It allows you to manage items you wish to buy now and in the future efficiently with two simple lists, your shopping history, and a customizable list of favorites.

Once you learn Buying List’s interface, it’s a joy to use. There are four tabs at the bottom: buying now, buy later, history, and favorites. Here’s how it works:

You can add items directly to the buying now or buy later list. Tap any item on the buying now list once you’ve purchased it. When you’ve completed your shopping, press the new list button and the items you’ve purchased are moved to the history along with the date you purchased them. Any items that you have not purchased are automatically moved to your buy later list.

From the buy later list, selecting a few items and pressing the new list button adds them to your current buy now list.

Additionally, any item on your lists can be added to your favorites by tapping a star icon. Your favorites list functions much like the buy later list. Tap a few items, hit new list, and they’re added to your current buy now list.

The interface is a bit complicated to describe, but once you get used to it you can quickly build manageable lists from a large set of items you need to buy. If you are a shopping list person, I would highly recommend it. The free version allows only 10 favorites. Get the full version for $0.99

แต่ว่าดูนี่ซะก่อน

อ่านได้ชัดเจน สวยงามมาก … ตอนที่ผมพิมพ์ตอนแรก อึ้งไปสามสิบวินาที ก่อนจะร้อง “เฮ้ย จะบ้าเรอะ!” แบบไม่เกรงใจคนรอบข้าง .. ไม่ทราบว่าท่านไปจ้างโปรแกรมเมอร์ที่ไหน ทำในงบประมาณหลักกี่ล้านครับท่าน? ยังไม่พอนะครับ ข้างล่าง ผมยังพบสิ่งนี้

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

ผู้ถาม: อาจารย์เว็บแบบไหนที่แตกต่างๆ
ผู้ถาม: ขอคำแนะนำหน่อยนะคะ
ผู้ถาม: พอดีเพื่อนเขียนเว็บให้บริษัทน่ะ
ผม: แล้วทำไมต้องแตกต่าง?
ผู้ถาม: แต่ไม่อยากจำเจอยู่กับรูปแบบเดิมๆๆ
ผม: มาอีกล่ะ พวกทำงานเอารูปแบบเป็นหลัก จะรูปแบบเก่า รูปแบบใหม่ ถ้าไม่ได้วิเคราะห์เรื่อง function และ usage เป็นหลัก มันจะทำได้ไง
ผู้ถาม: แต่คือว่าเขาแค่ตอ้งการดีไซต์และส่วนเรือ่งนั้นเขาคงทำเองอ่ะ
ผู้ถาม: ก้อแค่ออกแบบอะ
ผม: เว็บไซต์ไม่สามารถ design หน้าตาได้ หากไม่ design function ครับ
ผม: มันเหมือนกับคุณอยากจะออกแบบ “หน้าตา” ของรถยนต์ โดยไม่กำหนดว่า รถคันนี้ จะต้องวิ่งในที่แบบไหน บรรทุกอะไร กลุ่มเป้าหมายคืออะไร
ผม: คุณอาจจะคิดว่า หน้าตารถสปอร์ตมันเท่ห์ดี
ผม: แต่รถตู้ที่ออกแบบโดยใช้ concept รถสปอร์ต มีแต่ห่วยกับห่วย
ผม: ว่างั้นเถอะ
ผม: ไม่ได้กวนตีนหรือหลบเลี่ยงในการตอบ แต่ด้วยจรรยาบรรณ ไม่สามารถออกแบบเฉพาะหน้าตาได้ครับ หากคุณเคารพวิชาชีพตัวเอง ในฐานะนักออกแบบเว็บไซต์
ผู้ถาม: แต่มานก้อเปงส่วนหนึ่งหนิ
ผม: ลำดับก่อนหลังมีผลครับ
ผม: เอางี้ ผมให้คุณเลือกชุด จะพาออกงาน คุณจะเลือกชุดอะไร? ยังไง?
ผู้ถาม: ก้อต้องดูงานก่อนค่ะ
ผม: ใช่มั้ย
ผม: คุณต้องทราบว่า “งานอะไร แขกที่จะต้องไปพบ เป็นคนระดับไหน ต้องดู look เป็นยังไง ฯลฯ” ใช่มั้ย
ผม: ก็แบบเดียวกับการออกแบบเว็บไซต์น่ะแหละครับ
ผู้ถาม: แต่งานนี้เปงวัตถุดิบทางอุตสาหกรรม
ผู้ถาม: แต่ลูกค้าบอกว่าไม่อยากให้ธุรกิจมากเกิน
ผม: ถามคนอื่นเถอะครับ
ผม: คนที่ไม่ได้มีมาตรฐานในการทำงาน และมีจรรยาบรรณในการักษามาตรฐาน มีเยอะครับ
ผู้ถาม: ค่ะ
ผม: เหมือนสร้างตึกครับ ถ้าผมเป็นนักออกแบบ สถาปนิก ผมคงไม่สามารถบอกได้ว่า “ตึกนี้สวย ตึกนี้สวย ตึกนี้แปลก เอาแบบนี้ ผสมกับแบบนี้ ผสมกับแบบนี้ ฯลฯ” โดยไม่ดูว่า “แล้วมันเป็นตึกอะไรวะ ใครจะอยู่วะ เอาไปทำอะไรวะ คนเดินเข้าออกเยอะมั้ยวะ ฯลฯ”
ผม: สุดท้าย คุณอาจจะได้ตึกที่สวย แปลก เฉี่ยว แต่ใช้งานไม่ได้จริง
ผม: ตัวอย่างนี้มีให้เห็นตามเว็บไซต์ทั่วไปครับ
ผม: สวย แปลก ดูครั้งแรกแล้ว “ว้าว!” แต่ขอโทษนะครับ ไม่สามารถใช้งานได้จริงตามที่มันควรจะใช้งานได้
ผู้ถาม: ช่ายค่ะ
ผู้ถาม: พอเข้าใจและ
ผม: ขออนุญาตเอาการสนทนานี้ ไปลง blog และสอนหนังสือนะครับ เป็นตัวอย่างแนวคิดและทัศนคติหนึ่ง ที่พบเห็นได้ตามสังคมทั่วไป
ผู้ถาม: ขอบคุงค่ะ
ผู้ถาม: แป่ว
ผู้ถาม: ตามบาายคะ
ผู้ถาม: ก้อคิดไม่ออก
ผู้ถาม: เพราะยึดติดแต่สิ่งที่แตกต่างอ่ะคะ

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