คราวนี้โชคไม่ดีตรง กอบ เพื่อนร่วมทีมผม ที่รับผิดชอบงานด้าน
server side erlang เกิดไม่สบาย
ผมเลยต้องทำแทน
ด้วยความที่ไม่ได้เตรียมตัวเท่าที่ควร (เตรียมอยู่ 2 วัน)
อาการ panic ก็เลยเกิดขึ้น
ช่วงเช้าถึงบ่าย เป็นเวลาทีื่ชุลมุนที่สุด
เนื่องจากอยู่ในช่วง setup ปรับตัวกัน
ต้องแบ่งสมาธิไปทำหลายอย่าง ทำให้ไม่มีสมาธิที่จะทำโปรแกรม
ทืมผมได้กว้านเอาน้องๆแถวนั้นมาร่วมทืมอีก 3 คนคือ
น้องป้อ (iporsut.wordpress.com) จากสุรนารี
น้องซี (kobkrit.blogspot.com) กับน้อง boy จากธรรมศาสตร์
3 คนนั้นก็เลยได้ลิ้มรส erlang เป็นครั้งแรก
น้องป้อได้เปรียบหน่อยตรงที่คุ้นชินกับ haskell มาแล้ว
ตัว version control ที่ใช้ก็คือ Git
ซึ่งสร้างความปวดหัวเวียนเกล้าได้มาก เวลาที่มันเกิด exception case ขึ้นมา
(เวลาเราอ่าน tutorial เรามักจะทำไปตาม flow ที่รื่นไหล)
ร่ำๆจะเปลี่ยนไปใช้ svn แทน
การเขียน erlang คราวนี้ทำให้รู้จุดอ่อนอย่างหนึ่ง
(จุดอ่อนของคนเขียน ไม่ใช่ของภาษา)
เนื่องจาก erlang มี characteristic อย่างหนึ่งก็คือเรื่อง fail-fast
พอมี process หนึ่งตาย โปรเซสที่ link กันอยู่ ก็จะตายด้วย
ด้วยความที่เราทดสอบโปรแกรม จาก shell command เป็นหลัก
พอเราทำอะไรผิดนิดผิดหน่อย โปรเซส shell ก็จะตาย
ส่งผลให้ process ที่ start ด้วย generic behavior ทั้งหลาย
(พวกนี้จะ link กับ process แม่ที่ start มัน)
ตายตามเป็นแถว
ดังนั้นงาน routine ส่วนใหญ่ใน codefest ก็คือ restart process.
ตอนนั้นก็ได้แต่สงสัยว่า เอ๊ะเราไม่ได้ link ตัวนี้กับตัวนั้น
แต่ทำไมพอตัวนี้ตาย ตัวนั้นตายด้วยหว่า
มาร้องอ๋ออีกที ตอนสายๆของอีกวันหนึ่ง
จุดอ่อนการเขียน erlang อีกเรื่องก็คือการใช้ io:format
ที่เรามักใช้ในการ print output ออกมาดูที่ console ว่า โปรแกรมทำงานถูกต้องตามที่ต้องการไหม
ปรากฎว่า io:format มันมักจะรบกวนการทำงานของ process
ส่งผลให้ process มันมีพฤติกรรมแปลกๆไป
อย่างเช่น socket ที่เปิดอยู่ ถูกปิดไป, โดย process ที่ control ไม่ได้ตายไปด้วย
bug ตัวนี้ผมใช้เวลาหาอยู่ตั้งแต่ช่วงหกทุ่มถึง 7 โมงเช้า
ร่ำๆจะยอมแพ้ ไม่จบงาน ก็หลายที
แต่สุดท้ายมาปิ๊งว่าเป็นเรื่องนี้ ตอนที่ไปอาบน้ำ
งาน codefest คราวนี้มีประเด็นที่น่าสนใจอยู่เรื่องก็คือ
lead ในงานคราวนี้คือทืมจากญี่ปุ่น, ซึ่งเขามีแนวทางในการ lead project
ที่น่าสนใจมาก เช่นใช้ wiki เป็นตัวสื่อสารหลัก
การจัด schedule เวลา ฯลฯ
เสียดายมากที่ผมต้องทุ่มสมาธิไปที่ erlang อย่างเดียว
ก็เลยไม่ได้เข้าไปสังเกตและเรียนรู้วิธีการของเขา
ส่วนงานอีกเรื่องที่เกี่ยวกับ MapServer
อันนี้ผมเตรียมมาก่อนแล้ว น้องๆก็เลยทำกันเองได้ ไม่ต้องเข้าไปช่วย
ซึ่งผมคิดว่าคุ้มมากที่พาน้องๆที่บริษัทฯมา
เพราะ
1. การโปรแกรมในเวลาระยะสั้น ต้องการการสื่อสารที่ชัดเจน
ต้องการความเข้าใจใน tool, framwork เพื่อใช้ในการวินิจฉัยปัญหา
ปัญหาที่น้องๆเจอ น่าจะทำให้เขารู้ว่า จุดอ่อนของเขามันมีอยู่ที่ไหนบ้าง
เช่น น้องอั๋นหาวิธีการ response ajax request แบบไม่ได้ใช้ template render
อยู่หลายชั่วโมง, ซึ่งถ้าเขาเข้าใจ concept ของ framework ชัดเจน
เวลาในการ solve ก็จะเหลือไม่กี่นาทีแทน
2. การ present ผลงาน ทำให้เรารู้จักเตรียมตัว, การซักซ้อม,
การคัดเลือกเนื้อหาที่จะนำเสนอ
งานนี้ผมปล่อยให้น้องๆนำเสนอกันเอง
ซึ่งก็เกิดความผิดผลาดกันถ้วนหน้า
เช่นคุมเวลาไม่ได้, เนื้อหาไม่น่าสนใจ, program ไม่ work อย่างที่อยากจะแสดงให้ดู
Thursday, November 08, 2007
Subscribe to:
Post Comments (Atom)
1 comment:
อ่านแล้วอยากกลับไปจัด BarCamp Bangkok จัง
Post a Comment