Ruby Business Commons

เมื่อวานไปนังฟัง Mr.Eihiro Saishu present หัวข้อเรื่อง Ruby Business Commons
ฟังหัวข้อตอนแรก นึกยังไงก็นึกไม่ออกว่ามันเป็นเรื่องเกี่ยวกับอะไร, ค้นใน net ก็พบว่ามี project อยู่ใน rubyforge
ตามไปดูก็ไม่พบข้อมูลเพิ่มเติม เห็นแต่ว่ามี code กองอยู่จำนวนหนึ่ง

ได้ไปฟังแล้วก็ประทับใจมาก เหมือนได้ฟังพวกคอเดียวกันพูด
present ของ Eihiro ทำออกมาได้แตกต่างจากคนอื่นในงานดี
ออกมาในแนวของ ใช้คำน้อย, สื่อสารด้วย keyword ไม่ไช่ bullet

Ruby Business Commons คือ Community ของคนที่มี passion ใน ruby
รวมกลุ่มกัน เรียนรู้, พัฒนา และที่สำคัญก็คือ สังสรรค์
แล้วก็มีกิจกรรม knock (ร่วมกลุ่มกัน implement project)
ตัวอย่าง knock ครั้งที่ 1 ของเขาที่เมือง Tenjin น่าสนใจมาก
ลองอ่านเพิ่มเติมใน slide
ส่วน web site ของตัว Community อยู่ที่นี่ Link
แต่เสียใจด้วยมันเป็นภาษาญี่ปุ่น (โชคดีที่บริษัทฯผมมีคนอ่านญี่ปุ่นได้)

อ่านกิจกรรม knock ของเชาแล้ว เริ่มฝันเห็นแนวทางรำไรของ Bangkok BarCamp แล้ว

อานิสงค์ของการไปฟังครั้งนี้ ก็เลยได้พบคนใช้ ruby ในไทยเพิ่มอีกหลายคน
เช่น น้องฝน(ที่เขียน wiki เรื่อง rails) และคุณชุมพล ครุฑแก้ว จาก nectec
แล้วก็น้องพีรพงษ์ จากบริษัท Thai Software Engineering
ที่กำลังใช้ rails พัฒนา product ให้กับบริษัทญี่ปุ่น(กล้องนิคอน)

จบ Codefest ไปอีกครั้ง

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