จาก ข้อความของ @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 ที่ดีเท่าไหร่หรอกนะ และไม่เคยคิดว่าตัวเองเป็นได้ดีด้วย ไม่ได้คิดว่าน้ององเป็นได้ดีเหมือนกัน เพียงแต่ว่าคนมันมีกันแค่นี้ ก็เลยต้องทดลองกันไปเรื่อยๆ ตราบใดก็ตามที่ยังทดลองกันได้อยู่

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

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

ผมพยายามตั้ง Lab วิจัยทาง Computational Science (ใน Link เป็นข้อมูล “เก่ามาก” ไม่ได้ update มานานมากกกก) ที่ภาควิชาคอมพิวเตอร์ คณะวิทยาศาสตร์ ม.ศิลปากร ตั้งแต่จบกลับมาทำงานใหม่ๆ และ Lab นั้นก็เป็นรูปเป็นร่างขึ้นมาภายใต้ชื่อ SIGMA Lab (Scientific & Informatics Group of Multidisciplinary Arts; และคำย่อก็แปลว่าการรวบรวมซะด้วย) ซึ่งอยู่ในภาควิชาคอมพิวเตอร์เป็นเวลาครึ่งปี ก่อนที่จะขยับขยายมาอยู่ที่ใหม่ ที่สถาบันวิจัยและพัฒนา ม.ศิลปากร เช่นกัน ภายใต้โครงการนำร่อง Silpakorn Digital Content City (ตามที่ได้คุยและปรึกษากับผู้บริหาร ในเรื่องที่ท่านต้องการผลักดัน) ซึ่งผมก็เคยได้ post กิจกรรมของ SIGMA Lab ไปใน blog นี้เมื่อนานมาแล้ว

และในวันนี้ วันที่ SDCC โตขึ้น งานการทั้งหมดออกในชื่อนี้มากขึ้น เทียบกับ SIGMA Lab ที่เป็นองค์กรเกือบจะลับๆ ที่ไม่มีตัวตน (เพราะว่าที่มหาวิทยาลัยไม่ได้มีระบบการเรียนการสอนแบบห้องวิจัย) และลักษณะงานที่ออกไปในเชิง Computational Science และ Scientific Computation ตามเจตนาเดิมน้อยลงไปทุกที (ถึงวันนี้แทบไม่มีเลย) ในขณะที่ความต้องการในการทำ Digital Content มีมากขึ้น ไปประชุมที่ไหนก็มีแต่เรื่องนี้ทั้งนั้น เรื่อง Digital Content กลายเป็นประเด็นหลักในการทำงาน การวางแผนงาน และการสนทนา …. หลายคนพยายามที่จะผลักดันให้กลายเป็นวาระแห่งชาติ (แต่ไม่รู้จะแค่ไปอยู่ในแผน ที่ไม่เคยมีผลจริงๆ หรือเปล่า)

นอกจากนี้ยังมีเรื่องของความสามารถของทีมงาน SIGMA Lab เอง ที่ไม่เพียงพอจะทำ Scientific Computation และยังไม่มีโจทย์อีกด้วย แต่ว่าถ้าเป็นเรื่องการทำเนื้อหาดิจิทัลล่ะก็ ..​ เรามีความพร้อมพอสมควร และคิดว่าทำได้ดีกว่า

จะอย่างไรก็ตาม วันนี้ถือเป็นวันสำคัญวันหนึ่งสำหรับคนที่ผมทำงานด้วย คือ SIGMA Lab จะไม่มีตัวตนอีกต่อไปแล้ว

ยินดีต้อนรับสู่ DACI: Digital Arts & Content Industry

อะไรยากกว่ากัน ระหว่าง

1. สอนคนที่เขียนโปรแกรมเป็นแล้ว ให้เปลี่ยนภาษา
2. สอนคนที่เขียนโปรแกรมไม่เป็น ให้เขียนโปรแกรมเป็น

หลายคนจะตอบข้อ 2 โดยไม่ลังเลเท่าไหร่ เพราะว่าถ้าเป็นภาษาหนึ่งๆ แล้ว เรียนอีกภาษาหนึ่งคงไม่ยากเท่าไหร่ สาเหตุหนึ่งก็คงเพราะว่าภาษาส่วนมากมีรากที่คล้ายๆ กัน เช่น Pascal, C, C++, Java, C# ถ้าเป็นภาษาใดภาษาหนึ่งแล้ว การเรียนรู้ syntax ของอีกภาษาหนึ่งก็ไม่ใช่เรื่องยากเย็นเท่าไหร่แต่ว่าสอนคนที่เขียนโปรแกรมไม่เป็นให้เขียนโปรแกรมเป็นนี่สิ งานช้าง เพราะว่าอาจจะต้องสอนแนวคิด หลักการคิดแบบคอมพิวเตอร์ หลักการคิดแบบ von Neumann machine หลักการคิดแบบที่เราต้องใช้เวลาเขียนโปรแกรม ฯลฯ ซึ่งอาจจะยากหน่อย ไหนเลยจะต้องมานั่งเรียนรู้ syntax อีกแต่ว่าถ้าเปลี่ยนคำถามหน่อยนึงล่ะ เปลี่ยนข้อที่ 1 ให้เป็น

1. สอนคนที่เขียนโปรแกรมเป็นแล้ว ให้เปลี่ยน paradigm ในการเขียนโปรแกรม

ไอ้นี่อาจจะเป็นงานช้างพอๆ กัน หรือว่าช้างกว่าการสอนคนที่เขียนโปรแกรมไม่เป็นให้เขียนโปรแกรมก็ได้ เพราะว่าคนเราพอมันชินกับวิธีคิดแบบไหนแล้ว การจะเปลี่ยนรูปแบบของวิธีคิด การที่จะออกจาก The Matrix ของกระบวนการคิดของตัวเอง หรือว่าลักษณะการคิดของตัวเองได้ นี่คงจะยากเย็นแสนเข็ญมิใช่น้อย จะยกตัวอย่างดังนี้

• นึกถึงโปรแกรมที่ประกาศตัวแปรไม่ต้องประกาศ type แต่ว่าก็ยังเป็น strong typing ออกไหม
• นึกถึงโปรแกรมที่ไม่ต้องประกาศ main function ออกไหม
• นึกถึงภาษาโปรแกรมที่ไม่มี loop ออกไหม
• นึกถึงภาษาโปรแกรมที่ฉลาดพอที่จะทำ list comprehension (เช่นบอกว่า จะเอา x จาก list L โดยที่ x มากกว่า 3 แล้วมันเข้าใจว่าจะต้องทำอะไรโดยที่เราไม่ต้องเขียน low-level instruction)

นอกจากเรื่องพวกนี้จะยาก เพราะว่าพอสมองเราถูก over-train ให้ชินกับอะไรบางอย่างมากๆ แล้ว มันจะเรียนรู้สิ่งใหม่ยากขึ้น มีอะไรที่ต้อง unlearn มากขึ้น อย่าว่าแต่ imperative vs. functional programming เลย แค่ procedural vs. object-oriented ก็แย่แล้ว การที่เราจะ unlearn เรื่องหนึ่งๆ แล้วปรับไปสู่เรื่องใหม่ เป็นเรื่องที่ค่อนข้างยากเอาการทีเดียวไม่ใช่แค่นั้น แต่ให้เขียน style เดิม แต่ว่าเปลี่ยนภาษาเขียนโปรแกรม ก็ยากแล้ว

1. สอนคนที่เขียนโปรแกรมเป็นแล้ว ให้เปลี่ยนภาษา โดยต้องใช้เป็นภาษาหลักในกรณีทั่วไปแทนภาษาเดิม

ผมเห็นน้องหลายคนเขียน Ruby กันมาพักนึง (เพราะว่างานบางงานที่อาจจะต้องใช้ Rails) แต่ว่าพอลองตั้งโจทย์ที่มองไม่เห็นชัดว่าจะใช้ความสามารถของภาษาตรงไหน (ให้สร้าง permutation ของ list) น้องหลายคนก็ fall-back กลับไปเขียน C เหมือนเดิมไม่แปลกอะไร เพราะว่าจริงๆ แล้วผมเอง บางทีขนาดโปรแกรมง่ายๆ ก็ยังดื้อจะเขียน C++ กับ STL อยู่เลย ทั้งๆ ที่รู้อยู่แก่ใจว่า Ruby, Python, Haskell มันก็ทำได้ และจะง่ายกว่าด้วย แต่ว่าทำไมนะ ทำไมผมถึงยังจะดื้อที่จะ fall-back ไปเขียน C++ อยู่ดี?ความเคยชินบางอย่างมันแก้กันยาก อาจจะเป็นเพราะว่าผมใช้เวลาอยู่กับ C++ มานานกว่าภาษาอื่นๆ และทำงานจริงในภาษาตระกูล C มานานกว่าภาษาอื่นๆ หลายเท่าตัวก็ได้ (C, C++, Objective-C)เปล่าหรอกครับ ผมไม่ได้ถามเพื่อหาคำตอบใดๆ เพราะว่านี่คือธรรมชาติของมนุษย์ อะไรก็ตามที่เราทำจนเป็นนิสัย จนเป็น second nature แล้วมันอาจจะเปลี่ยนแปลงยากมาก หลายเรื่องเราเปลียนไม่ได้ เพราะว่าเรามีความรู้สึกว่า “เคยทำ” อะไรที่มันคล้ายๆ กันมาก่อนในลักษณะนั้นอยู่แล้ว (เช่นเวลาผมจะเขียนโปรแกรมง่ายๆ บางทีผมใช้ C++ โดยไม่มีเหตุผล ทั้งๆ ที่เขียน Ruby ง่ายกว่าเยอะ ส่วนหนึ่งเพราะว่าผม “เคยทำ” สิ่งนั้นมาแล้วใน C++ มั้ง)ผมเลยมีข้อสังเกตและข้อเสนอแนะให้น้องๆ ที่อยากจะเขียนโปรแกรมภาษาใหม่นะครับ ดังนี้

1. เขียน code ภาษานั้นให้เยอะที่สุดและเร็วที่สุด โดยอย่าเอาแต่ลอก code จากหนังสือหรือว่า tutorial เพราะว่าคุณจะไม่ได้ใช้งานจริง และไม่ได้ force ให้ตัวเองคิดในลักษณะของภาษาใหม่ๆ เท่าไหร่
2. เรียน standard library ของภาษานั้นๆ ให้มากที่สุดในเวลาที่น้อยที่สุด เพื่อให้รู้ว่ามันพอจะทำอะไรให้เราได้บ้าง โดยไม่ต้องลงอะไรเพิ่มเติม แล้วก็ลองดูว่ามันเอามาทำอะไรให้ชีวิตเราง่ายขึ้นได้บ้าง
3. หักดิบ อย่าเล่นภาษาเดิมเท่าที่จะทำได้ ถ้าจำเป็นจริงๆ ก็ลองลบ compiler ภาษาเดิมทิ้งไปเลย
4. อย่าเอาแต่เรียน syntax กับ library นะ เพราะว่าสิ่งที่สำคัญที่สุดสิ่งหนึ่งที่แทบทุกคนลืม ก็คือ การเรียน idiom ของภาษานั้นๆ ยิ่งหลายภาษา โดยเฉพาะพวกภาษาใหม่ๆ เป็นพวก expressionism ซะด้วยสิ แบบนี้ idiom ยิ่งสำคัญมากเข้าไปอีก
5. ยิ่งถ้าเป็นการเรียนภาษาคนละ paradigm กับที่เคยเขียนนะ ยิ่งไปกันใหญ่ เพราะว่าลักษณะการเขียน วิธีคิด idioms ต่างๆ มันจะต่างกันมาก มากๆ ถึงมากที่สุด
6. ยากนะ แต่ว่าหลายครั้งต้องคิดนอกกรอบเดิม ถ้าคิดตามกรอบเดิมล่ะก็ คุณก็จะไม่ได้เขียนภาษาใหม่หรอก แต่ว่าจะเขียนภาษาเดิมน่ะแหละ แต่ว่าอยู่ใน syntax ใหม่เท่านั้นเอง
7. ทำงานจริง เพราะว่าทำงานจริงเท่านั้นที่จะบังคับให้เราต้องอยู่กับภาษาโปรแกรมภาษาใหม่และกระบวนการคิดของมัน ยิ่งทำงานจริงแบบมี deadline ด้วยแล้วล่ะก็ ยิ่งดี เพราะว่าเป็นการบังคับให้เรายิ่งต้องคิดและ figure out การทำงานต่างๆ และ idioms ของมันให้ได้เยอะที่สุด เพื่อประโยชน์สูงสุด และให้งานเสร็จเร็วที่สุด
8. หา library เพื่อช่วยงานโน้นงานนี้เยอะๆ มีของเล่นเยอะๆ แล้วลองเล่นกับมัน เดี๋ยวก็ชินกับมันไปเองแหละ
9. ดูภาษาอื่นๆ ใน paradigm เดียวกันบ้าง เพื่อหาข้อเปรียบเทียบหน่อยๆ ก็ดี
10. ระลึกไว้ ว่าไม่ใช่ทุกภาษาเหมือนกัน สิ่งที่ผิดหลักการในภาษาหนึ่ง อาจจะเป็นสิ่งที่ถูกหลักการและควรทำในอีกภาษาหนึ่งก็เป็นได้ ดังนั้นอย่ายึดติดกับหลักการและข้อบังคับข้อกำหนดต่างๆ ของภาษาหนึ่งๆ มากไปนัก
11. พยายามมองหาโอกาสใช้มันให้เยอะที่สุดเท่าที่จะทำได้ และอย่าเลี่ยงโอกาสในการใช้มันซะล่ะ

จริงๆ เรื่องนี้ยังเขียนได้อีกยาวมาก แต่ว่าวันนี้พอแค่นี้ก่อน ชักเหนื่อย แต่ขอปิดท้ายด้วย quote ดังจากคนดัง

Anyone could learn Lisp in one day, except that if they already knew Fortran, it would take three days.Marvin Minsky

เห็นรูปนี้จาก MSN น้องโตโต้ (protocoltoto ใน blog นี้) มานานล่ะ วันนี้ไม่รู้นึกยังไงก็เลยเอามา share กันบ้าง ไม่รู้ว่า original creator เป็นใคร แต่ว่า creative มากมาย ชอบ

คิดๆ อยากจะเขียน code snippet (ที่ไม่เกี่ยวกับ mac development) ลงในนี้บ้างเหมือนกัน แต่ว่ามันไม่มี highlighting เจ๋งๆ เลย ไอ้ตัวที่ใช้อยู่นานนมกาเลอย่าง code2html ก็ดันไม่ highlight Haskell อีก จะเขียนเพิ่มเข้าไปเองก็ขี้เกียจ (ทั้งๆ ที่จริงๆ ก็ทำได้อ่ะนะ แต่ว่า code มันเขียนแบบ Perl-ish มากกกกก แถมไม่ factored ไม่แยก module เท่าไหร่) … อืมมม มันต้องมีคนคิดเหมือนเราสิ ว่าแล้วก็เริ่มหา

สักพักก็ไปเจอหน้า Plugins/Syntax Highlighting ที่ Wordpress เอง แต่ว่าเท่าที่อ่านๆ ดูไม่ค่อยจะมีตัวไหนเข้าท่าเลยแฮะ (มันไม่ highlight Haskell ซักกะตัว เท่าที่อ่านแบบผ่านๆ) นอกจาก Vim Color แต่ว่าไอ้ตัวนี้ก็ดันไป dependent กับ Text::VimColor ที่เป็น Perl module ต้องลงผ่าน CPAN อีก เออ ไม่เป็นไร ลงก็ได้ แต่ว่าก็ดัน build ไม่ผ่านซะงั้น (test ผ่านน้อยไปหน่อย) จะ force install ลงเลย ก็ดันไม่ work อีก เฮ้อ เบื่อจริง ก็เลยต้องหาต่อไป

และแล้วเราก็ไปเจอ GeSHi: Generic Syntax Highlighter ที่เขียนในภาษา PHP เราก็เลยเอามาเขียนทำเป็น command line application ง่ายๆ ที่อ่านไฟล์ตาม argument แล้วก็เดาภาษาจาก extension ของไฟล์ แล้วก็พ่น highlighted code ที่เป็น HTML ออกมาให้เรา code-paste ใส่ blog ได้ผลดังนี้ (Haskell)

import List
 
permute [] = [[]]
permute xs = [x:ys | x <- xs, ys <- permute (delete x xs)]
 

หรือว่าภาษา Ruby แบบนี้

class Array
  def permute
    return [self] if size < 2
    perm = []
    each {|e| (self - [e]).permute.each {|p| perm << ([e] + p)}}
    perm
  end
end
 
[0,1,2,3].permute.each {|e| p e }

ก็ใช้ได้อ่ะนะ แต่ว่ามันอาจจะรก HTML code ไปหน่อยนึง

[update 1]: พอมี line number แล้วมันเละใน blog แฮะ เลยเอาออก ไว้จะแก้ CSS ทีหลัง ตอนนี้ขี้เกียจ (อีกล่ะ)

[update 2]: เพิ่งจะสังเกตจากหน้า web ว่า \\ ใน code haskell มันหายแฮะ เหลือแค่ตัวเดียว .. ไม่รู้เหมือนกันว่าทำไม code ฝั่งนี้ก็ยังอยู่นะ เลยไม่รู้จะว่าไงดี :-(

[update 3]: สุดท้ายก็เลยลงเอยด้วยการเขียน code ใหม่ไม่ให้มันมี \\ อืมมม อ่านเป็นภาษาคนกว่าเก่าแฮะ แต่ว่ามัน geek-ish น้อยลง :-P

[update 4]: อ๊ากกก GeSHi มันไม่มี Erlang highlighting! ว้า กำลังจะหัดเล่นอยู่เลย ว่าแต่ Erlang นี่ทำไมมันลูกเมียน้อยตอนนี้จังเลย emacs ก็ไม่มี (ผมใช้ Carbon Emacs distribution) TextMate ก็ไม่มี มีแต่ vim … สุดท้ายก็ตายรังสินะ แต่ว่า Emacs mode ของ Erlang ก็ไม่น่าหายากเท่าไหร่ [note -- ณ ปัจจุบัน เจอแล้ว] ไม่เป็นไร มีเวลาและชินๆ กับ Erlang มากกว่านี้เมื่อไหร่ (พอจะชินกับ module/keywords) แล้วเดี๋ยวค่อยทำเพิ่มเข้าไปใน GeSHi เองก็ได้วะ

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

• หลายคน (ความเชื่อสาธารณะ) ยังคงมองซอฟต์แวร์ ว่าเป็นสิ่งที่แถมมากับเครื่องอยู่ พอจะซื้อเครื่องใหม่ ก็มักมีค่านิยมให้ร้าน load โปรแกรมให้เยอะๆ จะใช้ไม่ใช้อีกเรื่องนึง load ไว้ก่อน ซึ่งก็เลยกลายเป็นงูกินหางกับทางร้าน เพราะว่าการ load ซอฟต์แวร์ที่ลูกค้าต้องการให้ได้ กลายเป็น competing feature หนึ่งไปซะงั้น
• Trialware/Shareware หลายตัวที่มีให้ download ใช้เพื่อทดลองจากเน็ต พอหมดอายุหรือว่าหมด feature เราก็มักจะนิยมทำการ “หา crack” หรือ “หา serial” ที่มันก็ไม่ได้หายากหาเย็นเท่าไหร่ เป็นอันดับแรกๆ ในความพยายามที่จะทำให้เราได้ใช้ซอฟต์แวร์ตัวนั้นๆ ต่อไป
• ราคา อันนี้เรื่องใหญ่และเป็นปัญหาโลกแตก … จ่ายแพงกว่าทำไม ในเมื่อจ่ายร้อยเดียวได้ (หลายโปรแกรมด้วย) ทำไมต้องจ่ายเป็นพันด้วย? (ไม่ใช่แค่พันหรอก ซอฟต์แวร์บางตัวแพงกว่าเครื่องอีก อย่าง Mathematica เงี้ย ซื้อ laptop ได้สองเครื่องสบายๆ)
• Availability อันนี้อาจจะเป็นเรื่องใหญ่กว่าด้วย … โปรแกรมหลายตัวอยากใช้ด่วนน่ะ แต่ว่ามันไม่มีขาย ติดต่อตัวแทนจำหน่ายก็เรื่องมาก ท่าเยอะ ต้องมีกระบวนการมากมายวุ่นวาย ทั้งเรื่องการเงิน ฯลฯ เฮ้อ ขับรถไปศูนย์ซอฟต์แวร์แป๊บเดียว ดีกว่ากันเยอะ
• Support เราหลายคนก็ไม่ได้ต้องการ support อะไรมากมายกับโปรแกรมที่เราซื้อมาซะด้วย เพราะว่าส่วนมากก็ไม่ได้ใช้งานมากอะไรถึงขนาดที่ทำให้ support มัน crucial ขึ้นมา ใช้งานงูๆ ปลาๆ ไม่กี่ feature ไม่กี่อย่าง คลำๆ เอาเอง หรือว่าถ้ามันไม่ work จริงๆ ก็ไปเรียนเอา หรือว่าหาคนสอนแถวๆ ไหนก็ได้เอา

เอาเป็นว่า จะเหตุผลใดก็แล้วแต่ ทำให้การใช้ซอฟต์แวร์เถื่อนยังคงเป็นทางเลือกหลักของการใช้งานโปรแกรมคอมพิวเตอร์ในบ้านเราอยู่ดี

แล้วผมเขียนถึงเรื่องนี้ทำไม …​ พอดีวันนี้ iWork 08 หมดอายุ trial 30 วันแล้ว ก็เลยไปซื้อของแท้แบบมีกล่องมาซะหน่อย (จริงๆ ซื้อ license/serial ผ่าน net ก็ได้ แต่ว่าไหนๆ มันก็ราคาพอกัน ได้กล่องด้วยดีกว่า .. พวกบ้าวัตถุก็เงี้ย) …​ แล้วผมทำงั้นไปทำไมล่ะเนี่ย ก็ในเมื่อ iWork มันก็หา serial เถื่อนได้นี่ (จริงๆ ผมก็มี serial เถื่อนอยู่ในมือเรียบร้อยแล้วล่ะ)

ผมยืดถือธรรมเนียมปฏิบัติส่วนตัวอยู่ไม่กี่ข้อในการใช้ซอฟต์แวร์นะ

1. Freeware/Free Software/Open Source มาก่อนเสมอ ถ้าทำได้ จ่ายแพงกว่าทำไมถ้ามีของฟรี (จริงๆ ไม่ใช่ละเมิดเค้ามา) หลายตัวมันไม่ feature-complete แต่ว่าถ้าเราต้องการใช้มากกว่านั้นและบังเอิญมันมีใน commercial software ก็จ่ายตังค์ซื้อ feature พวกนั้นไปสิ ถ้าเราไม่มีปัญญาจ่ายก็ถือว่าเราไม่ได้ต้องการมันจริง (รักจริงต้องสู้สินสอดได้) และใช้ๆ ไปเถอะ เราจะพบว่าหลายครั้งเราหลอกตัวเองว่าเราต้องการโน่นนี่ จริงๆ ไม่มีไม่ตายหรอก พวก Freeware/FS/OS พวกนี้หลายต่อหลายตัว “เจ๋ง” กว่าที่หลายคนคิดเยอะ
2. ถ้าจำเป็นจริงๆๆๆๆ ก็ใช้มันไปเถอะ ไอ้ซอฟต์แวร์เถื่อนน่ะ แต่ว่านี่หมายถึงต้องหา Freeware/FS/OS ที่ทำงานแทนได้แบบสุดความสามารถแล้วนะ ห้ามเอามาเป็นข้ออ้างเด็ดขาดด้วย และต้องใช้ในการทำมาหากิน “เท่านั้น” และ
3. “ถ้า” เราทำเงินจากมัน ไม่ว่าจะโดยตรงหรือโดยอ้อม ได้มากกว่าราคาซอฟต์แวร์ตัวนั้นเมื่อไหร่ เราจะต้องซื้อมันแบบถูกต้อง ไม่มีข้ออ้าง เพราะว่าคุณทำเงินได้มากกว่าราคามันแล้วนี่

ผมก็เลยลองไล่ซอฟต์แวร์ในเครื่องดู พบว่าผมมี Freeware/FS/OS ค่อนข้างหลายตัวที่เป็นชิ้นส่วนสำคัญในการทำงานของผม ส่วนโปรแกรมที่ผมใช้ทำงานจริงๆ ผมก็เสียเงินซื้อเสียเป็นส่วนมาก (เช่น iWork ที่ Pages มันช่วยชีวิตผมในการทำ poster งานวิจัยมาหลายครั้งแล้ว และ Keynote ที่ถ้าไม่มีมัน ชีวิตผมในฐานะวิทยากรรับเชิญตามที่ต่างๆ และอาจารย์ประจำ คงจะกร่อยไปอีกเยอะ แล้วก็มี TextMate อีกตัว และอื่นๆ อีกหลายตัวด้วย) ….​ส่วนที่ยังใช้แบบเถื่อนอยู่ก็มีบ้างแหละครับ แต่ว่านั่นเป็นเพราะผมต้องใช้มันบ้าง (อย่างมากก็เดือนละครั้ง) .. แต่ไม่เคยทำเงินจากมันได้ไม่ว่าจะตรงหรืออ้อม และหาตัวแทนมันไม่ได้จริงๆ (พยายามหาแล้ว หาอีก หาแล้ว หาอีก) .. ก็ถือว่ายังตรงกับธรรมเนียมตัวเองล่ะนะ

ปล. ผมเห็นน้องๆ หลายคนนะ หัดเขียนโปรแกรมจะต้องใช้ Visual Studio Enterprise Architect edition ทั้งๆ ที่จริงๆ แล้ว Express (ซึ่งฟรี) มันก็มี หรือว่าหลายคนหัดทำ 3D ก็ไปใช้ Maya “Unlimited” ทั้งที่จริงๆ แล้ว Personal Learning Edition มันก็มี ..​ ฯลฯ

ว่าแต่คุณล่ะ มีหลักการ/ธรรมเนียมปฏิบัติยังไงในการใช้ซอฟต์แวร์?

[update 1]: ขอขยายความข้อ 2 นิดหน่อย คือบางคนชอบเอาข้ออ้างที่ว่า “ต้องการศึกษาเพื่อนำไปใช้งาน” โดยมากมักจะเกิดขึ้นกับซอฟต์แวร์ที่เป็นระดับ professional เช่นฐานข้อมูล Oracle ชุดพัฒนาซอฟต์แวร์ VS.NET Enterprise Architect โปรแกรมแต่งภาพ Photoshop CS3 โปรแกรม 3D Modeling/Animation เช่น Maya Unlimited บางทีก็เข้าใจและเห็นด้วยนะ ที่ว่าบางทีเราก็ต้องการเรียนรู้โปรแกรมพวกนี้เพื่อนำไปทำงานจริงในอนาคต ซึ่งโปรแกรมพวกนี้จริงๆ แล้วหลายตัวก็จะมี scaled-down version ให้ใช้ฟรีหรือราคาถูก และไม่ยอมให้นำไปใช้เพื่อทำการค้าได้ ให้ใช้อยู่แล้ว ถ้าจำเป็นต้องใช้โปรแกรมพวกนี้จริงก็ค่อยซื้อ version ที่เหมาะสมเอาทีหลัง หรือว่าถ้ามันไม่มี version อย่างที่ว่าจริงๆ (แต่ว่าบางทีก็มี trial-ware version) ก็ใช้เถื่อนใช้ crack ไปก่อน จนกระทั่งเราทำเงินกับมันได้ ซึ่งเร็วหน่อยก็ดี และซื้อใช้ซะ

โปรโมทซะหน่อย

นอกจาก SIGMA Research Lab (โครงการ Silpakorn Digital Content City, สถาบันวิจัยและพัฒนา ม. ศิลปากร นครปฐม) ที่ผมกับน้องๆ ผู้ช่วยทั้งหลาย ทำงานอยู่ จะทำงานวิจัยและพัฒนาระบบ Digital Content ต่างๆ จัดกิจกรรม LO & KM และงานทาง Multimedia, Computer Simulation (Visual และ Scientific), HPC, Web application/services ฯลฯ แล้ว เรายังมีกิจกรรมบางอย่างด้วย คร่าวๆ ก็ดังนี้นะครับ

• วันจันทร์ (18:00 ~ ) : Movies Day

  เรียนรู้จากภาพยนต์ เลือกหนังมาดูกัน แล้วช่วยกันวิจารณ์ หาข้อคิดต่างๆ หรือว่าทฤษฎีต่างๆ ที่ซ่อนอยู่ในหนัง หรือว่าแม้แต่จับผิดหนังจากข้อมูล factual ต่างๆ และ logic ต่างๆ

• วันพุธ (18:00 ~ ) : Programming Day

  ฝึกเขียนโปรแกรมในหลากหลายภาษา เพื่อแก้ปัญหาต่างๆ ที่อาจจะเรียกว่าเป็น classic เพื่อฝึกทักษะทั่วไปทาง Algorithmic Problem Solving บางทีก็จะใช้โจทย์จาก Online Judge และ Programming Contest ต่างๆ

• วันศุกร์ (18:00 ~ ) : Seminar

  ที่ทำกันมาตั้งแต่ตั้ง lab ใหม่ๆ เมื่อ 2 ปีก่อนไม่ได้เว้นว่าง ส่วนมากจะเป็น work progress และแลกเปลี่ยนประสบการณ์ใหม่ๆ ซึ่งตอนนี้ฤดูกาลของการ present research paper ในวิชา Research Methodologies ก็ใกล้จบลงแล้ว ช่วงเวลาของการทำ project จบจริงๆ ก็มาถึงแล้วด้วย คราวนี้จะหนักเรื่อง Work progress ล่ะ

• วันอาทิตย์ (vary) : Journal Seminar

  (อันนี้กำลังคิดอยู่ว่าจะทำ ยังไม่แน่ใจ) อาจารย์ นักวิจัย (พวกที่จบแล้ว) ผลัดกันเอา paper งานวิจัยที่เกี่ยวข้อง มาสนทนากัน

ใครที่อยากจะมาร่วมงานเหล่านี้ด้วย ก็ยินดีต้อนรับนะครับ ไม่ว่าจะเป็นศิษย์เก่าศิษย์ปัจจุบัน ผู้สนใจต่างๆ หรือว่าแม้แต่น้องๆ นักศึกษาต่างคณะ ต่างสถาบัน ที่นี่เราไม่มีกำแพงเรื่องสถาบัน ไม่มีหมวก ไม่มีหัวโขน ส่วนจะมาร่วมงานวิจัย/พัฒนาด้วยกันหรือไม่ อันนี้เป็นเรื่องของอนาคต รู้จักกันไว้ก่อนก็ดี บางทีก็เข้ามานั่งทำงานเล่นได้นะ มีพี่ๆ ที่อยากให้คำปรึกษาเรื่อง coding หรือว่า program design หลายคนเลย (ณ ปัจจุบันก็โดยเฉพาะ Web applications/services)

เซ็ง(โว้ยยยยยย)

เขียนบทความลงหนังสือ 35 ปีคณะวิทยาศาสตร์ ม.ศิลปากร (ที่ทำงานปัจจุบัน) ทางคณะอยากได้บทความที่ออกแนว popular science คือ เขียนให้คนทั่วไปอ่าน ไม่วิชาการจ๋า เราก็เขียนให้ และก็เวียนให้คนในภาคช่วยกันอ่าน ช่วยกัน comment

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

พอมาเป็นบทความของเรา ทำไมชื่อ รวิทัต ภู่หลำ มันหาย เหลือแต่ อาจารย์ประจำภาควิชาคอมพิวเตอร์ คณะวิทยาศาสตร์ มหาวิทยาลัยศิลปากร หว่า

เหมือนกับว่าอาจารย์ทั้งภาคช่วยกันแต่งเลยเนอะ

ปล. ดีนะ ที่ยังมี e-mail ของเราลงอยู่ด้วย ไม่งั้นคงไม่มี trace อะไรเลยจริงๆ

แต่ว่าเบื่อว่ะ ทำไมวะ เฮ้อ

ปล. ขอบคุณลูกศิษย์สองคน thitipat ที่เป็นคนสังเกต คนเจอ และ kiterminal ที่เป็นคนบอกผม

โดนเชิญมาพูดแบบกระชั้่นมาก ฉุกละหุกมาก แต่ว่าก็ทำให้เรามีโอกาสได้ทำ 2 อย่าง คือ

• มาภูเก็ต ถึงจะไม่มีเวลาเที่ยวก็เถอะ ได้เห็นบ้านเมืองบ้าง ได้เห็นโน่นนี่บ้าง เห็นการ recover เมืองจากภาพที่เราเคยเห็นจาก Tsunami tragedy แล้วก็ดูความเป็นไปได้ที่จะมาเที่ยวในอนาคต
• ได้บินสายการบิน low-cost ภายในประเทศครั้งแรก อยากรู้มานานแล้วว่ามันเป็นยังไง

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

ส่วนเรื่องที่ถูกเชิญมาพูดน่ะ พอดีเค้าให้รายละเอียดมาค่อนข้างน้อย หัวข้อมีแค่ “Macintosh” เท่านั้นเอง เราเลยต้องเล่นเกมเดาใจว่าเค้าอยากให้เราพูดเรื่องอะไร สรุปก็เลยพูดหัวข้อที่ว่า “Me, My work, My life, My Mac” ที่เป็นมุมมองของผม ในฐานะ Academic lecturer, Research scientist, และ Software developer ที่บังเอิญ พอดีเป็นผู้ใช้ Mac

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

เท่าที่คุยกับอาจารย์เค้า รู้สึกว่าจะมีอาจารย์คนหนึ่งจบมาจาก MIT เสียด้วยสิ เห็นบอกว่าทำเรื่องเอา remote sensing ไปตรวจวัดค่าต่างๆ ในอากาศ เพื่อเอามาพยากรณ์อากาศ และได้ model ที่แม่นมาก ชักอยากจะรู้เหมือนกันว่าเค้าใช้ model อะไร เพราะว่าเราสนใจเรื่อง Mathematical models ของเรื่องพวกนี้มานานแล้ว และ Weather forecasting นี่ถือเป็น chaotic system ตัวหนึ่งที่น่าสนใจและ classic มากๆ ด้วย

สงสัยคงต้อง e-mail ไปคุยด้วยแฮะ อ่อ แล้วใครอยากจะเชิญผมไปพูด ติดต่อมาได้นะแต่ว่าพักหลังๆ อาจจะยุ่งนิดหน่อย

วันนี้พาลูกน้องที่ทำงานมาจัด workshop ที่ BIOTEC ทำให้เจอเรื่องอะไรหลายอย่างที่จัดว่าเป็นประสบการณ์ของผมที่จะต้องจำมันไว้

• อย่าไว้ใจทางอย่าวางใจคน ผมต้องใส่ใจกับรายละเอียดเล็กน้อยมากกว่านี้ บางทีไว้ใจคนที่ทำงานด้วยมากเกินไป บอกให้ทำอะไรไว้ที่ค้ดว่าสำคัญ และเจ้าตัวได้ตกปากรับคำไปแล้วว่าจะทำ … แต่ว่าถึงเวลาจริงๆ ไม่มี ก็คงต้องเก็บรายละเอียดด้วยการ check ให้ละเอียดเอง
• เรื่องการ deploy งาน บอกหลายครั้งว่าต้องเตรียม deploy งานบน Windows ไปด้วย ต้องให้มี impression ที่ดีตั้งแต่ “การติดตั้งโปรแกรม” เพราะว่าลูกค้าหรือว่าคนทำงานด้วย จะเริ่มรู้สึกว่าโปรแกรมใช้ง่ายหรือยาก ไม่ใช่ตอนใช้งานนะ มันเริ่มจากตอน “ติดตั้ง” และ “เรียกใช้” โปรแกรมตะหาก
• บางทีนะ เรื่องบางเรื่องบอกไปเป็นสิบๆ ครั้ง แต่ว่าไม่ทำ บอกว่าคงไม่ใช่ปัญหา แค่ copy InstantRails ลงไปก็จบแล้ว แต่ว่าผู้ใช้ทั่วไปน่ะ เรื่องนี้ยังยากอยู่นะ มันต้อง single-click
• อย่าว่างั้นงี้เลย ไม่มีการ download file ที่จะใช้ install มาเตรียมไว้ก่อนด้วยซ้ำ ไม่มีการ burn CD มาเพื่อให้คน copy ลงเลยครั้งแรกด้วยซ้ำ
• รายละเอียดโปรแกรม เฮ้ย ทำไมมันไม่มีการ validate field อะไรเลยวะ จะบ้ากันไปใหญ่แล้ว นี่มัน programmer error ชัดๆ
• ฯลฯ ขี้เกียจเขียนล่ะ :-P

ครั้งหน้า ผมคงต้องเตรียมรายละเอียดเองหมดล่ะ ต้อง check รายละเอียดมากกว่านี้ ไอ้เรื่องที่คิดว่า “ไม่ควรเกิดขึ้นหรอก ไม่น่าจะเกิดขึ้นหรอก” มันเกิดขึ้นประจำ

งานนี้โทษตัวเองครับ จุดอ่อนคือการที่ไว้ใจ