Jun 13, 2012

อยากทำ อย่างที่ 5 โปรแกรมแก้ไขเอกสารที่มองภาพรวมเป็นต้นไม้

วันนี้เห็น @awkwin ทวีตเกี่ยวกับความ *** สุดจะบรรยายของ JavaScript เลยได้ฤกษ์ขุดกระทู้ในตำนานมาอ่านอีกรอบ แล้วก็ได้สัมผัสถึงความ !@#$%^&* ของภาษา APL ซึ่งคอมเมนท์ในนั้นบอกไว้ว่า มันคงเป็นภาษาที่เจ๋งและกี๊คมากเลยถ้าอยู่ในหนัง ก็เลยทำให้นึกถึงหนังเรื่อง Stealth ตอนที่ศูนย์คอมเข้าไปดูโค้ดของโปรแกรมเพื่อหาบั๊ก (ส่วนนี้ในหนังกากมาก เพราะแม่งเล่นง่าย เอาโค้ดส่วนที่เป็นบั๊กไปไว้ "ระหว่างบรรทัด" เลย ซึ่งในความเป็นจริงโค้ดมันจะซ้อนอยู่ตรงนั้นได้ยังไงวะ) ถึงตอนนี้ก็ฉุกคิดได้ว่า เอ่อ ไม่เห็นจะเจ๋งตรงไหนเลย ถ้ามันแต่งมาเวอร์ๆ แต่ไม่มีทางเป็นไปได้ในโลกความเป็นจริง ...

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

ถอยกลับมา 1 ก้าว.. เอ่อ แต่ถ้าได้เขียนโค้ดแบบ 3 มิติจริงๆ คงเจ๋งไม่น้อยเลยนะ ก็เลยลองออกแบบว่า ไอ้การเขียนโค้ด 3 มิติ (ถ้ามันจะมีจริง) มันควรจะเป็นยังไงกันนะ?

คิดไปเรื่อยๆ โดยอิงจากตัวอย่างในปัจจุบัน ก็พบว่ารูปแบบโค้ดโดยทั่วไปจะออกแนวๆ นี้



ซึ่งถ้ามองในมุมของโปรแกรมเมอร์ที่เชี่ยวแล้วคงไม่มีปัญหา (เริ่มอ่านโปรแกรมจาก main ด้านล่างสุด แล้วโดดไปดูคลาส/ฟังก์ชันแค่เวลาที่ต้องการข้อมูลเพิ่มเติม)

แต่สำหรับโปรแกรมเมอร์มือใหม่ (อย่างผม) นี่ทำให้เกิดปัญหาที่เรียกว่า "เริ่มไม่ถูก" ขั้นรุนแรง ตั้งแต่เริ่มไม่ถูกว่าจะดูโค้ดที่ไหนก่อนดี? ทำไมต้องมองโปรแกรมตามแบบที่คอมพิวเตอร์ทำงานโดยการเริ่มจาก import requirement/dependency ต่างๆ ให้ครบก่อนแล้วจึงจะเริ่ม main ได้? ทิศทางการเขียนโปรแกรมควรจะเขียนแบบ top-down หรือ bottom-up กันแน่?

เลยได้ข้อสรุปสำหรับตัวเองว่า มันคงจะเหมาะกว่า ถ้าเริ่มมาก็สามารถเขียน concept ทั้งหมดของ main ได้เลย อยากใช้ฟังก์ชันใหม่ชื่ออะไรก็เขียนๆ ไปก่อน พอวางโครงเสร็จก็ค่อยกลับมาดูว่ามีฟังก์ชันไหนที่ยังไม่ได้เขียนกฎให้มัน ซึ่งพอดับเบิลคลิกที่ชื่อฟังก์ชันนั้นๆ ก็จะเป็นการเปิดป๊อปอัพหน้าต่างใหม่สำหรับเขียนกฎให้มันนั่นเอง (ยืมแนวคิดมาจาก lambda)



โดยรวมแล้วก็คงคล้ายๆ กับ Inspect Element ของเว็บเบราว์เซอร์ คือเริ่มดูจาก root node ไล่ลงไปเรื่อยๆ นั่นเอง เพียงแต่เปลี่ยนการ expand tag ไปเป็นการเปิดหน้าต่างใหม่แทน

รายละเอียดปลีกย่อย (ถ้าจะทำจริงๆ) ก็คงต้อง highlight สีของฟังก์ชันที่ยังไม่ได้เขียนกฎให้เด่นหน่อย ส่วนถ้าฟังก์ชันไหนเขียนไปแล้วแต่ติดแท๊ก FIXME หรือ TODO ไว้ ก็เปลี่ยนไป highlight ด้วยอีกสีหนึ่ง (จะได้รู้ว่ามีข้อผิดพลาดที่ฟังก์ชันนี้ และกลับมาแก้ไขทีหลังได้ง่าย) แล้วก็คงต้องดักพวก recursion ด้วย ส่วนการเขียนเพิ่มฟังก์ชันใหม่ๆ เข้าไป ต้องเอามันไปแทรกไว้ก่อน main เสมอ

คิดออกแค่นี้ ง่วงแล้ว ลองนอนดูก่อนว่าจะหายบ้ามั้ย 555

Jun 2, 2012

Opensource ไม่ใช่ของฟรี, คนทำไม่ได้อิ่มทิพย์

เรื่องหนึ่งที่เข้าใจผิดๆ กันมากเกี่ยวกับวงการไอที คือความคิดที่ว่า opensource คือของฟรี การนำ opensource มาใช้งานมีค่าใช้จ่ายเป็นศูนย์

อันที่จริงก็มีหลายคนเขียนถึงเรื่องนี้ไว้หลายครั้งแล้ว: 0, 1, 2 (ฯลฯ ที่ผมไม่สามารถหาเจอได้แล้ว) ซึ่งตอนนั้นผมเองอ่านบทความเหล่านั้นก็ยังไม่ค่อยเข้าใจเท่าไหร่ จนกระทั่งมาได้ทำงานกับ opensource จริงจัง

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

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

จาก 2 เคสที่ยกมานี้ จะเห็นว่าตัว opensource ไม่ได้จ่ายเงินให้นักพัฒนาเลย แต่เป็นผู้ว่าจ้างนั่นเองที่จ่ายเงินให้นักพัฒนาโดยตรง และโปรเจค opensource ก็โตได้เพราะเงินในส่วนนี้

ใช่ครับ opensource ไม่ใช่ของฟรี และคนทำก็ไม่ได้อิ่มทิพย์!!