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

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

Link: “รวิทัต ภู่หลำ” เผยเคล็ด สร้างซอฟต์แวร์ต้องลงมือ “ทำ” (กรุงเทพธุรกิจ)

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

แต่มีประเด็นสุดท้าย ที่เกี่ยวข้องกับ Silicon Valley ที่ผมคงต้องขอขยายความเพิ่มอีกนิด ว่าทำไมผมถึงต้องพูดถึงมันในการสัมภาษณ์นั้นด้วย

เพื่อให้เข้าใจง่ายๆ ผมขอย้อนกลับไปตอนที่ผมเคยให้สัมภาษณ์ออกรายการ “แบไต๋” เมื่อวันอาทิตย์ที่ 25 กันยายน ที่ผ่านมา ว่าจริงๆ แล้วในวงการพัฒนาโปรแกรมที่โตได้และยั่งยืนนั้น มันมีองค์ประกอบสำคัญด้วยกัน 4 อย่าง คือ

1. Skill ซึ่งถ้าไม่มีแล้วมันก็ทำอะไรได้ไม่ได้ ต่อให้ฝันได้เก่งแค่ไหน เปลี่ยนมันให้เป็นความจริงไม่ได้ ก็เท่านั้น และอย่าคิดว่าไม่เห็นจำเป็นเลย แค่คิดๆ ว่าอยากได้อะไร แล้วก็ไปจ้างคนอื่นทำๆ ก็หมดเรื่อง … ถ้ากรณีแบบนี้จะเกิดเรื่องเพ็ดโด้ๆ ขึ้นมากมาย (คิดว่าต้นตอหลักๆ ของเรื่องการ์ตูนเพ็ดโด้มันมาจากไหนล่ะครับ มันเริ่มต้นมาจากคนที่อยากได้ แต่ประเมินอะไรไม่เป็นเลย ทั้งเวลา ค่าใช้จ่าย ความยากง่าย ฯลฯ ตัวอย่างเช่น เมื่อ 2-3 ปีก่อนเคยมีคนต้องการจะจ้างผมทำเว็บแบบเฟสบุ๊ค ในเวลา 3 เดือน และราคาแค่ครึ่งแสน มาแล้ว)
2. Budget ยังไงเราก็ยังต้องกินอะไรบ้าง ต้องมีความเป็นอยู่ที่พออยู่ได้บ้างตามอัตภาพ ผมไม่ได้บอกว่าเราต้องรวย แต่แค่ไม่ต้องจนถึงขนาดอยากจะกินมาม่ารสอื่นนอกจากรสที่มันถูกๆ ยังต้องคิด หรือไม่กล้าเดินเข้าร้านอาหารตามห้าง ทั้งๆ ที่เด็กมหาวิทยาลัยที่ยังแบมือขอเงินพ่อแม่เดินเข้ากันเยอะแยะ เท่านั้นไม่พอ ค่าหนังสือ ค่า Video Screencast ดีๆ ค่าอุปกรณ์ที่จะใช้ในการทดสอบโปรแกรม ค่าการ “ขยายทีม” (สำคัญนะครับ … พูดง่ายๆ ก็เงินเดือนเพื่อนร่วมงาน)
3. Marketing ต่อให้ทำโปรแกรมเจ๋งๆ มาเยอะแค่ไหน โปรแกรมที่คนไม่รู้จัก ก็คือโปรแกรมที่คนไม่ซื้อ ผมพูดถูกมั้ยล่ะ ดังนั้นจะให้คนรู้จักได้ยังไง การทำ Marketing เป็นเรื่องสำคัญ และจริงๆ แล้วมันก็เกี่ยวข้องกับเรื่อง Budget ด้วยน่ะแหละ ตอนนี้บอกตรงๆ ว่าผมยังว่าจะต้องจ้างทำการตลาดให้กับ App บางตัวของผมบ้างแล้วเลย สิ่งนี้จะส่งผลโดยตรงกับเรื่อง Budget ด้วย
4. Community (และ Environment) เรื่องนี้ “สำคัญที่สุด” ในบรรดาทั้ง 4 เรื่อง ในการจะทำอะไร “สภาพแวดล้อม” ที่เอื้ออำนวยในการทำสิ่งนั้นๆ เป็นเรื่องสำคัญมาก ตัวอย่างเช่น พวกลูกหมอ หรือเด็กที่เกิดและโตในโรงพยาบาล จะมีความต้องการเป็นหมอเฉลี่ยแล้วมากกว่าเด็กอื่นๆ เป็นต้น อันนี้ผมพูดได้จากประสบการณ์ตรงของตัวเอง ว่าสภาพแวดล้อมที่มีการสร้างนวัตกรรมตลอดเวลา เป็น Open & Friendly competition คือ แต่ละคนบอกกันตลอดว่ากำลังทำอะไรอยู่ สิ่งที่แต่ละคนทำ มันเสริมกัน มันคล้ายกัน มันต่างกัน อะไรใช้ด้วยกันได้ อะไรที่เปิด source ให้ช่วยกันพัฒนา อะไรที่ ฯลฯ และเมื่อต่างคนต่างทำได้ ต่างคนต่างเรียนรู้ ก็นัดกันมาทำ Conference ปล่อยของ และสร้าง Partnership ใหม่ ตลอดเวลา เป็นสิ่งที่ผม “คุ้นเคยมาก ที่ญี่ปุ่น” และเป็นสิ่งที่ผมไม่ค่อยจะเห็นเท่าไหร่เลย ในบ้านเรา

Link: คลิปรายการแบไต๋ ผมออกตั้งแต่นาทีที่ 1:08:00​ โดยประมาณ เป็นต้นไป

บ้านเราสนใจแต่เรื่อง Skill ของคนเป็นหลัก “มากเกินไป” คิดว่าคนเก่ง จะอยู่ได้ สร้างสรรค์งานได้ แต่ไม่มีปัจจัยอื่นๆ ที่เอื้ออำนวยเลย โดยเฉพาะอย่างยิ่งข้อสุดท้าย คือเรื่อง Environment และ Community ซึ่งเมื่อผมพูดถึงคำว่า Community นี่ผมไม่ได้หมายถึง การที่เราแค่รู้จักกัน หรือมีรายชื่อ และมีการพบปะกันนานๆ ครั้ง หรือเกาะกันแบบหลวมๆ แบบบ้านเรา และปกติก็ต่างคนต่างอยู่กันอยู่ดี แต่ผมกำลังพูดถึง Virtual Learning Organization ของคนที่ทำงานด้านเดียวกัน ใน Environment ที่เอื้อการสร้างสรรค์ แบบ Open & Friendly.

ผมพูดถึง Silicon Valley เพราะมันเป็นตัวอย่างในการมีสิ่งเหล่านี้ครบ ตั้งใจพูดถึงปัจจัยอีก 3 ตัว (เรื่อง Budget จะเป็นเรื่องของ Venture Capital) ว่าบ้านเราขาดอะไรไปบ้าง และคงเป็นความฝันของคนทำงานด้านนี้ ที่จะไปสัมผัส Community & Environment ที่นั่นสักครั้ง …​ เหมือนกับคนทำงานด้านแฟชั่น คงจะไม่ได้อะไร หากจะเป็นแต่คนเก่งอยู่ใน “กรุงเทพเมืองแฟชั่น” (ตั้งใจประชด) แต่ไม่เคยสัมผัสงานในมิลานเลยสักครั้ง อะไรทำนองนี้แหละครับ

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

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

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

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

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

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

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

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

เนื้อหาคร่าวๆ ในวิชานี้ ผมไม่ได้ต้องการเพียงแค่ว่าหลักการในการออกแบบ User Interface เท่านั้น แต่จะรวมถึงการพัฒนาซอฟต์แวร์ ระบบ ตั้งแต่ขั้นตอนการเก็บ requirement เพื่อให้ได้มาซึ่ง User Experience (UX​) ที่ดี และการนำความรู้เรื่องอื่นๆ ไม่ว่าจะเป็นหลักการ 80:20 หลักการทำงานของสมองเพื่อให้ได้มาซึ่ง creativity การสร้าง innovation การศึกษาและระบุตลาดของซอฟต์แวร์ และความสร้างความสามารถในการแข่งขันโดยให้ User Interface, User Experience ที่เหนือกว่า เรื่องต่างๆ จาก Game Theory (เช่น Prisoner’s Dilemma) เป็นต้น

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

ป.ล. เสียงอาจจะมาช้านะครับ อาจจะต้องรอมัน stream เสียงนิดนึง ส่วนภาพคงไม่มีปัญหา เพราะจากที่สังเกต ทาง Livescribe ใช้วิธีการสร้างจาก coordinate data (x, y, t) ส่วนเสียงนี่เป็น audio streaming ธรรมดา

หมายเหตุ มีการแจ้งว่า กด play บนนี้แล้วเล่นไม่ได้ ไปเล่นบนหน้าเว็บของ livescribe เองก็ไม่มีเสียง …​ ผมเข้าใจว่าพอกด play ไปแล้ว มันจะเริ่ม download ไฟล์เสียงครับ ซึ่งจะใช้เวลาหน่อย ในกรณีที่ไฟล์เสียงมันใหญ่ การ streaming ของเสียงอาจจะไม่ดีพอครับ คิดว่าใช้การ download ทั้งไฟล์ ขออภัยในความไม่สะดวกครับ จะติดต่อกับทาง livescribe เพื่อบอกปัญหานี้ต่อไปครับ …. กด play แล้วรบกวน “อดทนรอ” หน่อยนะครับ

• UI class 6.14 1: Changes and Revolution of Industry
  brought to you by Livescribe
  
• UI class 6.14 2: How we think and process information?
  brought to you by Livescribe
  
• UI class 6.14 3: Work on things that matter
  brought to you by Livescribe
  

ส่วนนี่คือ PDF ที่ export มาจากที่เขียนครับครับ

• ส่วนที่ 1: Changes and Revolution of Industry
• ส่วนที่ 2: How we think and process information?
• ส่วนที่ 3: Work on things that matter

หวังว่าคงเป็นประโยชน์นะครับ ฟังเล่นเพลินๆ ละกันนะครับ

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

อืมมมมมม เห็นด้วยแฮะ

ก่อนจะพูดต่อไป ขอพูดถึงตัวเองหน่อย ….. ผมอาจจะโชคดีพอ ที่เกิดมาทันสมัย DOS (เครื่องแรกในชีวิต ที่ตั้งที่บ้าน ใช้งาน DOS 5.0 — ไม่มีเมาส์ด้วยซ้ำไป) ทำให้การทำงานกับ command line เป็นอะไรที่เป็นเรื่องปกติ รู้สึก at home กับมันมาก อยากจะให้มันทำอะไร ก็สั่งมันตรงๆ เป็นคำสั่งๆ ไป และแต่ละคำสั่งก็จะมี option อะไรก็ว่าไป ไม่พอ กว่าจะเล่นเกมได้แต่ละเกมๆ ก็ต้องแก้ config.sys, autoexec.bat กันวุ่นวาย ถึงขนาดต้องเขียน batch file เอาไว้เปลี่ยนสองไฟล์นี้เอง ด้วยความรำคาญ

พอชีวิตเริ่มเจอ GUI มากขึ้น ไม่ว่าจะเป็น Windows 3.x, Windows 95 ก็ได้ทุนไปเรียนญี่ปุ่น ก็พอเดินเข้าห้องคอมพิวเตอร์วันแรก ก็เจอ SGI IRIX เจอ GUI แบบไม่เคยเจอมาก่อน และต้องทำงานกับ Shell บน terminal emulator (ถ้าจำไม่ผิด รู้สึกว่าจะเป็น tcsh) ทำทุกอย่างบนนั้นหมด เหมือนกับเปลี่ยนโลกไปเยอะ จากนั้นเพื่อนๆ สนิทๆ กัน (Peter Suranyi, Janos Gyerik) ก็ยุให้เล่น Linux ก็เลยหามาลง ซึ่งก็กว่าจะหาทางทำให้ X-Windows มันทำงานได้ กว่าจะฯลฯ ได้ ก็แทบแย่

ประเด็นคือ การอยู่กับ terminal หรือ command prompt ทุกชนิดของผม ทำให้ผมมองการใช้งานคอมพิวเตอร์ เป็น “บทสนทนา” ระหว่างผมเอง กับคอมพิวเตอร์ ไม่ว่าผมจะใช้โปรแกรมอะไรก็ตามที่สามารถใช้งานในลักษณะ terminal ได้ จะเป็น MySQL, Octave, R หรือว่าโปรแกรมที่เป็น command line-based เช่น imagemagick ที่เอามาประกอบกับ shell scripting ได้ หรือว่า interactive programming environment ต่างๆ เช่น IRB, Python, Scheme, Haskell

กลับมาถึงบทสนทนาระหว่างผมกับคุณพ่อ

คุณพ่อผม เป็นนักปรับปรุงพันธ์พืช ที่ใช้ dBase 3 Plus ในการเก็บข้อมูล มานานมาก และเขียนโปรแกรมใช้งานเอง เริ่มจากใช้งานฐานข้อมูลนั้นๆ ทีละคำสั่งๆ แล้วก็เอาคำสั่งพวกนั้นมาต่อๆ กันเป็น routine/sub-routine และก็เริ่มซับซ้อนขึ้นเรื่อยๆ จนปัจจุบัน เป็นโปรแกรมที่มีความซับซ้อนมาก และทำงานได้ดี ช่วยงานได้เยอะมาก

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

มันเลยกลับมาถึงเรื่องที่ผมบ่นๆ ไว้บ่อยๆ เรื่องนักศึกษาในสาขาวิชาที่ต้องเรียนเขียนโปรแกรม ซึ่งพบว่า มีปัญหากับกระบวนการคิดค่อนข้างเยอะ และไม่สามารถคิดอะไรในลักษณะ “เอาคำสั่ง มาต่อกัน” หรือ chain ของ Input-Process-Output ได้เลย

ผมลองตั้งโจทย์คร่าวๆ ว่า “มีไฟล์อยู่หนึี่งไฟล์ ข้างในไฟล์มีคำอยู่เยอะ ซ้ำๆ กัน ผมอยากรู้ว่ามีคำไม่ซ้ำกันทั้งหมดกี่คำ?” (ทั้งนี้ คำทุกคำ เป็นตัวเล็กหมด และไม่มีอักขระแปลกๆ ตัวอย่างเนื้อความในไฟล์คือ this is a cat this is a bat this is a map this is a phone)

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

• เปิดไฟล์ เอาเนื้อความ
• เอาเนื้อความในไฟล์มา แยกเป็นคำๆ
• เอาคำที่ได้ มากรองเอาคำซ้ำออก
• นับคำที่เหลือ

จะเห็นว่า มันก็เป็น chain ของ I-P-O อยู่ชัดเจนนะ คือ สมมติว่ามันเป็นฟังคชัน f, g, h, i ตามลำดับ ก็จะได้ว่าคำตอบของมันก็คือ i(h(g(f(x)))) … เขียนให้มันง่ายๆ กว่านี้หน่อย สมมติว่าเป็นฟังคชันชื่อ readfile, splitwords, unique_element, count ตามลำดับ ก็เป็น count(unique_element(splitwords(readfile(“filename”)))) ใช่มั้่ย จากนั้นก็แค่เอาไปดูว่า แต่ละภาษาหรือ environment เนี่ย เอามาทำแบบนี้ยังไงดี มีฟังค์ชันมั้ย ต้องเขียนเองมั้ย ถ้าจะเขียนเองจะต้องเขียนยังไง ก็แค่คิด I-P-O แบบเดิม ลงไปให้ลึกขึ้น เท่านั้น

ถ้าเขียนใน bash shell ก็คงเป็น

cat filename.txt | tr " " "\n" | sort -u | wc -w

ถ้าเป็น ruby ก็เป็น

File.read("filename.txt").split(" ").uniq.count

ถ้าเป็น haskell ก็เป็น

content <- readFile "filename.txt"
length (List.nub (words content))

ซึ่งจะซับซ้อนกว่าตัวอื่นๆ นิดหน่อย เพราะว่ามีเรื่อง IO String กับ String มาเกี่ยวข้อง (purely functional ก็แบบนี้แหละ)

แถม ... เป็น C++ ก็ยาวหน่อย (ไม่รวมพวกการ include library มาใช้นะ)

int main()
{
  ifstream fin("filename.txt");
  set<string> words;
  copy(istream_iterator<string>(fin), istream_iterator<string>(),
       inserter(words, words.begin()));
  cout << words.size() << endl;
  return 0;
}

จะเห็นว่า logic มันไม่ได้เปลี่ยนเลยสักกะนิด เพียงแต่ว่าอาจจะ verbose บ้าง รูปแบบต่างกันบ้าง คำสั่งต่างกันบ้าง

วันนั้นข้อสรุปของบทสนทนาระหว่างผมกับพ่อก็คือ Generation Click พบความลำบากมากกว่า ในการคิดสื่อสารกับคอมพิวเตอร์เป็นขั้นตอน ด้วย text ด้วยคำสั่งต่างๆ ดังนั้นอาจจะช่วยได้ หากทุกคำสั่งมันมี icon หมด และลากมาวางต่อๆ กันได้ เหมือนกับ automator.app ใน Mac OS X หรือบรรดา visual programming ทั้งหลาย

สมัยผมสอน OOP ผมเคยให้ นักศึกษาเล่นกับ Alice ซึ่งก็เป็น visual programming พอสมควร ก็พบว่าได้ผลในระดับหนึ่ง แต่ว่าพอถึงเวลาต้องไปเขียน code ซึ่งเป็น text ก็ยังพบปัญหาเดิมๆ อยู่ เทอมนี้ก็เลยขอหักดิบ ให้ใช้งาน shell มันซะเลย เผื่ออะไรๆ จะดีขึ้นมาบ้าง

ลงท้ายด้วยการเผา advisee หน่อยละกัน ... เจอพวกที่แทนที่จะคิด logic ของระบบงาน กลับคิดแต่ว่าจะต้องใช้โปรแกรมอะไร ต้องเริ่ม click ที่ปุ่มไหน แล้วจะ click ปุ่มไหนต่อ งานถึงจะเสร็จ ....​ ฮา (ไม่ออก)

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

แต่วันนี้หายหงุดหงิดแล้วล่ะ ปลงแทนดีกว่า ….. ว่าแล้วก็ไปถ่ายรูปเล่นดีกว่า ผ่อนคลาย คลายเครียดกันดีกว่า

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

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

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

เอาไอ้นี่มาใช้แล้วมีปัญหาครับ/ค่ะ

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

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

rp: ./configure: งานเป็นไงมั่งน้อง
IKE::: ก้อกำลังปั่นค่ะ
rp: ./configure: เหอๆ
IKE::: ได้ พี่คนหนึ่งช่วยสอน
rp: ./configure: ปั้นเหน่งป่ะ?
rp: ./configure: ใช่ @punneng ใน twitter หรือเปล่า
IKE::: ได้ข่าวว่ารู้จักกะอาจารย์ด้วย
IKE::: ช่ายคร๊าา
rp: ./configure: อ่อ
IKE::: พี่เค้าสอน แบบว่ายาวนานมาก
IKE::: วัน ละ 5hr ได้
IKE::: เอากาน แบบว่า รื้องานทำใหม่กานเลย
rp: ./configure: แล้วดีขึ้นมั้ย
IKE::: ไม่แงะcode เก่าแบบไม่เข้าใจ เร่ิมทำใหม่เลยน้อง ประมาณนั้น
IKE::: ดีขี้น มากมายอะคร่ะ
IKE::: เข้าใจ ตั้งแต่แรกเลย
rp: ./configure: ได้หมอนี่สอน ค่อยยังชั่วหน่อย
IKE::: รู้งี้ รู้จักพี่เค้า แต่แรกดีกว่า
rp: ./configure: เฮ้อ ก็พวกคุณมันเล่นไม่ทำความเข้าใจอะไรเลยนี่หว่า
IKE::: งานคงออกมาหรูกว่านี้เยอะ
rp: ./configure: ก็พวกคุณเล่นไม่พยายามทำความเข้าใจอะไรจริงๆ จังๆ นี่หว่า …. เล่นลอกโค้ดๆ แล้วก็มาพยายามแก้ๆ กันอย่างเดียว
IKE::: ช่ายๆๆ
IKE::: เปลี่ยนแนวคิดใหม่ด้วย
IKE::: พี่เค้า สอน ดีมากเลย สอน ให้คิดแบบที่ควรจะเป็น
rp: ./configure: ก็ดีแล้ว
rp: ./configure: ปัญหาของพวกคุณ (และเด็กทุกคนที่รู้จัก) คือ ไม่ทำความเข้าใจ ไม่พยายามทำความเข้าใจ และปฏิเสธที่จะทำความเข้าใจ ใน “แนวคิด” ใน “วิธีคิด” และใน “คอนเซปท์” ทุกคนพยายามลัดไปที่โค้ดหมด
rp: ./configure: ลอกโค้ด เอาโค้ด รันได้ แก้โน่นนี่ ปะๆๆ มันเข้าไป
rp: ./configure: อะไรแบบนั้น
rp: ./configure: ก็ดี ได้เริ่มคิดใหม่
IKE::: ค่ะ ยอมรับผิดแต่โดยดี
rp: ./configure: ดีกว่าไม่ได้เลย
IKE::: แต่พี่เค้าสอน ทุ่มเท มากอะค่ะ
IKE::: เดี๋ยววัน อาทิต นี้ ก้อ ไปให้เค้าสอน อีก
IKE::: พี่เค้าแบบว่า ไม่เน้น งานเสร็จ แต่ว่าเน้น เข้าใจในสิ่งที่ทำมากกว่า

อยากจะกราบขอบคุณ @punneng มากๆ เลย แต่คงไม่ได้เจอตัวจริงๆ กันซะที ก็เลยทำมันซะที่นี่น่ะแหละ แล้วก็อยากจะฝากสิ่งที่ผมคุยกับน้อง IKE ให้เป็นอุทาหรณ์กับน้องคนอื่นๆ ด้วยนะครับ

ว่า “อย่าลัดไปที่ coding” นะครับ มันไม่ค่อยจะช่วยอะไรคุณหรอก ถ้า paradigm ของความคิดมันเหมือนๆ เดิมที่คุณคุ้ยเคยมา ก็ดีไป แต่ว่าถ้ามันไม่ใช่แบบนั้น มันจะแย่เอาง่ายๆ และถ้ามันเป็นการแก้ไขง่ายๆ เล็กๆ น้อยๆ ก็อาจจะโอเค แต่ว่าถ้ามันเป็นเรื่องของการพัฒนาโปรแกรมขนาดใหญ่กว่านั้นขึ้นมาเมื่อไหร่เนี่ย ถ้าไม่กลับไปที่พื้นฐาน (back to basic) จะแย่เอาง่ายๆ เพราะว่ามันอาจจะทำให้อะไรหลายๆ อย่างแย่ในระยะยาวได้ง่ายๆ เลยทีเดียว

rp: ./configure: ปัญหาของพวกคุณ (และเด็กทุกคนที่รู้จัก) คือ ไม่ทำความเข้าใจ ไม่พยายามทำความเข้าใจ และปฏิเสธที่จะทำความเข้าใจ ใน “แนวคิด” ใน “วิธีคิด” และใน “คอนเซปท์” ทุกคนพยายามลัดไปที่โค้ดหมด
rp: ./configure: ลอกโค้ด เอาโค้ด รันได้ แก้โน่นนี่ ปะๆๆ มันเข้าไป

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

จริงๆ แล้วด้วยความสะดวกของเครื่องมือสมัยนี้ (ยกตัวอย่างเช่น bootstrapping method ต่างๆ ใน framework สมัยใหม่ ที่สร้างโครงของโปรแกรมพร้อมใช้งานให้เราเลย หรือว่าพวก migration tools และ version control ต่างๆ) มันช่วยให้เราทำงานขึ้น application ได้เร็วมากๆ อยู่แล้ว ดังนั้นเราควรใช้เวลากับการออกแบบดีไซน์ และคอนเซปท์มากขึ้นกว่าเดิม ไม่ว่าจะเป็นเรื่องของ entity relation ต่างๆ เรื่อง use cases ต่างๆ และเรื่องของ usability เป็นต้น และถึงเวลาที่จะต้องไปขึ้น application มันจะทำได้ง่ายและรวดเร็วมาก

สืบเนื่องเรื่องนี้นะครับ วิชา Object-Oriented Programming ที่ผมสอนเทอมนี้ ดู coding แล้ว “ห่วยบรม” ส่วนหนึ่งก็เพราะว่าผมยังไม่ได้สอนลง coding เลย ผมถือว่าผมจัดสอบส่วนของ Lab (ที่เป็น coding) เพื่อเก็บข้อมูลเบื้องต้นเท่านั้น ว่าพื้นๆ ฐานๆ ของน้องๆ ในเรื่องของการเขียน code (ที่ผมย้ำนักหนา .. ว่าเรียนคอนเซปท์ไปอย่างหนึ่งเนี่ย มันมากพอที่จะไปหัด coding เอง ซึ่งก็ดูเหมือนจะไม่ทำกันเลย) นั้นเป็นอย่างไรบ้าง

แต่ว่าเท่าที่ดูจากความเข้าใจ concept ก็ดูค่อนข้างจะดีพอสมควรแล้วล่ะครับ

There’s More Than a Browser War

ก็ตั้งแต่ Google ออก Chrome น่ะแหละครับ ที่หลายคนคิดว่าจะเป็นสงคราม browser ใหม่อีกครั้งหรือเปล่า หรือว่า Google ทำไปเพื่อวัตถุประสงค์อะไรกันแน่ จากมุมมองของธุรกิจและความอยู่รอด ตลอดจน Business Identity และ Organization Identity ของ Google เอง ว่าทำไม Chrome (จากมุมมองของผู้เขียนบทความนี้) จึงเป็นหมากตาสำคัญที่สุดหมากหนึ่งบนกระดาน ที่ Google ต้องเดินเพื่อ “ปกป้องตัวเอง”

เป็นบทความที่อ่านแล้วได้คิดดีเหมือนกัน เลยเอามาแชร์กันต่อ

แปะลิงค์ก่อน

Real World Haskell (beta) by Bryan O’Sullivan, Don Stewart, and John Goerzen

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

เรื่องของเรื่องมันมีอยู่ว่า วันนั้นนั่งเขียนโปรแกรมอะไรซักอย่างอยู่ในห้องคอมพิวเตอร์ที่มหาวิทยาลัย Tsukuba (ไม่ได้เขียนอะไรใหญ่โตหรอก รู้สึกจะหัดเขียนพวก data structures เล่นอยู่) แล้วเพื่อนสนิทมากที่สุดคนหนึ่ง ชื่อ Nao Hirokawa (จริงๆ แล้วเป็นรุ่นพี่) ก็เดินเข้ามา แล้วก็ชวนคุยเล่นกันโน่นนี่ พอเห็นที่เราเขียนเล่นอยู่ ก็ถามว่า “เฮ้ ทำไมไม่ใช้ Haskell?” เราก็เลยถามว่า มันคืออะไรหว่า Hirokawa ก็เลยถามว่า รู้จัก Quick Sort มั้ย แหม ใครจะไม่รู้จัก เค้าก็เขียน Quick Sort เป็น Haskell ให้ดู พร้อมกับที่เราอ้าปากค้างตาโต (โดนแหก — จริงๆ แล้วรู้สึกว่า Quick Sort นี่เป็นตัวอย่างตลาดของ Haskell เลยนะ .. คงไม่มีใครไม่ยกตัวอย่างอันนี้มาแหกตาชาวบ้านเวลาโชว์ Haskell) แล้วก็เล่น List Comprehension ให้ดูอีกนิดๆ หน่อยๆ

นั่นแหละ รักแรกพบครั้งแรกในชีวิต