Category Archives: Development

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

Posted on by
2

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

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

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

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

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

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

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

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

เก็บ iOS App Crash Log ส่ง App Developer กันเถอะ!

Posted on by
Reply

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

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

คำตอบคือ “ส่ง 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)

    location_crash.png

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

    crash_log.png

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

Buying List & Buying List Free

Posted on by
Reply

โปรแกรมทำ 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

ช่องกรอกรหัสผ่าน+วันที่

Posted on by
2

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

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

password_field.png

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

date.png

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

ออกแบบเว็บไซต์

Posted on by
8

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

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

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

Setup Aquamacs for Erlang

Posted on by
Reply

A quick note about how to setup Aquamacs (Cocoa Emacs distribution) for coding Erlang (the next kid in town).

I assume you install Erlang via Macports so if you install it via any other mean, something will vary (I used to install it, along with everything else, from source; but currently the Macports is just easier).

The setup is simply adding the following lines into your ~/.emacs file

(setq load-path (cons "/opt/local/lib/erlang/lib/tools-2.6.4/emacs" load-path))
(setq erlang-root-dir "/opt/local/lib/erlang")
(setq exec-path (cons "/opt/local/lib/erlang/bin" exec-path))
(require 'erlang-start)

Please note that the actual path may vary from installation to installation (version numbers, most probably). So check yours.

ปัญหา ความเคยชิน “ก๊อปโค๊ดมาแก้”

Posted on by
6

ว่าจะไม่เขียนเรื่องนี้แล้ว แต่ว่าเขียนหน่อยก็ดี จากเด็ก ICT ที่ทำโปรเจคกับผมเอง ขอยก conversation มาทั้งหมดกันแล้ว

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 ก็ดูค่อนข้างจะดีพอสมควรแล้วล่ะครับ

Real World Haskell และ รักแรกพบ

Posted on by
Reply

ไปเจอมา เอามา note ไว้สำหรับตัวเองและเพื่อนๆ พี่ๆ น้องๆ ทุกท่านที่สนใจ Haskell เป็นหนังสือที่ดีพอสมควรเลยทีเดียว ละเอียด ตัวอย่างเยอะ ค่อนข้างเป็นปัจจุบันมากๆ และมีประโยชน์กับ Real World จริงๆ (บ้างล่ะน่า) ไม่ใช่แบบหนังสือ Functional Programming ทั่วไปที่ยกว่า FP ดีอย่างนั้นอย่างนี้ แต่ว่าไม่ค่อยจะมีตัวอย่าง Real World ที่มัน convincing เท่าไหร่เลย ยกแต่ประโยชน์ที่ … ขอโทษนะ ต้องบอกว่า “ถ้าไม่ได้เขียน FP เป็นอยู่แล้ว ก็คงจะไม่ซึ้งกับมันเท่าไหร่ ว่ามันเจ๋งแค่ไหน” มากกว่า

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

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 ให้ดูอีกนิดๆ หน่อยๆ

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

Programmer->Manager

Posted on by
10

จาก ข้อความของ @sugree ใน twitter

my profession is coding. don’t hire me to be manager. it’s useless.

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

และท่านก็ต่ออีกว่า

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

KID In Digital ก็เรียนรู้เรื่องนี้แบบ Hard-way ล่ะนะ แต่ตอนนี้น้ององ(คช) คนที่ลองทำงานเป็น Project manager อยู่ครึ่งปี ก็อยากจะกลับมาเขียน code แล้ว แต่ใครจะมาเป็น Project manager แทนล่ะ? เพราะว่าผมเองก็อยากจะกลับไปเขียน code เหมือนกัน……

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

บางทีถ้าไม่ลองจับให้มีบทบาทบางอย่าง เราจะรู้ได้ยังไงว่าใครเหมาะ/ไม่เหมาะกับอะไรบ้าง ก็ต้องให้โอกาสกันเรียนรู้บ้าง

อย่าไปคิดว่าทุกอย่างมันจะต้องถูกต้อง เหมาะสม ไร้ที่ติ ไร้ข้อผิดพลาด ตั้งแต่แรก ตั้งแต่ต้นเลย ป่วยการ

Note to self: Project Planning

Posted on by
Reply

Note for myself:

  • Next time my developers say “X months” for developing any project, I will say “2X months” to the customers. So my developers will have time to talk to each other more and spending time developing relationship through playing games and doing all other activities with each other.
  • Next time my developers say “X weeks”, I will say “X weeks + 2X days”. My developers love to think of weekend and holidays as ‘working days’ which is simply wrong and give no breathing window if anything goes wrong.
  • I will train all the newcomers myself, like I once did to my current team of developers. Never again asking any of my developers doing it.
  • I have to beg my developers to remember: The opposite of playing isn’t working. It’s depression.
  • Never let any developer working alone again.
  • Don’t promote my top developer to do management work. Myself included. Why? I still believe I’m one of the finest developer in my office, and if I’m doing project management work; my team looses one good developer and get one bad manager.
  • Be more sensitive to small personal details. It ruins things.