อันนี้เหมือนจะเป็นตอนต่อจาก entry ที่เขียนไว้เมื่อเกือบ ๆ 7 ปีที่แล้วครับ

คือโค๊ดอันนั้นเป็นการแสดงว่ามันลูปได้จริง ๆ นะ แต่ปัญหาคือ SDL นั้นไม่มี mixer ในตัวครับ และโปรแกรมนั่นเล่นได้แค่เสียงเดียวเท่านั้น เรียกได้ว่าแทบไม่มีประโยชน์อะไร ... เอาเป็นว่าช่างมันก่อนละกัน วันนี้จะเสนออีกวิธีนึงที่น่าจะใช้ประโยชน์ได้มากกว่า

แต่ก่อนหน้านั้นขออธิบายเรื่องการเล่นไฟล์เสียงแบบ streaming ก่อน

การเล่นเสียงแบบ Streaming

โดยทั่วไปเวลาเราจะเล่นไฟล์เสียง เราจะโหลดข้อมูลทั้งไฟล์ขึ้นไปในบัฟเฟอร์ ในรูปแบบที่ตัว hardware หรือ api สามารถเล่นได้ (มักจะเป็น PCM - Pulse-Code Modulatation) ซึ่งปัญหาคือถ้าไฟล์เสียงเรายาวมาก ๆ มันจะใช้พื้นที่ในหน่วยความจำค่อนมาก โดยทั่วไปก็ราว ๆ 60MB ต่อนาที (คิดที่ PCM 44.1KHz 16bit Stereo ครับ) การโหลดข้อมูลใหญ่ ๆ เข้าในเมโมรีทีเดียวทั้งหมดอาจจะเยอะเกินไป อาจจะทำให้โปรแกรมไม่ทำงานได้

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

พักตรงนี้ก่อน โค๊ดตัวอย่างนี้ใช้ไฟล์จาก Persona 4 OST แต่ผมคงไม่สามารถแปะเพลงนี้ได้ ถ้าสนใจอยากลองฟัง ก็ลองดูคลิปนี้ละกันครับ (คนละเวอร์ชันกันครับ)

ปัญหาเรื่องการเล่นไฟล์เพลงให้ลูปใน SDL_mixer

SDL_Mixer จริง ๆ มีคำสั่งที่ใช้เล่นไฟล์เพลงอยู่ครับ และเราสามารถสั่งให้มันลูปได้ด้วย โค๊ดก็ประมาณนี้

auto music = Mix_LoadMUS("./songs/2.04. Heartbeat, Heartbreak.ogg");
Mix_PlayMusic(music, -1);

ซึ่งสิ่งที่มันทำมันก็เหมือนกับที่ผมเล่าไปข้างบนนั่นแหละ เราเลยไม่ต้องมากังวลเรื่องการเติมบัฟเฟอร์ การสลับบัฟเฟอร์ หรืออะไรทำนองนั้น

ปัญหาคือ มันเล่นตั้งแต่ต้นจนจบไฟล์ แล้วเริ่มที่จุดเริ่มต้นใหม่ครับ เราไม่สามารถกำหนดได้ว่าจะลูปจากตรงไหน และลูปไปตรงไหน

อ้อ SDL_mixer มีคำสั่งให้กรอเพลง (ใช้คำนี้ได้ไหม :-)) กลับไปยังตำแหน่งที่เราต้องการได้ แต่ดันไม่มีคำสั่งที่เช็คว่าเล่นไปถึงตำแหน่งไหนแล้ว ... เราก็เลยไม่สามารถใช้วิธีการเช็คตำแหน่งแล้วย้ายตำแหน่งได้จาก SDL_mixer ตรง ๆ ตรงนี้มีคนด่าเยอะเหมือนกันครับ แต่ว่าก็ไม่มีใครแก้ (ไม่รู้ทำไม ไม่ได้เช็ค)

ทางแก้ สำหรับคนที่ยังอยากให้ SDL_mixer

บอกก่อนว่าถ้าไม่อยากใช้ SDL_mixer ก็ทำได้ครับ แต่นั่นคือต้องเขียน mixer เอง เหนื่อยน่าดู อีกวิธีคือการเปลี่ยนไปใช้ API อื่นอย่าง OpenAL เลย (ผมเคยเล่าให้ฟังเมื่อ 7 ปีที่แล้วล่ะมั้ง ลืมละ)

โชคดีอย่าง SDL_mixer มีกลไกที่อนุญาตให้เราเติมบัฟเฟอร์ได้เอง ซึ่งเราจะไปถอดรหัสด้วยวิธีไหนมาจากอะไรก็ได้ แล้วแต่เราเลย ตรงนี้จะเป็นการใช้คำสั่ง Mix_HookMusic() แทนนั่นเอง ปัญหาคือใช้แล้วใช้คำสั่ง Play/Stop ไม่ได้นะครับ เรียกปุ๊บมันเล่นเลย เราต้องเขียนกลไกสั่งให้มันหยุดเอง แต่คำสั่ง Pause/Resume ยังใช้ได้นะ อันนี้ก็ต้องลองกันเอาเองดูนะครับ

ข้างล่างเป็นโค๊ดตัวอย่างครับ

OggVorbis_File vf;
ov_fopen("./songs/2.04. Heartbeat, Heartbreak.ogg", &vf);

Mix_HookMusic([](void *udata, Uint8 *stream, int len) {
  OggVorbis_File *pvf = (OggVorbis_File *) udata;
  const long int start_loop = 447151L;
  const long int end_loop = 3410688L;
  int bitstream;
  int read_total = 0;
  while (true) {
    if (read_total >= len) break;
    auto pos = ov_pcm_tell(pvf);

    if (pos > end_loop)
      ov_pcm_seek(pvf, start_loop);

    int read = ov_read(pvf, (char *) stream + read_total,
                       len - read_total, 0, 2, 1, &bitstream);
    read_total += read;
  }

}, &vf);

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

ผมใช้ตำแหน่งแบบ pcm ซึ่งจะนับจำนวน sample จากจุดเริ่มต้นจนถึงตำแหน่งที่เรากำหนดไว้ ซึ่งจะแม่นยำกว่าการใช้ตำแหน่งแบบเวลา (เช่น วินาที) แต่การจะได้ตำแหน่งนี้มานั้นคงต้องคุยกับ sound design ดี ๆ ล่ะครับ เราสามารถหาตำแหน่งของลูปได้จากโปรแกรมแก้ไขไฟล์เสียง แล้วก็โปรแกรมพวก DAW ครับ (ไฟล์นี้ผมใช้ Sound Forge Audio Studio 10 ที่แถมมากับแลปท็อปผมครับ ... น่าเสียดายที่ Sony ขาย Vaio ไปแล้วจริง ๆ )

2016-01-12 05_13_34-Greenshot

วิธีนี้จะใช้วิธีการเช็คตำแหน่งที่เราอยู่ในปัจจุบันก่อนที่จะสั่ง decode โดยถ้าเราเล่นเกินตำแหน่งลูปไปแล้ว ก็ให้กรอกลับไปยังตำแหน่งเริ่มต้นใหม่ วิธีนี้ยังค่อนข้างหยาบอยู่ เพราะว่าเราเล่น "เกิน" กว่าตำแหน่งลูปก่อนจะวนกลับไป (ตรงนี้จำเป็นเพราะว่าเราถอดรหัสไฟล์ออกมาเป็นข้อมูลก้อนใหญ่ ๆ ก้อนหนึ่งครับ ไม่ใช่ว่าเราโหลดราย sample เลย ดังนั้นมันจะโหลดมาเกินกว่าที่เราตั้งไว้) เป็นสาเหตุว่าทำไมในหลาย ๆ lib ถึงไม่การันตีว่ามันจะลูปที่ตำแหน่งที่เราตั้งไว้ด้วยครับ เพราะมันถอดมาเกินนี่ล่ะ แต่เท่าที่ผมลองฟังดูผมไม่รู้สึกว่ามันมีรอยต่อครับ อาจจะเพราะว่าเลือกจุด loop point ได้ดีด้วย (เป็นจุดที่ amplitude ค่อนข้างต่ำครับ)

อ้อ ถ้าเกิดว่ามันลูปมาไม่เนียน เราสามารถปรับตำแหน่ง loop in/out ได้ครับ โค๊ดตรงนี้ทำงานค่อนข้างเหมือนเดิมในแต่ละครั้ง ถ้าเรามั่วค่าได้ดีรอยต่อมันจะหายไปเอง

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

สุดท้ายคือ วิธีนี้ใช้ custom callback ในการโหลดข้อมูลเข้าบัฟเฟอร์ การที่จะรองรับ file format ต่าง ๆ นั้นเราต้องทำเองหมดเลย (ต่างกับการเล่นไฟล์ด้วยกลไกของ SDL_mixer เอง) ถ้าเราต้องการรองรับหลาย ๆ ฟอร์แมทนี่อาจจะเหนื่อยหน่อยนะครับ :-) ส่วนตัวผมแนะนำว่าให้ใช้แค่ฟอร์แมทเดียวกับทั้งโปรเจคดีกว่า จัดการง่ายกว่าครับ

สุดท้ายทิ้งท้ายด้วยไฟล์โค๊ดตัวอย่าง ลองเข้าไปดูเล่น ๆ นะครับ

ก่อนเริ่มขอนอกเรื่องนิด ไอ้เจ้าช่อง PG-Talk ที่ผมไม่ได้ทำมาตั้งครึ่งปีเนี่ย ผมคิดว่าน่าจะได้กลับมาทำในเร็ว ๆ นี้ครับ เพิ่งเคลียร์อะไรหลาย ๆ อย่างไปก็เลยว่าจะกลับมาทำต่อ

เรื่องที่จะเล่าวันนี้เป็นเรื่องนึงที่ผมคิดระหว่างการขับรถกลับบ้าน (อันตรายครับไม่ควรทำ 55) ก่อนจะเริ่มไปถึงจุดที่ผมว่าผมขอเล่าให้ฟังนิด คือได้ยินว่าในหลาย ๆ องค์กรมักจะวาง ecosystem ของระบบไอที ทั้งที่เป็นแบบให้บริการภายในบริษัทเอง หรือเป็นที่ให้บริการลูกค้า ตาม "ผลิตภัณฑ์" ที่แต่ละคนทำงานอยู่ ซึ่งไอ้เจ้า "ผลิตภัณฑ์" ที่ว่านี้นั้นสร้างจากเทคโนโลยีที่แตกต่างกัน เช่น ตอนแรกสร้างแอพเป็นคอนโซล เขียนด้วยภาษาดาต้าเบส (PL/SQL ?) แล้วต่อมาก็สร้างระบบ UI เป็น Windows ด้วยภาษา C++ หลังจากนั้ันก็พัฒนา web frontend ด้วย Python หรืออะไรก็ว่าไป ซึ่งฟังดูผ่าน ๆ มันก็เหมาะสมดีนะ เอาคนที่ทำงานคล้ายๆ กันมาอยู่ด้วยกัน มีอะไรก็แทนกันได้

บางที่ถึงขั้นว่า ทีมข้างบนทำแต่โปรเจค ถ้ามีปัญหาอะไร มีอีกทีมนึงสำหรับซัพพอร์ตลูกค้าโดยเฉพาะ จะได้บริการได้อย่างรวดเร็วขึ้น ... จากประสพการณ์ส่วนตัวผมพบว่าการแยกทีมซัพพอร์ตออกมาทำให้งาน "ช้าลงอย่างเห็นได้ชัด" ครับ อันนี้ไม่พูดถึงนะว่าทำไม

กลับมาต่อ ผมบอกว่าดูเหมือนมันจะเหมาะสมใช่ไหมครับ ? ปัญหาคือหลาย ๆ ครั้งที่ผลิตภัณฑ์มีส่วนที่ทับซ้อนกัน และการ implement ระบบเพื่อขึ้นมารองรับตัว functionality นั้น ๆ ก็ต่างคนต่างทำ ทำให้มันไม่ไปในทิศทางเดียวกัน ... และถ้าผลิตภัณฑ์หนึ่งมีปัญหา ก็จะแก้ไขกันที่ผลิตภัณฑ์นั้น ๆ ตัวเดียว ไม่มีใครยืนยันว่าผลิตภัณฑ์อื่น ๆ ที่ให้บริการแบบเดียวกันจะมีปัญหาด้วยหรือไม่ ...

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

ระหว่างที่ขับรถผมก็คิดว่า แล้วทำไมเราถึงไม่แบ่งตาม "functionality" ของตัว ecosystem แทนล่ะ ? เช่นสมมติเราทำระบบธนาคาร ก็มีส่วนงานหนึ่งดูแลแต่เรื่องข้อมูลส่วนที่ไม่ใช่การเงิน (เช่นพวกที่อยู่) อีกส่วนงานหนึ่งดูแลเรื่องการประมวลผล transaction (transaction processing) อีกส่วนงานหนึ่งดูแลเรื่องระบบสร้าง transaction ไป และอื่น ๆ ... คือมันก็เหมือนกับการแบ่งงานให้คนทำล่ะครับ ทำตามหน้าที่ของตัวงาน ไม่ใช่แบ่งตาม เอ่อ ... "สถาบันการศึกษา" หรืออะไรคล้าย ๆ กันนั่นล่ะครับ (ถ้ามองว่าคนงานคือตัวแผนกงานที่ทำ function ต่าง ๆ ผมว่าตัวภาษาที่ใช้สร้างตัวชิ้นส่วนที่ทำงานตรงนั้นก็คล้าย ๆ กับสถาบันการศึกษาที่สร้างคนงานมานั่นล่ะมั้ง ? 555)

เหตุผลเบื้องหลังคือ ผมคิดว่าคนที่ทำงานด้านเทคโนโลยี สามารถปรับตัวให้รับกับความเปลี่ยนแปลงและความหลากหลายทางเทคนิคได้อยู่แล้วล่ะครับ (ถ้าทำไม่ได้ก็อาจจะต้องพิจารณาเรื่องการเปลี่ยนงานดูล่ะมั้ง) แต่เรื่องของ business functionality เนี่ยมันมีความซับซ้อนและความกำกวมมากกว่า มีเรื่องให้เรียนรู้มากกว่า ดังนั้นถ้าสามารถแบ่งให้ออกเป็นส่วนย่อย ๆ แล้วให้คนเรียนเฉพาะส่วนนั้น ทำงานเฉพาะส่วนนั้น ก็น่าจะทำงานได้อย่างมาประสิทธิภาพมากกว่า

คราวนี้ก็จะมีคนสงสัยว่า อ้าว ถ้าต่างคนต่างดูแล function ของตัวเองแล้วมันจะเชื่อมโยงได้อย่างไร ถ้าเป็นในอดีตก็ยากครับ อาจจะมีการปิดโปรแกรมโน้นเปิดโปรแกรมนั้น เพราะว่าแอพบนเดสก์ท็อปจะมีความเชื่อมโยงกันน้อย แต่เราอยู่ในยุคที่เว็บครองเมืองแล้วใช่ไหมครับ ? แต่ละทีมก็สร้างผลิตภัณฑ์แบบเว็บ ใช้วิธีที่แตกต่างกันหรือเหมือนกันก็ได้ (เหมือนกันดีกว่าครับ) ของใครของมันไปเลย แต่สามารถเชื่อมโยงถึงกันได้ แชร์ session id กันได้ สามารถสลับไปมาระหว่างผลิตภัณฑ์โดยที่ผู้ใช้ไม่รู้ตัว (แบบเดียวกับ Google -> Google Drive -> GMail -> Google Docs อะไรทำนองนี้ล่ะครับ) คราวนี้ต่อให้เป็นซอฟต์แวร์ที่แยกขาดออกจากกันก็ยังสามารถทำงานร่วมกันได้ ผู้ใช้ไม่รู้ตัว อ้อ วิธีนี้มีข้อดีอีกอย่างคือสามารถขายแยกส่วนได้ครับ เพราะมันไม่อิงซึ่งกันและกันนั่นเอง

อีกอย่างที่สำคัญคือ ถึงจะบอกให้แยกตาม functionality แล้วก็จริง แต่ละฟังก์ชันก็ควรจะทำงานร่วมกันได้ แต่ละทีมควรจะมี API เพื่อเรียกใช้ฟังก์ชันของทีมตัวเองได้ อาจจะเป็น Web Service หรืออะไรก็แล้วแต่

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

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

2

ผมเริ่มรู้สึกรำคาญความอืดของ NAS ที่ใช้ก็เลยคิดว่าจะเปลี่ยน คือผมใช้ ZyXEL NSA210 มาก่อน (ก่อนหน้ามีอีกตัวแต่ขายทิ้งไปแล้ว) ก่อนสลับไปใช้ Raspberry Pi แล้วสลับกลับมาใช้ตัวนี้ ผมทำ Peak Data Transfer ได้ที่ราว ๆ 7MB/s ครับ ซึ่งถ้าก็อปปี้ไฟล์ใหญ่ ๆ เนี่ยมันต้องรอเป็นชั่วโมงเลยครับ

หลังจากที่หาข้อมูลอยู่สักพักผมก็ตกลงปลงใจกับเจ้า NSA325 ซึ่งก็เป็นรุ่นที่ใหม่กว่าของ ZyXEL ผมเลือกเจ้านี่ด้วยความคุ้มเงินครับ เพราะว่าถ้าจะเล่นตัวหรู ๆ อย่าง QNAP หรือ Synology เนี่ยราคามันจะแพงกว่ามาก (รุ่นที่สเปคเท่ากันราคาแพงกว่า 50%) และอีกสาเหตุนึงคือผมสามารถที่จะติดตั้ง Linux เข้าไปได้อย่างไม่ยากเย็นจนเกินไป (ใช้แค่ Thumb drive ตัวเดียวเอง)

ภาพจาก ZyXEL

ภาพจาก ZyXEL นะครับ

Spec

เจ้านี่เนี่ยสเปคมันจริง ๆ ไม่เลวเลย คือเป็น NAS สองช่องที่รอบรับ SATA I/II ความจุสูงสุด 12TB ใช้ CPU จาก Marvell (ตระกูล Kirkwood เป็น ARMv5 ครับ เก่าหน่อย) ความเร็ว 1.6GHz คู่กับแรม 512MB ถ้าเทียบกับเจ้า NSA210 แล้วสเปคสูงขึ้นมหาศาลเลยครับ (NSA210 ใช้ซีพียูความเร็วแค่ 200MHz) ซึ่งด้วยสเปคขนาดนี้ความสามารถมันก็ค่อนข้างดีทีเดียว

Spec ของ NSA325v2

อ้อ ตัวมันเองมีอินเตอร์เฟซ Gigabit Ethernet 1Gbps ครับ (ความเร็วตามสเปคนะ) และมี USB 3.0 1 ช่อง กับ USB 2.0 อีกสองช่อง ซึ่งเราสามารถเอา Thumbdrive ไปเสียบเพื่อก็อปปี้ไฟล์เข้าไปในเครื่องได้เช่นกัน

Set Up

สำหรับการติดตั้งนั้น เนื่องจากผมเลือกที่จะติดตั้งตัว Arch Linux ARM หรือ ALARM แทนที่จะใช้ Firmware เดิม ๆ ดังนั้นมันจะวุ่นวายนิดนึง โดยวิธีการนั้นสามารถเข้าไปดูที่เว็บของทางโครงการได้เลยครับ ซึ่งสิ่งที่ต้องใช้เพิ่มเติมนอกจากตัว NAS และ HDD ก็คือ Thumbdrive สักตัว ขนาดไม่ต้องใหญ่มากก็ได้ครับ (ผมใช้ Sandisk Ultra 16GB เพราะว่าที่บ้านมี)

ผมใช้ HDD เป็น Western Digital Red ขนาด 2TB หนึ่งตัว ไม่ได้ต่อ RAID นะครับ ทั้งนี้การใช้ Arch Linux นั้นเราไม่จำเป็นว่าจะต้องต่อ RAID ในกรณีที่ใส่ HDD ครบสองช่อง (ไม่เหมือนตัว Stock Firmware) ดังนั้นเราจึงสา่มารถใช้พื้นที่ของ HDD สองตัวรวมกันได้โดยที่ไม่เสี่ยงกับปัญหาข้อมูลเสียหายเพราะ HDD ตัวใดตัวนึงพัง

หลังจากที่ติดตั้งเจ้า ALARM ไปแล้วเจ้า NSA นี้จะมีแค่ส่วนของระบบปฎิบัติการณ์เท่านั้น เราจะต้องคอนฟิกทุกอย่างเองทั้งหมด ซึ่งก็ทำเหมือนบน Arch Linux ปรกติทุกอย่างครับ การติดตั้ง Software จะใช้คำสั่ง pacman (package manager) ในการติดตั้งหรือถอดถอนโปรแกรม เช่น ถ้าจะติดตั้ง Samba เราก็พิมพ์ว่า

pacman -S samba

เป็นต้น

ทั้งนี้ตัวระบบปฎิบัติจะไม่มีส่วนของ Web GUI เลยนะครับ ทุกอย่างทำผ่าน Command Line หมด อาจจะเหนื่อยนิดนึง จริง ๆ มีทางเลือกอีกทางก็คือใช้ Debian แล้วรันเจ้า OpenMediaVault ซึ่งมี Web Interface แต่คราวนี้ผมเลือกจะใช้ ALARM เพราะว่า OMV เนี่ยจะไม่ให้ใช้ไดร์ฟระบบในการเก็บข้อมูลครับ (นั่นคือผมจะเสียที่ไปฟรี ๆ 2TB)

สำหรับโปรแกรมที่ผมติดตั้งไปนั้นหลัก ๆ ก็ตามนี้ครับ

  1. Samba (SMB/CIFS Filesharing สำหรับแชร์ไฟล์กับวินโดวส์)
  2. VSFTPD (FTP server)
  3. Lighttpd (HTTP server)
  4. GIT
  5. MiniDLNA (DLNA/UPNP server เอาไว้แชร์หนัง เพลง รูปถ่ายให้เครื่องอื่น ๆ ดู)
  6. Transmission (Bittorrent Client)

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

Test

ผมใช้ PC ที่มี Gigabit Ethernet (ใช้ชิพของ Realtek) กับ Router ของ Buffalo ที่เป็น Gigabit Ethernet 4 พอร์ต นะครับ ผมลองก็อปปี้ไฟล์ขนาด 42GB เข้าไปผ่าน Samba ก็สามารถทำความเร็วได้ที่ราว ๆ 35MB/s (ความเร็วสูงสุดประมาณ 40MB/s)

ทดลองโอนไฟล์

ถ้าดูกราฟจะเห็นว่าแทบจะไม่แกว่ง และอันที่จริงนอกเหนือจากที่ผมโอนไฟล์แล้ว ระหว่างการทดสอบผมก็กำลังดูหนัง Bluray ที่เป็นไฟล์ iso บน NSA นี่อยู่ครับ ผมเองก็ไม่แน่ใจว่าจริง ๆ แล้วมันติดที่ตัว Router เองหรือเปล่า เดี๋ยวคงต้องลองเปลี่ยนตัว Hub/Switch ที่ใช้ในการทดสอบดู นอกจากนี้แล้วก็มี HTTP Server กับ Bittorrent ที่กำลัง Seed อยู่ด้วยครับ (5 ไฟล์มั้ง ?)

อ้อ อีกอย่างคือระหว่างการโอนไฟล์ 2 session นี่ ระบบใช้ซีพียูแค่ราว ๆ 10% เองนะ ผมเดาเล่น ๆ ว่ามันน่าจะเร็วกว่านี้ได้อีกครับ ความเร็วระดับก็ถือว่าใช้ได้แล้วล่ะครับ เพราะปรกติไม่ค่อยโอนไฟล์ใหญ่ระดับ 40GB บ่อย ๆ อยู่แล้ว (ที่บ่อยกว่าคือระดับ 5GB)

Conclusion

สำหรับคนที่กำลังมองหา NAS ที่สามารถปรับแต่งได้ละเอียดสุด ๆ และสามารถใช้ Command Line ได้ ผมว่า NSA325v2 นี้ก็เป็นทางเลือกที่น่าสนใจครับ (ถึงแม้ว่าการลง Linux เองอาจจะทำให้หมดประกันก็เถอะ) ที่ค่าตัวประมาณสี่พันกว่าบาทปลาย ๆ กับความสามารถระดับนี้นั้นผมว่าคุ้มค่าทีเดียว

ปล. HDD ต้องซื้อเพิ่มนะครับ ไม่แถมนะ

2015-05-29 06_41_42-ZipPicView - idol-kinouchi-akiko-1334112557-BOBX.zip

หายหน้าไปนานนนน จนโฮสต์หมดอายุ 55 ขออภัยทุกอ่าน วันนี้จะขอแชร์แอพที่เขียนเล่น ๆ ในช่วงอาทิตย์ที่ผ่านมาครับ ชื่อว่า ZipPicView คือเจ้านี่เนี่ยมันเกิดจากความที่ผมมีไฟล์รูปอยู่ใน Zip อยู่จำนวนหนึ่ง (ไม่เยอะหรอกครับ มีอยู่ประมาณ 120GB :-)) ไอ้ครั้นจะแตกไฟล์มันออกมาก็ขี้เกียจ เพราะว่ามันเยอะ แต่โปรแกรมดูรูปในไฟล์ Zip ส่วนใหญ่มันออกแบบมาไว้อ่านการ์ตูน มันจะเอาไฟล์ย่อย ๆ มาเรียงกันหมดเลยโดยไม่สนใจว่าโครงสร้างของ directory เป็นยังไง (ส่วน Zip Folder ก็ทำงานได้ห่วยเกินทน)

ทางเลือกที่มีอีกทางคือ ACDSee ซึ่งก็ราคาพันกว่าบาท

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

ZipPicViewWeb

2015-05-30 20_14_50-View Zip

เริ่มแรกผมเริ่มจากเวอรชันเว็บก่อน เพราะว่า คือ ... สมัยนี้อะไรก็เป็นเว็บไปหมด ผมก็เลยคิดถึงเว็บก่อนครับ ในตอนแรกสุดเลยผมว่าจะลองวิธีที่เดี๋ยวนี้เขานิยมกัน ก็คื่อการเขียนเว็บด้วย Node.JS แต่ว่า ด้วยความที่ Node.JS โปรเซสไฟล์เป็น Stream มันไม่เหมาะกับงานที่ผมใช้ (Zip File ออกแบบมาเป็น random access ครับ ต้องอ่านถึงท้ายไฟล์ถึงจะสามารถดึงเอา content ไปใช้ได้)

ก็เลยเปลี่ยนมาใช้ Java Backend แทน แต่ก็ไม่ได้เขียนเป็น Servlet หรอกครับ ผมใช้ Application Server จาก Eclipse ที่ชื่อว่า Jetty ในการพัฒนาครับ ตัวโปรแกรมไม่ได้มีอะไรมากเลย มันประกอบไปด้วยสองส่วน ก็คือหน้าที่สำหรับ browse หาไฟล์ zip ในเครื่อง (Host) กับหน้าสำหรับลิสต์ชื่อไฟล์รูปภาพใน zip file เท่านั้นเอง

ส่วนวิธีดูรูปนั้นใช้วิธีการดาวน์โหลดรูปลงมาที่เครื่องตรง ๆ เลยครับ ซึ่งมันจะแสดงผลใน browser ได้พอดี

2015-05-30 20_32_54-(JPEG Image, 1200 × 1800 pixels)

ก็ถือว่าใช้ได้ตามที่ต้องการพอดี

แอพตัวนี้ฝั่ง backend เป็น java อย่างที่ผมบอกไป แต่ฝั่ง frontend เนี่ยเป็น HTML5 (HTML + CSS +JS) ล้วน ๆ ครับ ไม่มี server-side script/app แม้แต่น้อย เป็นความตั้งใจเพราะมันเป็นเรื่องที่จะฝึกนี่ล่ะ

  • CSS เป็น Pure CSS
  • JavaScript เป็น jQuery เป็นหลักครับ แล้วก็มี lib อื่น ๆ อีกพอสมควร

ทีนี้ มาคิดอีกที ... เปิดดูอยู่คนเดียว ก็ไม่ได้ว่าจะแชร์ให้ใครดู ก็เลยเขียนเวอร์ชัน Desktop ขึ้นมาอีกตัวครับ

ZipPicViewDsk

ZipPicViewDSK เป็น Java Swing App ที่ทำงานเหมือนข้างบน (โดยหลักการนะครับ โค๊ดสองโปรแกรมไม่มีแชร์กันเลย 555) แต่จะตัดตัว file browser ออกไป (ใช้ open file dialog แทน) และเพิ่มตัวดูรูปเข้ามา

2015-05-30 20_13_04-ZipPicView - idol-arimura-kasumi-1376238044-BOBX.zip

Look and Feel ที่ใช้คือ Substance ครับ เพิ่มความหรูหราให้กับโปรแกรมได้มากมาย

2015-05-30 20_13_27-ZipPicView - idol-arimura-kasumi-1376238044-BOBX.zip

สุดท้ายแล้วผมว่า ถ้าเรามีอะไรที่อยากได้ เราสามารถลงมือทำเองได้ถ้าดูแล้วไม่ยากเกินไปครับ และได้เป็นการฝึกฝีมืออีกด้วย ที่ทำนี่จริง ๆ ไม่ได้ยากเลย

ทั้งนี้ขอขอบคุณองค์กรดังต่อไปนี้ครับ

  • Eclipse Foundation สำหรับ Eclipse IDE, Jetty Application Server, Xtend Programming Language
  • Apache Foundation สำหรับ Apache Commons Archive, Apache Ivy

และ library อื่น ๆ ที่ถูกใช้งานในโปรดักท์นี้ครับ

โค๊ดทั้งหมดถูกแชร์ขึ้นไปบน Github ด้วย License MIT License นะครับ เอาไปใช้เล่นกันได้ตามสะดวก

คิดว่าบางคนคงจำเรื่องดราม่า ที่มีคนจ้างศิลปินชาวญี่ปุ่นมาเอาต้นไม้อายุร้อยกว่าปีไปสร้างสรรค์ผลงานศิลปะ แล้วอ.เฉลิมชัยแกออกมาโต้บอกว่า "คนไทยไม่รู้อะไร มันเป็นงานศิลปะ โคตรคุ้ม" คืออ้างอิงจากสัมภาษณ์ที่ลงไทยรัฐก็แล้วกันนะครับ

อ.เฉลิมชัย ศิลปินผู้มีชื่อเสียง เริ่มเรื่องจากการเล่าถึงศิลปะของคนไทย ว่า โดยปกติแล้วนั้น คนไทยไม่มีพื้นฐานที่จะเข้าใจในเนื้องานศิลปะได้ แต่จะเข้าใจเพียงว่า งานศิลปะที่มีคุณค่า อันจะบ่งบอกว่าศิลปินผู้นั้นมีฝีมือสูง ต้องเป็นงานศิลปะที่มีความสวยสดงดงาม ต้องวาดเขียน หรือแกะสลักไม้ออกมาด้วยความประณีต ฉะนั้น เมื่อคนไทยมาเจองานศิลปะของ ดร.กมล ทัศนาญชลี ศิลปินแห่งชาติ สาขาทัศนศิลป์ แล้ว สมองสั่งการของคนไทยจะคิดไปในทันทีว่า “งานแบบนี้ ลูกกูก็ทำได้ เตี่ยกูก็ทำได้ หมาก็ทำได้ เอาต้นไม้สวยๆ มาตัดเป็นท่อน กูว่าต้นไม้ก็อยู่ของมันดีๆ ยังสวยกว่าเอามาตัดอะไรแบนี้ นี่มันทำลายธรรมชาติชัดๆ แต่ถ้าพี่กมล เอาต้นไม้ที่ว่านี้ มาตัดเป็นเรือสุพรรณหงส์ พญาครุฑ หรืออะไรก็ตามแต่ที่เป็นงานไทย เชื่อสิ ไม่มีใครเขาด่า จะมีก็แต่ชื่นชม และไม่มีใครเสียดายต้นไม้ ส่วนผลงานของพี่กมลนั้น ไม่ใช่ไม่สวย แต่นี่เป็นความสวยแบบ abstract (นามธรรม) สวยที่รูปอารมณ์ ไม่ใช่สวยที่รูปร่าง” อาจารย์เฉลิมชัย ชี้แจงโผงผางตามสไตล์

อืม ... ศิลปะเอง คนที่จะมองก็ต้องเป็นคนที่มีพื้นฐาน เป็นคนที่มีความเข้าใจ

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

สมมติอย่างเช่นเวลาที่มีคนเปิดเพลงขึ้นมาสักเพลงนึงในห้างสรรพสินค้าละกัน คนที่เดินผ่านไปผ่านมาก็อาจจะคิดว่า

  1. เพลงนี้เพราะจัง
  2. ทำนองเพลงนี้แปลกดี
  3. เอ๊ะ เทนชันตรงนี้สวยดีแฮะ
  4. หืม ท่อนส่งกลองตรงนี้เจ๋งดี
  5. เนื้อเพลงท่อนแรกก็สวยดี แต่ท่อนหลังมันดันไปแจ้งกับท่อนแรกซะงั้น เล่นคำมากไปหน่อยมั้ง
  6. มิกซ์มาไม่ดีเลย เสียงมันกลืน ๆ กันไปหมด
  7. เครื่องเสียงมีปัญหาหรือเปล่าเนี่ย ??

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

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

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

ทั้งนี้ผมก็พยายามมองแบบเลี่ยง ๆ ไม่ให้รู้ตัวนะ เกรงใจ 555

ปล. ทำไมจบโรคจิตได้ขนาดนี้นะ

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

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

ถ้าถามเรื่องนี้กับหลาย ๆ คนก็จะมีคนบอกว่า บ.เล็กท้าทายกว่า เติบโตเร็วกว่า บ.ใหญ่มั่นคงกว่า สวัสดิการดีกว่า ฯลฯ แต่ถ้าถามผมผมจะตอบว่า...

บ.ใหญ่มีคนเยอะกว่าบ.เล็ก ...

/me ได้ยินเสียงใครสักคนล้มโต๊ะ

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

หรือถ้าดูกันที่เรื่องของ facility เนี่ย คุณก็จะบอกว่า บริษัทใหญ่ ๆ มีออฟฟิศหรู ๆ มีห้องอาบน้ำ มีเครื่องถ่ายเอกสาร ผมก็จะบอกว่า บริษัทเล็ก ๆ จะมีคอมพิวเตอร์ดีกว่า มีอุปกรณ์ดีกว่า

นึกภาพออกหรือยังครับ บริษัทใหญ่จะมีสิ่งที่ "ใช้ร่วมกัน" ดีกว่า ในขณะที่บริษัทเล็กๆ จะมี "ของส่วนตัว" ดีกว่า นั่นเอง นั่นเพราะของส่วนรวมดี ๆ นั้น ยิ่งมีคนใช้เยอะมันจะยิ่งถูกครับ (ลองคิดเล่น ๆ ก็ได้ ประกันสุขภาพกลุ่มแบบ 12 คน กับแบบ 120 คนราคาต่อหัวมันจะต่างกันมากขนาดไหน) ในทางกลับกันไอ้ของปลีกเล็ก ๆ น้อย ๆ เนี่ยยิ่งมีเยอะมันก็จะยิ่งแพง

ทำไมมันถึงยิ่งแพง เอาแบบนี้ก็ได้ สมมติว่าในออฟฟิศมีคอมพิวเตอร์ 20 เครื่องนะครับ สิ่งที่ต้องมีคือ คอมพิวเตอร์ 20 ชุด สวิตช์ 24 พอร์ต แล้วก็เราท์เตอร์สักตัวนึง พอละ ในทางกลับกันพอเป็นคอมพิวเตอร์ 200 เครื่อง จะบอกว่าใช้ คอมพิวเตอร์ 200 ชุด สวิตช์ 240 พอร์ต ต่อเข้าเราท์เตอร์ 10 ตัว มันก็ประหลาดใช่ไหมครับ (สามสายก็เยอะแล้ว) และต่อให้ทำแบบนี้สิ่งที่ต้องมีเพิ่มขึ้นมาคือฝ่าย Infrastructure คอยดูแลไม่ให้ระบบล่ม ในขณะที่ไอ้คอม 20 เครื่องเนี่ย ผู้จัดการบริษัทคนเดียวก็ดูแลได้

หรือ ไอ้ห้องอาบน้ำ ห้องนี้มันไม่ได้ใช้พร้อมกันทุกคนในออฟิศ เขาก็แบ่ง ๆ กันใช้ บางคนก็ไม่ใช้ ใช่ไหมครับ ดังนั้นสร้างสักห้องเดียวก็พอสำหรับคน 120 คน ในทางกลับกันถ้าเรามีคนแค่ 12 คน จะสร้างแค่ 0.1 ห้องมันก็ทำไม่ได้ใช่ไหมครับ (ว่าแต่ถ้าใครรู้วิธีสร้างห้องอาบน้ำ 0.1 ห้องนี่ก็มาเล่าให้ฟังกันด้วยก็ดีนะครับ)

อีกเรื่องนึงที่จริง ๆ ดูเหมือนจะสำคัญกว่า ก็คือ ... การมีส่วนร่วมครับ คือ สำหรับบริษัทที่มีคน 12 คน สมมติว่าบริษัทมีนโยบายอะไรใหม่ เรียกประชุมคุยกันเสร็จ ถ้าคุณมีข้อโต้แย้ง คุณก็แย้งได้เลย คนที่จะฟังคุณก็ยืนอยู่ตรงนั้น ไม่มีปัญหา แต่พอเป็นบริษัทที่มีคน 120 คุณ สมมติว่าคุณมีข้อโต้แย้ง คุณจะไปแย้งให้ใครฟัง ? แย้งให้คนที่มาบอกคุณ เขาก็รับนโยบายมาอีกที (ซึ่งบางครั้งเจ้าตัวก็ไม่ได้รู้เรื่องอะไร และอีกหลายครั้งที่ก็ไม่ได้อยากรับมาหรอก) ซึ่งเขาก็มักจะทำอะไรไม่ได้เหมือนกัน (ผู้บริหารระดับกลางมักจะเป็นไส้แซนด์วิชครับ ดังนั้นหลาย ๆ ไม่อยากเป็น อยากเป็นเจ้าของมากกว่า) ไอ้ครั้นจะไปแย้งกับคนที่เขียนนโยบาย ... คนไหนล่ะที่เขียน ? แล้วเขาจะฟังคุณเหรอ ? คือนอกจากที่ว่าคุณเป็นแค่ 1/120 เสียงแล้ว มันจะมีเรื่องของลำดับขั้นเพิ่มเข้ามาอีก (ก็เหมือนกับสังคมขนาดใหญ่นั่นล่ะครับ)

และในทางกลับกันอีก สำหรับบริษัทที่มีคน 120 คุณ ถ้าเกิดว่าคุณดันทำงานแล้วมีปัญหาส่งงานไม่ได้ตามที่กำหนด ตัวโครงการมักจะยังพอไปได้ หรืออาจจะมีคนมาแทนคุณได้ บริษัทคุณก็คงจะมีปัญหาบ้างแต่ไม่ได้หนักหนาอะไร เพราะคุณมีความรับผิดชอบแค่ 1/120 ของทั้งบริษัท ในทางกลับกันถ้าเป็นบริษัทที่มีคนแค่ 12 คน ถ้าคุณปิดงานไม่ได้คนเดียว บริษัทอาจจะเจ๊งได้ หรืออาจจะเกิดความเสียหายขั้นรุนแรงได้ (ผมเคยเห็นมากับตาแล้วครับกรณีนี้ เสียลูกค้าหลักไปเลยหนึ่งราย) นั่นคือ คุณมีความรับผิดชอบ 1/12 ของทั้งบริษัท (เทียบกับไอ้ไม่ถึง 1% ของแบบแรกแล้วคนละเรื่อง)

พอเอาสองอย่างมารวมกัน เขาถึงเรียกว่า อำนาจมาพร้อมกับความรับผิดชอบไงล่ะครับ

จะว่าไป 120 คนนี่ก็ไม่ได้ใหญ่โตอะไรเลยนะ หลาย ๆ บริษัทมีคนหลักแสนมีสาขาอยู่ทั่วโลกด้วยซ้ำ ลองคิดดูละกันว่ามันจะเป็นแบบไหน (แต่ส่วนใหญ่แต่ละสาขาย่อยในแต่ละประเทศเขาจะมองว่าเป็นคนละองค์กรกันนะ)

ส่วนเรื่องอื่น ๆ ผมว่าจริง ๆ มันเป็นเรื่องเฉพาะกับบริษัทมากกว่า อย่าง บ.จะเล็กหรือใหญ่ก็มีเรื่องการเมืองได้ทั้งนั้น บ.เล็กอาจจะไม่โปร่งใส บ.ใหญ่กลับโปร่งใสอย่างคาดไม่ถึง (พิจารณาอะไรทุกคนรู้ร่วมกันหมด) หรือ เอ่อ ผลประกอบการ บริษัทที่มีขนาดเล็กกว่าสิบเท่าอาจจะมีผลประกอบการดีกว่าบริษัทใหญ่ก็ได้ (ผมว่าผมรู้จักบ.ที่มีกำไรมากกว่าสายการบินบางแห่งมากเลยนะ :-)) หรือแม้กระทั่งเป็นคู่แข่งในงานด้านเดียวกัน ทำธุรกิจแบบเดียวกัน บ.ที่เล็กกว่าอาจจะมีผลประกอบการดีกว่าก็ได้

ก็สรุปง่าย ๆ แหละว่า บ.เล็กกับบริษัทใหญ่ นั้นมีจำนวนคนนี่แหละเป็นรากฐานของความแตกต่าง เท่านั้นแหละ

ช่วงนี้เน้นทำคลิปเลยไม่ค่อยเขียนบล็อกเท่าไหร่ ถ้าใครต้องการสาระด้านบวก ลองดูคลิปดูนะครับ ส่วนใน Blog บางทีมันจะดาร์ก ๆ หน่อย :)

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

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

ดังนั้นมันไม่ได้ผิดอะไรเลยที่เราไม่รู้

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

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

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

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

แต่ถ้าไม่สนใจที่จะเรียนรู้ก็ฟังอธิบายให้จบก็พอแล้ว ไม่ต้องมาทำเสียงไม่พอใจใส่ก็ได้ ใช่ไหมครับ

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

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

ช่วงนี้น่าจะเห็นผมไม่ค่อยเขียนบล็อกเท่าไหร่ เหตุผลคือผมมีช่องทางที่จะสื่อความคิดของผมออกไปอีกทางนึง และนั่นก็คือ PG-Talk ครับ

PG-Talk เป็นช่องบน YouTube ที่ีผมตั้งขึ้นมาจากคำถามที่ว่า ถ้าย้อนกลับไปสัก 10 ปี ถึงตอนที่ยังเป็นนักศึกษาปีสุดท้าย เราควรจะเรียนอะไรเพื่อที่สามารถพัฒนาตัวเองในสายอาชีพได้ ช่องนี้จะเป็นการรวมเอาความรู้ต่าง ๆ ที่ผมเรียนรู้ในระหว่างการทำงานตลอด 9 ปีที่ผ่านมา เอามาเล่าให้ฟังในภาษาไทยเพื่อที่จะสื่อให้กับคนที่ต้องการจะเริ่มต้นได้รู้และเข้าใจได้โดยไม่ต้องมานั่งแปลภาษาอังกฤษกลับมาเป็นไทยอีกที

ตอนนี้มีอยู่ทั้งหมด 4 ตอน ซึ่งก็จะพยายามอัพเดตให้ได้อาทิตย์ละตอนเป็นอย่างน้อยครับ

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

ท่านใดที่สนใจก็รบกวน Subscribe กันหน่อยนะครับ แล้วก็กรุณาอย่าปิดโฆษณานะครับ ถ้าเกิดรายได้ดีผมอาจจะเลิกงานประจำไปเลยก็ได้นะ (คงยาก 555)

1

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

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

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

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

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

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

ดังนั้นผมคิดว่าการสร้างวัฒนธรรมเพื่อสนับสนุนความแตกต่างนั้นจึงเป็นเรื่องที่สำคัญเหมือนกันนะ

ในหนังสือ How Google Works เขียนไว้ว่า ที่ Google จะมีการสนับสนุนให้พนักงานแต่ละคนใช้เวลาทำงาน 20% ไปกับการทำโปรเจคที่ไม่ได้เกี่ยวกับงานของตัวเองโดยตรง โดยโปรเจคที่ว่านั้นพนักงานเป็นคนเสนอและผ่านการรับรองจากผู้บริหาร และนั่นเป็นหนึ่งในวิธีการสนับสนุนการสร้างวัฒนธรรมที่สนับสนุนการเปลี่ยนแปลง (ผมเคยบอกแล้วว่าไม่ใช่มีแต่ Google ที่ทำนะ แต่เท่าที่ได้ยินมาก็มีน้อยมากที่มีวัฒนธรรมที่สนับสนุนความเปลี่ยนแปลงแบบนี้)

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

สำหรับคนเก่งแต่ไม่แกร่งพอ โลกองค์กรมันอยู่ยากครับ บอกตรง ๆ

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

อย่างสมมติ คุณบอกว่าจะนำเอา CouchDB (เป็นระบบ database แบบไม่มีความสัมพันธ์) เข้ามาแทนที่ MySQL เพราะสามารถดูแลได้ง่ายกว่า และใช้คนพัฒนาน้อยกว่า (อาจจะเพราะตัวผลิตภัณฑ์เป็น Web และใช้ JavaScript เป็นหลักอยู่แล้ว) คุณจะถูกต่อต้านจากฝั่งเทพ SQL ทันที ทั้ง ๆ ที่ยังไม่มีใครศึกษาข้อดีข้อเสียด้วยซ้ำ เพราะกลายเป็นว่าเขาต้องศึกษาภาษาใหม่ทั้งหมด (ทั้งนี้คนกลุ่มนี้หลายคนเขียนอะไรไม่ได้เลยนอกจาก SQL Query เพราะภาษามันเฉพาะทางมาก) และในระยะยาวเขาอาจจะทำไม่ได้และถูกบีบจนต้องลาออกไปก็ได้ และนี่ถ้าคุณดันไปเสนอให้เปลี่ยนจาก PHP เป็น Node.JS พร้อมกันเลยล่ะก็ คุณอาจจะไม่ได้กลับบ้านอีกเลยก็ได้นะ

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

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

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

สวัสดีปีใหม่ทุกท่าน ปี 2015 แล้ว ใครที่ยังมีอะไรติดค้างมาจากปีที่แล้วก็ขอให้สะสางให้ได้หมดนะครับ เพราะว่ายังจะมีอะไรอีกมากมายที่จะเข้ามาในปีใหม่ ๆ นี้

เอ๊ะ จริง ๆ มันก็เป็นปีนี้ไปแล้วเนอะ

วันนี้พูดถึงสิ่งที่เรียกว่า "การยอมรับ" สักหน่อย คือ ผมจะไม่บอกนะว่ามันคืออะไร เพราะเอาจริง ๆ ผมก็ไม่รู้ (ฮา) แต่จะเล่าเรื่องของตัวเองให้ฟังละกัน

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

มึงเป็นใครมาสั่งกู

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

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

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

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

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

ผมคิดว่าก่อนที่จะทำตามคำสั่งใครคุณต้องสามารถยอมรับคำสั่งนั้นได้ก่อน ถ้าเกิดว่าคำสั่งที่ไม่น่าเชื่อถือ หรือเป็นคำสั่งที่แย้งกับกฎข้อต่าง ๆ คุณก็มีหน้าที่ที่จะปฎิเสธ เช่น คุณต้องปฎิเสธเวลามีคนมาขอยืม user id และ password ของตัวเคุณ ไม่ว่าเขาจะเอาไปทำอะไร และไม่ว่าเขาจะเป็นใครก็ตาม (เพราะมันเป็นการผิดกฎและข้อบังคับด้านความปลอดภัยอย่างชัดเจน)

และคุณเองก็คงจะยอมรับคนลักษณะนี้น้อยลงด้วยเช่นกัน เพราะเป็นผู้ที่พยายามทำให้คุณเดือดร้อนนั่นแหละ

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

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

ทั้งนี้การเป็นที่ยอมรับนี่ นอกจากเรื่องพวก ... เอ่อ คุณวุฒิ วัยวุฒิ หรืออะไรพวกนั้นนี่ จริง ๆ เรื่องของการประพฤติตัวนี่ก็มีผลมากนะ คนที่ดูท่าทางน่าเกรงขาม ทำตัวเหมือนกับข่มขู่คนอื่นตลอดเวลานี่ จะมีคนฟังแทบจะตลอด (ด้วยความกลัว อารมณ์ประมาณ "จ้าวแห่งหมัด" นั่นแหละ 55) ทั้ง ๆ ที่จริง ๆ เขาอาจจะเป็นคนไม่มีความสามารถอะไรเลย (เอาเข้าจริง ๆ หลาย ๆ คนที่ต้องทำตัวข่มขู่คนอื่นตลอดนี่ก็เพราะไร้ความสามารถนั่นแหละ) แต่คนที่มีทั้งบารมี ดูน่าเกรงขาม และมีความสามารถจริง ๆ ด้วยนี่จะเป็นคนที่ดูน่ากลัวและมีพลังวัตรสูงส่งมาก แค่มองหน้าก็สั่นไปทั้งตัวละ 555

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

ทั้งนี้ผมไม่ค่อยชอบเรื่องการใช้กำลังเท่าไหร่น่ะ รู้สึกว่ามันไม่ใช่ตัวเอง ผมชอบพิสูจน์ด้วยความสามารถมากกว่า (จริง ๆ คือไม่มีกำลังให้ใช้ 555 ไม่ชอบออกกำลังนิ) ซึ่งก็ไม่ค่อยมีเหมือนกัน (อ้าว...)