Tag: work

กู เป็น API Support

แนะนำให้อ่านกู เป็น Support ก่อนนะ

ผมเคยเขียน blog เรื่องชีวิตทำงานนานแล้ว (link ข้างบนนั่นแหละ) ว่าผมไม่ได้หากินกับการเขียน code เพราะเป็น support แต่สุดท้ายยังไงๆ ผมก็หนีไม่พ้น code อยู่ดี เพราะสิ่งที่ผม support คือ api -*-

การ support api นั้นความรู้ที่จะต้องมีต่างจากการ support product อื่นๆ อย่างพวกสาย end user support หรือ server support ก็คือ

  • แน่นอนว่าต้องเขียนโปรแกรมเป็น โดยเฉพาะภาษาของ api ที่เรา support เราต้องเขียนโปรแกรมเรียกใช้ api ที่เรา support ได้
  • ต้องอ่าน code ของ dev-ลูกค้า ที่มาเรียกใช้ api เราได้
  • ต้องอ่าน code example ของ api เราที่ส่งออกไปให้ dev-ลูกค้า อ่านได้
  • ต้อง debug code ไม่ว่าจะของลูกค้าหรือ example เราได้
  • ในกรณีที่เข้าถึง code api ที่เรา support ได้ ควรจะอ่าน code พอเข้าใจ/ไล่ flow/debug/build diagnostic binary ได้ เพราะว่า No matter what the documentation says, the source code is the ultimate truth

จะเห็นว่า skill ด้านบนมันก็ไม่ต่างจาก dev เท่าไหร่ หลักๆ คือต้องเขียนโปรแกรมเรียกใช้ api เราได้ (ผมใช้คำว่าเขียนได้ คือไม่จำเป็นต้องลึกมาก แต่ยิ่งรู้ลึกๆ ยิ่งดี) ,อ่าน source code ออก , อ่าน source code ชาวบ้านออก (ประสบการณ์การเป็น outsource และการเป็น dev ใน support phase ช่วยผมได้เยอะมาก) debug เป็น ซึ่งการฝึกฝนการเป็น support api ก็คล้ายๆ กับการหัดเป็น dev คือหัดเขียนโปรแกรม, หัดอ่าน code, หัดอ่าน document , ลองมันเข้าไป สงสัยอะไร ติดอะไรก็ไปถาม dev

อ่านดูเหมือนจะไม่มีอะไร แต่ปัญหาหลักๆ ก็คือคนมาเป็น support เพราะไม่อยากเขียนโปรแกรมแล้ว …. คือไม่อยากเขียนโปรแกรมแล้วแต่ยังอยากอยู่สาย IT อยู่ คือกะจะขึ้นสายบริหารก็กะว่ามาเป็น support จะได้ management มากขึ้น -*- เราจึงมี support ที่เน้นการ managment ปัญหาให้พ้นๆ ตัว ไม่ก็โยนงานไปที่ dev เลย ดีหน่อยก็ reproduce ได้แล้วก็ส่งให้ dev ต่อโดยที่ไม่ลองหาทางแก้ไขปัญหาเองเลย

ดังนั้นจึงไม่ต้องพูดถึงการ support api เพราะส่วนใหญ่ไม่ยุ่งกับ code แล้ว skill ด้านบนเกือบทุกอย่างนี่ตัดทิ้งไปได้เลย ให้หัด support api ก็ไม่อยากจะอ่าน code, ไม่ลองเล่น example, ไม่คิดจะขวนขวายอะไร รอให้คนที่เป็นอยู่แล้วทำ powerpoint มาสอนให้เขียนโปรแกรมเป็น ให้อ่านโปรแกรมออก

เจริญล่ะมึงเอ๊ย

ป.ล. ทุกวันนี้ผมก็ยังไม่เข้าใจ require.js ที่ api ผมเริ่มเปลี่ยนมาใช้ แต่ที่ผมไม่เข้าใจคือผ่านการอ่านและลองเล่นมาแล้ว ให้ตายไงก็ไม่เข้าใจมัน (คิดว่าตัวเองยังไม่เข้าใจ JavaScript ดีพอ)

Bangkok Technology Unconference

วันนี้ที่บริษัทผมมีจัดงาน Unconference กันภายในบริษัท เป็นการจัดครั้งแรก โดยแก้ไขข้อผิดพลาดของงานแข่ง technology ภายในบริษัทครั้งก่อนๆ หน้าที่จำกัดแค่ “technology ที่การันตีได้ว่าเป็นประโยชน์กับบริษัท, อิงกับ strategic product ของบริษัทเท่านั้น” คราวนี้คือพูดเรื่องอะไรก็ได้ที่เกี่ยวกับ technology ใช้ระบบคล้ายๆ Barcamp มีการเชิญวิทยาการข้างนอกมา (เท่าที่รู้คือมาจาก Microsoft, HP, Wongnai และอื่นๆ ที่ผมไม่รู้) มี mail แจ้ง manager ให้ทราบว่าพนักงานอาจจะหายไปจากโต๊ะเพื่อมาเข้าร่วมงานนี้ด้วย สบายเลย ^^

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

  • What I want to tell Junor Developers by @DevGuli
  • Cyber Threat – One of the most serious national security challenges we are facing
  • How to create 3D Engine in JavaScript for UIToolkit 3D Surface Chart
  • Making an application on 4 mobile platforms (iOS, Android, WP8, BB10) by @pattrawoots แห่ง wongnai.com
  • How to retouch your digital photograph like a pro

ตัวผมเองก็พูดในเรื่อง Sync your home, office and mobile with Cloud Storage Service ซึ่งชื่อหัวข้อมันดูเท่มาจนมีคนสนใจ 20 กว่าคน แต่เนื้อเรื่องจริงๆ มันคือ Dropbox vs Google Drive vs Microsoft Skydrive คนเลยเข้ามาฟังน้อย แถมชนกับเรื่อง Cloud ของ HP ที่เค้าจริงจังกว่า+คนบรรยายจาก HP สวย 55

เนื้อหาผมก็เตรียมตัวแบบขำๆ เอาแบบเรื่อง basicๆ ง่ายๆ เปรียบเทียบ feature พื้นฐานของ 3 ตัวนี้แล้วยกตัวอย่างการใช้งานจริง ผมเองทำการซ้อม present มาประมาณนึง แต่ตกม้าตายตรงลืมซ้อม demo การใช้งานจริงๆ ตอน demo เลยพลาดไปหลายดอกและเสียเวลาไปมากตอนทำ demo คิดว่าถ้ามีโอกาสไปพูดที่งานแนวๆ unconference อีกคงต้องซ้อม demo นอกจากซ้อมพูด slide ด้วย

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

ป.ล. มีการโปรโมตงานทาง Twitter ผ่านทาง Tag #bkktechunconf แต่เหมือนจะแป๊กๆ มีไม่กี่คนที่ tweet -*-

Unconference, Not Collaborative

ผมเคยเข้าร่วมกิจกรรม unconference 2 ครั้งด้วยกันคือ barcamp bkk ครั้งที่ 1 และครั้งที่ 3 ครั้งที่ 1 ผมไปถ่ายรูปแล้วไปกวนตีนเค้าอย่างเดียว ส่วนครั้งที่ 3 เตรียมหัวข้อไปดิบดีแต่ไม่มีใครเลือก (แม่ง) สิ่งที่ผมสังเกตุได้ระหว่างครั้งที่ 1 และ 3 คือคนเข้าร่วมมานั่งฟังนิ่งๆ มากกว่าสมัย 1 มาก และผมก็ไม่ได้เข้าร่วม event แนวนี้อีกเลย

เมื่อต้นปี ที่ทำงานผมคิดจะจัดงานแนวๆ unconference ขึ้นเหมือนกัน ให้คนใน office มาพูดมาแชร์กันทั้งเรื่อง technology, วิธีการทำงานเจ๋งๆ ของแต่ละคน อะไรทำนองนี้ มีการโปรโมตกิจกรรมไปทาง leader, manager ต่างๆ ให้คนมาร่วมเยอะๆ คนที่จัดก็มาชวนผมด้วยเพราะรู้ว่าผมเคยร่วม barcamp bkk และอ่านเวบพวกเทคโนโลยีบ่อย ซึ่งผมก็ตกลงไป

มีเพื่อนผมคนนึงสนใจงานนี้ (มั้ง) มาถามผมว่า “งานนี้คนเข้าร่วมต้องพูดด้วยเหรอ ทำไมต้องพูดด้วยอ่ะ นั่งฟังไปกินขนม (ฟรี) ไปอย่างเดียวไม่ได้เหรอ?”

ผมก็ตอบไปแค่ว่า “เออ ทุกคนต้องพูด” แล้วมานึกย้อนหลังว่า ไม่แปลกที่งานพวกนี้จะและหลายๆ project แนว collaboration รอบตัวผมจึงไม่ประสบความสำเร็จเท่าไหร่

ป.ล. ผมว่าจะไปพูดเรื่องข้อดีของการใช้โปรแกรมพวก dropbox, google drive, ms skydrive ในงาน unconference ที่ office นี่แหละ น่าจะง่ายๆ ดี ฮ่าๆ