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 →

รีวิวสั้น: iPad air

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

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

แต่… แทบทุกอย่างเปลี่ยนไปกับ iPad with Retina Display …… ในทางที่ค่อนข้างจะแย่ลง


DSCF1154.jpg

iPad air on a Macbook Pro

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 →

[ประกาศ] 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 แบบกว้างๆ เรื่อยๆ แต่ไม่ได้อะไรแบบลงลึกเท่าไหร่

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

เพิ่มเติมกับบทสัมภาษณ์ผมในกรุงเทพธุรกิจ

ขอเขียนอะไรเพิ่มเติมให้กับบทสัมภาษณ์ผมที่ลงหนังสือพิมพ์กรุงเทพธุรกิจเมื่อวันจันทร์ที่ 3 ตุลาคม (วันนี้แหละ) สักนิดหน่อย

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 ที่นั่นสักครั้ง …​ เหมือนกับคนทำงานด้านแฟชั่น คงจะไม่ได้อะไร หากจะเป็นแต่คนเก่งอยู่ใน “กรุงเทพเมืองแฟชั่น” (ตั้งใจประชด) แต่ไม่เคยสัมผัสงานในมิลานเลยสักครั้ง อะไรทำนองนี้แหละครับ

การทำ Proof-of-Concept กับการพัฒนาโปรแกรม

มีเรื่องนึงที่อยากจะฝากบอกน้องๆ ทั้งนักศึกษาและคนที่กำลังหัดเขียนโปรแกรมใหม่ๆ ที่จะต้องพัฒนาโปรแกรม ไม่ว่าจะใช้เอง เป็นโปรเจค ทำขาย หรือว่าอะไรก็แล้วแต่ ก็คือเรื่องของการทำ Prototyping และ PoC (Proof-of-Concept)

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

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

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

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

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

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

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

Buying List & Buying List Free

โปรแกรมทำ Shopping List ที่เน้นความเรียบ ความง่าย และความรวดเร็วในการใช้งานเป็นหลัก เกิดจากความขี้เกียจในการดึงเศษกระดาษกับหาปากกามาจดว่าจะซื้ออะไร ถ้าซื้อได้ก็รอดตัวไป ถ้าซื้อไม่ได้ ก็มักจะลืม เพราะกระดาษชิ้นนั้นจะถูกทิ้งไป พยายามหาโปรแกรมทำ Shopping List, To do list, To buy list หรืออะไรก็แล้วแต่แบบนี้ตั้งนาน มีแต่ซับซ้อนไปทั้งนั้น (จากความต้องการของตัวเอง) ก็เลยตัดสินใจพัฒนาโปรแกรมนี้ขึ้น

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


screenshots.jpg
Screenshot จาก iTunes App Store

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


large_icon.png large_icon_free.png

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


as_available_appstore_icon_20091006.png

AppDiscover badge

ล่าสุด โปรแกรมนี้ถูกรีวิวโดย 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

Pencast จากที่สอนวิชา UI วันที่ 6/14

Pencast ข้างล่าง 3 อันนี้ เป็นการบันทึกสดจากการสอนวิชา User Interface Design และ Human-Computer Interaction ครั้งที่ 3 (สองครั้งแรก ไม่มีการบันทึก เพราะยังไม่มีของเล่น แต่ว่าเนื้อหาจะยังคงไม่มีอะไรมากมายนัก และส่วนหนึ่งก็ได้พูดถึงซ้ำในวันนี้)

เนื้อหาคร่าวๆ ในวิชานี้ ผมไม่ได้ต้องการเพียงแค่ว่าหลักการในการออกแบบ 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 แล้วรบกวน “อดทนรอ” หน่อยนะครับ

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

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

“Generation Click”

กลับบ้านคราวที่แล้ว นั่งคุยกับพ่อเรื่องน่าสนใจหลายเรื่อง เรื่องหนึ่งก็คือ เรื่องผู้ใช้คอมพิวเตอร์ ทั้งเป็นผู้ใช้แบบ user จริงๆ และนักคอมพิวเตอร์ นักเทคโนโลยีสารสนเทศและการสื่อสาร และโปรแกรมเมอร์ generation ใหม่ ที่พ่อผมเรียกว่า Generation Click

คุณพ่อบอกว่า “พวก 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 ปุ่มไหนต่อ งานถึงจะเสร็จ ....​ ฮา (ไม่ออก)