วันอาทิตย์ที่ 28 กุมภาพันธ์ พ.ศ. 2559

แนวทางสู่การเป็นโปรแกรมเมอร์ที่ผมเลือก

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

>> บ่อยครั้งที่ผมสับสน และมักมีคำถามทำนองว่า "ฉันจะเขียนโปรแกรมเป็นอาชีพหรือ?" ส่วนคำตอบที่ได้จากการพิจารณาของผมก็คือ "อาจจะ ถ้าทำได้" กล่าวคืออาจจะทำเป็นอาชีพ หมายถึงจริงจังกับมันไปตลอดชีวิตหรือใช้เวลาของชีวิตส่วนใหญ่กับมัน! ทีนี้จึงมีอีกความคิดหนึ่งผุดขึ้น "แล้วถ้าทำไม่ได้ล่ะ?" คำตอบของผมง่ายมากเลยครับ ทำไม่ได้ก็ไม่ต้องทำ ฮ่า (หัวเราะ)

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

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

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

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

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

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

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

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

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

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

3. ความคิด ความคิดที่ว่าคือความคิดในการมองปัญหา ว่าเกิดปัญหาอะไร แล้วก็ใช้ความคิดหาดูว่าจะจัดการกับปัญหาดังกล่าวได้อย่างไร ควรใช้เฟรมเวิร์ก (framework) ตัวไหนไปพิชิตปัญหา หรือต้องวางโครงสร้างหรือสร้างระบบย่อยอะไรออกมาเพื่อจะจัดการกับปัญหานั้นๆ อย่างนี้เป็นต้น, นอกจากนั้นแล้วความคิดนี้ยังใช้ในการศึกษาภาษาโปรแกรมรวมถึงเทคโนโลยีแต่ละอย่างด้วย ความคิดต้องนำก่อน ต้องรู้ว่าเราเลือกใช้ภาษานั้นนี้ด้วยสาเหตุอันใด (ได้เงินเยอะ! ตอบแบบนี้สมควรถูกตบกระบาลหนึ่งฉาดแรงๆ ฮ่า) หรือเลือกใช้เทคโนโลยี (เช่น หัวหน้าครับเราต้องใช้เว็บเซอร์วิส) นั้นๆด้วยเห็นว่ามันแก้ไขปัญหาจริงๆหรือไม่ เพราะทุกภาษาโปรแกรมรวมถึงทุกเทคโนโลยีที่เกิดขึ้น เขาประดิษฐ์เพื่อให้มาจัดการกับปัญหาแต่ละอย่าง งานแต่ละลักษณะ ในแต่ละช่วงเวลาที่แตกต่างกันครับ

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

>> สรุปว่ามีสี่ขั้นตอนที่ผมเลือกใช้สู่เส้นทางการเป็นโปรแกรมเมอร์ของผม
1. ภาษาอังกฤษ
2. ภาพรวมของทั้งระบบ
3. ความคิดนำ
4. โค้ดดิ้งตาม API ที่เลือก

ฝันดีจ๊ะ .zZ

วันพุธที่ 24 กุมภาพันธ์ พ.ศ. 2559

จริงใจและยอมรับความจริงที่ผิดพลาด

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

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

>> ตัวอย่าง
งานชิ้นนี้สำคัญต่อตำแหน่งของหัวหน้าทีม เมื่อเขาทำงานชิ้นนี้สำเร็จเขาจะได้รับโบนัสและเลื่อนตำแหน่งอย่างแน่นอน เราในฐานะลูกทีมก็ต้องคุยกันกับเขาว่าจะทำให้งานชิ้นนี้สำเร็จได้อย่างไร อุปสรรคคืออะไร
- เจี๊ยบเพิ่งเข้าทีมได้ไม่นาน เธอใหม่และปรับตัวไม่ได้กับทีมที่มีแต่ผู้ชาย เจี๊ยบมักกล่าวว่า พวกผู้ชายไม่เข้าใจผู้หญิง
- โจ๊กอยู่มานานกว่า มีหน้าที่สร้าง HTML ให้กับเว็บทุกหน้า (งานสมมติ) แต่เขาไม่เก่งพวก jQuery หรือ CSS เท่าใดเลย
- จั๊บเป็นซีเนียร์ของทีม หนุ่มโสดเลือดร้อนที่ชอบสาวสวย แน่นอนว่าเขาแอบมองเจี๊ยบเสมอโดยเฉพาะเวลาที่อ้างว่ากำลังคิดเรื่องอัลกอริทึม
- เจาคือมือเอกดีไซเนอร์ด้านรูปภาพล้วนๆที่จะต้องวาดภาพไปเสนอ User ก่อนจะนำรูปทั้งหมดมาแปลงเป็น HTML โดยฝีมือของโจ๊ก
- จูนคือหัวหน้าทีมครับและเขาเบื่อตำแหน่งนี้มาก เพราะเขาต้องคอยตอบคำถาม PM ว่าเมื่อไรงานจะเสร็จ ตอนนี้ไปถึงไหน อย่าให้งานมีแมลงไปซ่อนอยู่นะ และอย่าให้กระทบกับชิ้นอื่นๆที่ทำเสร็จแล้วก่อนหน้านี้ด้วย เมื่อจูนทำงานชิ้นนี้สำเร็จเขาก็จะได้เลื่อนตำแหน่งเป็น PM
- จูนจะเอาแบบที่ปรับแก้แล้วจากเจาไปปรึกษากับจั๊บ แบ่งงานให้โจ๊กกับเจี๊ยบวาด HTML ออกมาพร้อมกับจัดการลูกเล่นต่างๆด้วย jQuery และทำให้สวยขึ้นด้วย CSS แน่นอนว่าบางหน้าต้องใช้หน้าเก่าที่สร้างเสร็จไปแล้วมาเพิ่มเติมลิงค์และเนื้อหาบางส่วน อันนี้แหละที่ PM จะมาเตือนจูนบ่อยๆว่าให้ตรวจสอบและระวังหน้าเก่ามันพัง
...
- อีกสามรูปที่จะถูกเปลี่ยนเป็น HTML กำลังจะถูกนำมาทำ ปรากฏว่าเจาไปโม้กับ User ว่าของใหม่ที่กำลังจะได้นี้ทำให้เจ๋งยิ่งกว่าเดิมได้ แค่เพิ่มๆๆ หรือลดๆๆ หรืองี้ๆๆ แน่นอนว่า User ถูกใจมากกกกกกกกก พี่แกวิ่งมาหาจูนเลย บอกว่าให้เปลี่ยนเป็นแบบนี้นะ แบบนี้ๆๆ
- งานงอกแน่ๆถ้าทีมนี้ทำงานส่งไม่ทัน เพราะคุณ PM หัวผักกาดต้องมาอาละวาดพ่นไฟใส่เผาทั้งแผนกแถมฟ้องเจ้านายใหญ่ หากเหตุนี้เกิดขึ้นคงเดาได้ว่าอนาคตและความคาดหวังของหัวหน้าจูนจะเป็นเช่นไรจริงไหม
- จึงให้เกิดขึ้นไม่ได้! แต่จูนก็ไม่อยากปฏิเสธความต้องการของ User ซึ่งนั้นหมายถึงคำชื่นชมและชื่อเสียงมหาศาล เขารีบประชุมทีม แจงความต้องการ จากนั้นขอให้จั๊บอยู่คุยกับเขาต่อหลังการประชุมจบลง ทุบกําปั้นลงบนโต๊ะ เราต้องทำมันได้!
- แต่วันเสาร์จูนขอไม่มาทำงานเพราะได้ชวนเจี๊ยบดูหนังกินข้าวมันไก่ต้มไม่เอาหนังไว้แล้ว ใช่ครับ เหตุนี้สาวเจ้าจึงขอลาด้วยอีกคน
- ขาดคนมาทำงานวันเสาร์... งานต้องส่ง PM วันอังคารสิบโมงเช้า...
- วันเสาร์จึงเป็นโจ๊กนั่งทำงานอยู่ลำพัง ทั้งออฟฟิศเงียบเหงาได้ยินกระทั่งเสียงกระดาษหล่น น้ำตาพลันไหลอาบแก้มเด็กโง่ด้วยคนสวยของเขาไปดูหนังกับชายผู้มีความสามารถมากกว่า ทำอย่างไรล่ะนั่นซีเนียร์ทีมนะ จะเอาอะไรไปสู้ หน้าตาและเงินเดือนเขาก็ดีกว่ามากเลย
- โจ๊กทำงานไปก็ร้องไห้ไป เขาก็สร้างบั๊กบนขิ้นงานโดยไม่รู้ตัว... และทำงานส่วนของเจี๋ยบ เสร็จแล้วตอนตีห้าห้าสิบก็กลับบ้านไปนอน
...
- เช้าวันจันทร์ทุกคนกลับมาทำงานยกเว้นโจ๊ก เขาลาป่วยค่ะ เจี๊ยบบอกกับทีม เช้านี้เธอแต่งตัวสวยเหลือเกิน ราวกับว่าได้ไปประสบพบรักร้อนซ่อนเสน่หามาปานนั้น
- จูนกล่าวเบาๆกับจั๊บว่านายนี่สามารถเหลือร้าย งานเสร็จหมดแล้วจึงขอให้เขาช่วยตรวจสอบในฐานะซีเนียร์ทีม แต่จั๊บกลับขอให้เจี๊ยบทำแทน ซึ่งสาวเจ้ายินดียิ่งด้วยยิ้มหวาน
- โจ๊กแท้จริงไม่ได้ป่วย เขารู้สึกหนาวและโดดเดี่ยวอย่างบอกไม่ถูก คิดถึงเพียงเรือนผมสีบรอนทองยาวของเจี๊ยบกับหน้าขาวๆของเธอที่ปั้นให้บูดตลอดเวลาที่เขาสอนงานให้ ชอบหรือหรือว่ารักหนอ ทำไมปวดใจเช่นนี้นะ โทรศัพท์ไปหาแม่แม่ก็บอกติดป๊อกเก้าสามเด้ง
- เจี๊ยบส่งงานที่ตรวจให้จั๊บบอกว่าเรียบร้อยดีค่ะ จั๊บก็เอาไปบอกกับจูนว่าตรวจเสร็จแล้ว ทั้งสามหารู้ไม่ว่ามันมีบั๊กซ่อนอยู่ (บั๊กใจสลาย)
- จูนไปโม้กับเจาบอกว่างานนี้กระรอกมาก (กระจอก) มีให้ปรับแก้ตรงไหนไหม เจาดูผ่านๆบอกว่าไม่ต้องแล้ว เยี่ยมเลยบอกตง
- PM ก็มาถามความคืบหน้ากับจูนและงานของวันพรุ่งนี้ (อังคารเช้า) จูนก็ว่า no problem, it easy to solve haha
...
- เช้าของวันอังคารงานชิ้นนี้ก็ถึงมือ PM เขาตรวจความต้องการที่ส่งมาจาก User เมื่อเห็นว่าทุกอย่างครบถ้วนก็ส่งงานต่อให้ Tester และ... งานงอก! งอกจนสะดุ้งตูดเด้งจากเก้าอี้กลับไปหา PM มันมีบั๊ก! ทำไมคุณปล่อยให้มันเกิดขึ้น ดูสิ! มันกระทบกับหน้าเก่าที่เคยทำไว้แล้วแทบทุกหน้าเลย!
- PM ก็โมโหๆ ไปตวาดใส่หัวหน้าทีมได้ยินถึงโรงอาหารของโรงพยาบาลที่ตั้งอยู่ไม่ห่าง ทำไมคุณปล่อยให้บลาๆๆ คุณนี่มันบลาๆๆ
- จูนหาจั๊บบอกทีมประชุมทันที มันเกิดขึ้นได้อย่างไร! เขาถามหาความจริงจากซีเนียร์อย่างไม่พอใจ จั๊บจะเอาตัวรอดก็ถามกับเจี๊ยบว่าใครสร้างหน้าที่มีปัญหานี้ขึ้นมา คนสวยก็หันไปมองโจ๊กซึ่งนั่งฟังอย่างซึมๆ
- ผมเองครับหัวหน้า เด็กโง่รับหน้าตาย
- จูนก็ทบทวนเหตุการณ์ที่เกิดขึ้นก่อนจะถอนหายใจ ถามว่าต้องใช้เวลาเท่าไรจึงจะจัดการปัญหานี้ได้
- โจ๊กจึงว่าสามวัน ทันใดจั๊บก็โพล่งมันไม่ทันหรอก อย่างน้อยก็หนึ่งอาทิตย์
- เป็นเพราะนายไม่มีฝีมือ ชอบทำพลาดเสมอ จั๊บสอนสั่งโจ๊กในฐานะที่ตัวเองเป็นซีเนียร์ ทำงานมีสติหน่อยได้ไหม!
- ใช่ พี่โจ๊กมักเหม่อลอย เจี๊ยบสังเกตเห็นบ่อยๆค่ะหัวหน้า นั่นคนสวยเอาด้วย
- จูนถึงกับกุมขมับ การเลื่อนตำแหน่งคงไม่ต้องหวังแล้วแบบนี้ ไหนเมียกำลังจะย้ายลูกไปเข้าโรงเรียนค่าเทอมแพงๆอีกล่ะ
- จูนจึงเรียกเจามาต่อว่า ว่าเป็นดีไซเนอร์ไม่รู้จักพอ เขาไม่ต้องการโทษทีมตัวเอง จึงบอกกับ PM ว่าเป็นเพราะเจามันเผือกไปขอแก้งานกลางคัน เหตุนี้โจ๊กกับเจี๊ยบจึงต้องทำงานหนักเป็นสองเท่าทั้งที่มีเวลาเท่าเดิม งานจึงไม่เรียบร้อยไงล่ะ
- PM ก็ต้องรักษาหน้าตาตัวเอง ก็ใช้เหตุผลเดียวกันนี้ไปบอกต่อ Tester
- เย็นวันนั้นหลังจากเลิกงาน โจ๊กกับเจานัดกันกินเหล้าย้อมใจ ต่างคนต่างเมากลายเป็นไอ้เน่าด้วยกันทั้งคู่

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

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

วันอาทิตย์ที่ 21 กุมภาพันธ์ พ.ศ. 2559

Vaadin with Map by JavaScript part 2

>> สามสิ่งที่เราจะต้องใช้จาก part ที่ผ่านมา (ทบทวน) ได้แก่
1. com.vaadin.ui.AbstractJavaScriptComponent หรือก็คือ หลังบ้าน
2. com.vaadin.shared.ui.JavaScriptComponentState หรือก็คือ share พื้นที่
3. จาวาสคริปต์ที่ทำหน้าที่เป็น Connector ซึ่งถูกเขียนรวมกับฟังก์ชันของแผนที่ที่เป็นงานของ หน้าบ้าน

>> ภาพด้านล่างนี้คือ main โปรแกรม

- บรรทัดที่ 5 และ 6 ระบุว่าเราจะเขียนคลาสแผนที่เพิ่มอีกสองคลาส ได้แก่ GoogleMap และ LongdoMap
- ส่วนบรรทัดที่ 24 คือจุดเริ่มต้นการทำงาน


- บรรทัดที่ 26 แบ่งหน้าจอออกเป็นสองด้าน ด้านซ้ายจะให้แสดง Google map ส่วนด้านขวาจะให้แสดง Longdo map
- บรรทัดที่ 29 และ 30 กำหนดพิกัดเริ่มต้น (ประเทศไทย)
- บรรทัดที่ 34 ถึง 37 อธิบายได้ว่า สร้าง Google map กำหนดพิกัดให้ จากนั้นกำหนดความกว้างและยาว 100 เปอร์เซ็นต์
- บรรทัดที่ 39 ถึง 41 อธิบายได้ว่า ให้วาด Google map ข้างต้น กำหนด caption กำหนดความกว้างและยาว 100 เปอร์เซ็นต์
- บรรทัดที่ 43 ให้ Google map ที่ได้แสดงยังพื้นที่ด้านซ้าย (ดังคำอธิบายในบรรทัดที่ 26)


- บรรทัดที่ 48 ถึง 51 อธิบายได้ว่า สร้าง Longdo map กำหนดพิกัดให้ จากนั้นกำหนดความกว้างและยาว 100 เปอร์เซ็นต์
- บรรทัดที่ 53 ถึง 55 อธิบายได้ว่า ให้วาด Longdo map ข้างต้น กำหนด caption กำหนดความกว้างและยาว 100 เปอร์เซ็นต์
- บรรทัดที่ 57 ให้ Longdo map ที่ได้แสดงยังพื้นที่ด้านขวา (ดังคำอธิบายในบรรทัดที่ 26)

>> ต่อที่คลาส DrawMap ครับ

- บรรทัดที่ 13 ให้คลาสนี้สืบทอดมาจาก VerticalLayout
- บรรทัดที่ 15 ถึง 18 ประกาศว่าคลาสนี้ประกอบไปด้วย component สำคัญใดบ้าง
- บรรทัดที่ 20 ให้ constructor ของคลาสรับพารามิเตอร์ที่มีชนิดเป็น Map interface เท่านั้น (เราเขียนขึ้นเองครับ) ทั้งนี้เพราะผมจะกำหนดให้คลาส GoogleMap และ LongdoMap เป็น Map ด้วย
- บรรทัดที่ 30 และ 31 เมื่อใดก็ตามที่เกิดการกดปุ่ม ค่าที่กำหนดไว้ใน text field จะถูกอ่านและนำมากำหนดให้กับ Map ออบเจ็กต์ทุกครั้ง ซึ่งจะเป็นผลให้เกิดการทำงาน onStateChange โดยอัตโนมัติดังที่ได้เล่าไป
- บรรทัดที่ 35 ถึง 47 เป็นการจัด layout เพื่อให้ประดา component ทั้งหลายเป็นไปตามตำแหน่งที่เราต้องการครับ


- บรรทัดที่ 52 ถึง 66 เขียนบริการ getter methods เอาไว้ส่งออก component สำคัญที่อนุญาตให้เรียกใช้ ณ คลาสอื่นๆ

>> และนี่คือ Map interface ครับผม


>> ก่อนที่จะไปต่อ ภาพด้านล่างคือโครงสร้างทั้งหมดของโปรเจ็กต์นี้


>> คลาส GoogleMap ที่จัดว่าเป็น server-side component และเป็น Map

- หัวใจสำคัญของคลาสนี้มี 3 ตำแหน่งนะ ได้แก่ 1. บรรทัดที่ 7 @JavaScript เพื่อเรียกใช้ไฟล์จาวาสคริปต์ใดๆ ทั้งจากภายนอกและภายในโปรเจ็กต์
-- ภายนอกเรียกไปยัง https://maps.googleapis.com เพื่อใช้ google map api เวอร์ชัน 3 (เท่าที่ทราบในตอนนี้)
-- ภายในเรียกไปยัง JavaScript Connector
2. บรรทัดที่ 11 ระบุว่าคลาสนี้สืบทอดจาก AbstractJavaScriptComponent และเป็น Map
3. บรรทัดที่ 14 เชื่อมโยงตนเองกับ share ในที่นี้คือ State ซึ่งจะได้รับผลการเปลี่ยนแปลงทุกครั้งที่มีการกำหนดพิกัดเข้ามาใหม่

>> คลาส GoogleMapState


>> JavaScript Connector ของ Google map

- บรรทัดที่ 1 ระบุที่อยู่ตาม package ของไฟล์นี้ โดยแทนที่ . (dot) หลังจาก window object ด้วยเครื่องหมาย _ (underscores) ไม่อย่างนั้นจะหาไฟล์นี้ไม่พบ
- บรรทัดที่ 3 บอกว่าพื้นที่ที่เป็นของคลาส GoogleMap นี้แหละคือ DOM ที่จะใช้ผูกเป็นหน้าตาบน browser
- บรรทัดที่ 5 ถึง 16 คือฟังก์ชัน onStateChange (ชื่อต้องตั้งตามนี้เลย) เพราะเมื่อกำหนดค่าพิกัดใหม่ฉันใด ฟังก์ชันนี้จะทำงานทันทีฉันนั้น ผมก็ตั้งใจให้มันไปเรียกใช้ google map api วาดแผนที่ออกมาให้ครับ :)

>> จบไปแล้วกับ Google map คราวนี้มาดู Longdo map กันบ้าง เพื่อนๆจะเห็นว่าวิธีการเหมือนเดิม ต่างกันแค่ api ของตัววาดแผนที่เท่านั้น








>> และลิงค์ด้านล่างนี้คือเอกสารทั้งหมดที่ผมอ่านแล้วลองประยุกต์ทำเอง (ลอกมาว่างั้นเถอะ หัวเราะ) ขอบคุณสำหรับความรู้ครับผม
- Vaadin 7 Loves JavaScript Components
https://vaadin.com/blog/-/blogs/vaadin-7-loves-javascript-components
- Integrating a JavaScript component
https://vaadin.com/wiki/-/wiki/Main/Integrating+a+JavaScript+component
- Integrating JavaScript Components and Extensions
https://vaadin.com/book/vaadin7/-/page/gwt.javascript.html
- Longdo map api (v.2)
http://map.longdo.com/longdo-map-api
- Longdo map api tutorial example (not v.2)
http://map.longdo.com/api/docs/tutorial-mmmap-api-beginners
- Google Maps JavaScript API v3 example
http://www.daydev.com/developer/s6-programming-language/google-maps-javascript-api-v3.html

วันพุธที่ 17 กุมภาพันธ์ พ.ศ. 2559

Vaadin with Map by JavaScript part 1



>> นี่เที่ยงคืนแล้วหรือไร ผมยังคงนั่งจดจ่ออยู่กับการเตรียมตัวอย่างจาวาโค้ดซึ่งเขียนด้วย Vaadin Framework, ที่น่าสนใจคือเราจะเขียน JavaScript (ของเราเอง) ให้ Vaadin เข้าใจได้อย่างไร นี่จึงเป็นอีกหนึ่งบันทึกที่ผมตั้งใจนำมาเล่าครับ

>> หัวใจของเรื่องคือ JavaScript Components ซึ่ง Vaadin ได้จัดเตรียมช่องทางเพื่อใช้คุยกับ JavaScript เพียวๆ อันประกอบไปด้วย
- AbstractJavaScriptComponent สำหรับฝั่ง Server-side หรือก็คือฝั่ง Vaadin component นั่นแหละจ้า
- JavaScriptComponentState สำหรับทั้งฝั่ง Client-side ที่เป็น JavaScript เพียวของเรากับฝั่ง Server-Side ข้างต้น
- และสุดท้าย Javascript เพียวๆสำหรับฝั่ง Client-side

>> ดังที่กล่าวไปแล้วหากเพื่อนๆมือใหม่คนไหน (หรือกระทั่งตัวผมเอง) ยังไม่แน่ใจ ยังไม่ค่อยเข้าใจ มาเถอะ ให้ผมลองอธิบายความคิดความเข้าใจของผมให้ฟังก็แล้วกันนะ, เรามาเริ่มกันที่ GWT หรือความคิดของ Google ที่ว่าเขียนจาวาได้ HTML + JavaScript ไปพร้อมกัน หรือพูดง่ายๆว่า เขียนจาวา (ภาษาหลังบ้าน) ได้งานของหน้าบ้าน (ที่แสดง ณ browser) ไปพร้อมกัน, GWT ดังกล่าวมี 3 layers เป็นหลักครับ
1. ฝั่งหลังบ้าน คือ จาวา ก็จะใช้ จาวาคอมไพเลอร์ มาจัดการ เปลี่ยนจาวาเป็น ไบท์โค้ด (Byte Code) และให้ JVM มาทำงาน (จาวาจึงต้องใช้ server)
2. ฝั่งหน้าบ้าน คือ GWT ก็จะใช้ GWT คอมไพเลอร์ มาจัดการ เปลี่ยนจาวาที่ GWT รู้จักเป็น JavaScript พร้อมส่งไปให้ Browser ทำงาน
3. ตรงกลาง เรียกว่า share หรือก็คือพื้นที่ที่ฝั่งหลังบ้านจะใช้ทำความรู้จักกับหน้าบ้าน เป็นพื้นที่ที่ทั้งสองฝั่งสามารถรับส่ง message ระหว่างกันไปมาได้ เขียนด้วยจาวาอีกเช่นกันและใช้เทคโนโลยี Asynchronous เป็นตัวขับเคลื่อน

>> ด้วยเหตุที่ว่า Vaadin ประดิษฐ์ขึ้นมาบนฐานความคิดของ GWT มันจึงหนี layer ทั้งสามนี้ไม่พ้น ทว่ามันก็ทำให้ layer ใกล้ชิดกันมากขึ้น ราวกับเหรียญที่มีสองด้าน หรือกล่าวว่าเขียนจาวาโดยความคิดของ Vaadin เพื่อนๆก็จะได้งานหน้าบ้าน (ที่เป็น HTML + JavaScript) ไปด้วยเลย แต่เขียนง่ายกว่า GWT, คอมไพล์ไวกว่า GWT ทั้งยังมีเทคโนโลยีหรือความคิดเรื่องของ Container ที่จะทำให้เพื่อนๆสามารถ อ่าน เพิ่ม ปรับปรุง ลบ ข้อมูลใดๆที่ยิงยาวจากหน้าบ้านไปยังฐานข้อมูลได้เลย ว้าว! (ไม่นับว่ามี Theme ให้เล่นอีกนะ สุโก้ย~)

>> เพื่อนๆมือใหม่ควรทราบว่า หาก component หรือง่ายๆว่าคลาสต่างๆที่ Vaadin จัดเตรียมไว้ให้นั้นไม่ตรงกับความต้องการของเพื่อนๆแล้วล่ะก็ เพื่อนๆมีแนวโน้มที่จะต้องประดิษฐ์ Widget (คำเรียกใน GWT) ขึ้นมาใหม่แล้วล่ะครับ

>> Widget หรือก็คือ component (คำเรียกใน Vaadin) นี้คือการกลับไปเขียน GWT แล้วสั่งคอมไพล์เพื่อให้ได้ JavaScript ซึ่งเราเรียกจาวาโค้ดที่มีหน้าตาให้มองเห็นได้นี้ว่า Widget แฮะๆ ก็อย่างที่เพื่อนๆรู้กันอยู่แล้วว่า เราเลือกใช้ GWT หรือ Vaadin ก็เพราะเราไม่ต้องการยุ่งกับงานหน้าบ้านที่ต้องใช้กลไกของ JavaScript หลากหลายลักษณะที่มุ่งแสดงผลบน browser ที่หลายหลากยี่ห้อ ดังนั้นเราจึงมานั่งหลังขดเขียนจาวาแล้วได้งานหน้าบ้านไปพร้อมกัน

>> เพื่อคอมไพล์จาวาโดยใช้ไลบรารีของ GWT เราเรียกกระบวนการนี้ว่าการคอมไพล์ให้ได้ Widget หรือก็คือความคิดที่เรียกว่า Widgetset, ความคิดดังกล่าวนี้ต้องใช้ 3 layers มาทำงานดั่งที่แจ้งไปแล้ว แต่ขอแบ่งให้ชัดกว่านี้อีกสักเล็กน้อยครับ ดังนี้
1. ฝั่ง Client-side widget (หรือก็คือ GWT ใน Vaadin)
2. ฝั่ง Server-side component (หรือก็คือตัว Vaadin)

>> Client-side widget พื้นฐานนั้นประกอบไปด้วย
- Connector ทำหน้าที่เชื่อมต่อกับฝั่ง Server-side component ทำงานกับ RPC และ onStateChange เป็นหลัก
- RPC ทำให้ Widget พูดคุยหรือส่ง message มายังฝั่ง Server-side component ได้ (แท้จริงมันทำงานส่ง message จาก Server-side component ไปยัง Widget โดยอัตโนมัติ)
- State หรือก็คือพื้นที่ตรงกลางที่เป็น share ระหว่างสองฝั่ง คอยรับรู้การเปลี่ยนแปลงหรือการส่ง message ของสองฝั่งซึ่งจะกระตุ้นให้เกิดเหตุการณ์ onStateChange ณ Connector
- Widget หรือก็คือคลาสที่เขียนด้วยไลบรารี GWT ที่เพื่อนๆต้องการสร้างขึ้นเป็น component ชิ้นใหม่นั่นเองครับ (และแน่นอนว่า Connector จะต้องรู้จัก มันจึงจะถูกทำงานได้)

>> Server-side component พื้นฐานนั้นประกอบไปด้วย
- คลาสที่เขียนด้วยไลบรารี Vaadin ซึ่งจะส่งข้อมูลหรือ message หรือเรียกว่าพูดคุยกับ Widget นั่นแหละจ๊ะ โดยส่งผ่านการเปลี่ยนแปลงที่ต้องการไปยัง State

>> เมื่อ State รับทราบการเปลี่ยนแปลงก็จะกระตุ้นให้เกิด onStateChange ที่ Connector ทันที เป็นเหตุให้ Server-side component สามารถสื่อสารกับ Widget ได้ในที่สุด

>> พูดมาเสียยาวตกลงผมจะทำอะไรเนี่ย (หัวเราะ) และตอนนี้ก็ไม่ไหวแล้ว ง่วงแล้ว ตีสองแล้ว เป็นอันว่าจากความคิดและขั้นตอนทั้งหมดที่เล่าไปนั้น เราไม่ทำ Widgetset หรอก เราต้องการ Server-side component หนึ่งคลาสที่เป็น AbstractJavaScriptComponent และหนึ่งคลาสที่เป็น share หรือกล่าวว่าเป็น JavaScriptComponentState สุดท้ายเราต้องการ Connector ที่เขียนด้วยภาษา JavaScript เพียวๆครับ

>> แล้วผมจะมาเล่าต่อว่าจะสร้าง แผนที่ ลงบน Vaadin ด้วยวิธีการดังกล่าวนี้ได้อย่างไรใน part ต่อไปนะ (ตัวอย่างน่ะทำเสร็จแล้วจ้า เอาดูรูปไปก่อน แฮะๆ)




>> ผมบอกเล่าด้วยความตั้งใจนะ ผมตั้งใจทำมันทั้งโค้ด ทั้งรูป หวังว่ามันจะเป็นประโยชน์ต่อการเรียนรู้ร่วมกันระหว่างเราทั้งสองนะครับ ฝันดีๆ