2021

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

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

ปกติแต่ละปีจะเขียน blog ล่วงหน้าไว้ประมาณ 1-2 เดือน ปีนี้มาเขียนเอาวันสิ้นปีเพราะว่าเนื้อเรื่องมันเปลี่ยนไปพอสมควรตอนปลายปีแล้วชวนไม่ค่อยอยากเขียนเท่าไร

Work

ปีที่แล้ว และครึ่งปีแรกปีนี้เราได้ Top Performer เป็นครั้งแรกหลังจากอยากได้มาหลายปี (ผลออกต้นปีเลยไม่ได้เขียนถึงในปีที่แล้ว)

เอาจริงๆ คิดว่าโชคช่วยไปอยู่ครึ่งทาง เพราะปัญหาต่างๆ ในครึ่งปีหลังปีที่แล้วส่วนมากก็เป็นเรื่องที่ดูมานานแบบ what-if แล้วพอได้ทำก็คิดว่า execute ได้ดี มีคนก๊อปแบบไปด้วยซึ่งก็ไม่ได้ว่าอะไร Good artist copy, great artist steal จริงๆ ก็มีเขียนบล็อกไว้เสร็จหมดแล้วแต่เนื่องจากมันไม่ใช่เรื่องที่ positive กับบริษัทเท่าไร บริษัทเลยอยากให้งดเว้นไม่ลง in writing ถ้ามีโอกาสและเป็นงานปิดไม่มี recording อาจจะขอบริษัทเอาไปเล่า

ปีนี้เรื่องใหญ่ๆ คงเป็นเรื่องทีมที่บริษัทแหละ

SRE

ผมคิดว่างาน SRE ที่นี่จริงๆ คืองาน 3 ตำแหน่งรวมกันคือ Sysadmin, DevOps และ Reliability (Network engineer มีบ้างแต่บน Cloud ไม่ค่อยสำคัญ) ซึ่งผมว่าไม่ใช่เรื่องแปลก เพราะบริษัทที่ Dev ไม่ถึง 100 คนน่าจะมีตำแหน่งแค่ 1 จาก 3 ตำแหน่งนี้ ยกเว้นว่าทีมขนาดใหญ่มากอาจจะรับ System administrator เข้ามาเป็น first tier support ปัญหาก็คือ ตอนทำ hiring จะพบว่า candidate ส่วนมากที่เข้ามารู้เรื่อง DevOps มากกว่า ในแกนอื่นๆ ยังไม่ค่อยเห็น candidate ที่ดีเท่าไร

ผมคิดว่าผมและทีมวาง DevOps ไว้ตั้งแต่ปีแรกที่ผมเข้าไปอยู่จนเรียกได้ว่าเป็นปัญหาที่ solve แล้ว คือเราไม่จำเป็นต้องมี DevOps อีกต่อไปนอกเหนือจากงาน training, routine หรือ support และ improvement คือถ้า Dev ที่รู้เรื่องก็จะ copy file ไปวางแก้นิดหน่อยก็ deploy ได้แล้ว และล่าสุดก็คือกำลังทำ tool ที่มันจะ apply standard ล่าสุดให้เลยก็จะยิ่งลดขั้นตอนไปอีก อาจจะติดแค่เรื่องของสิทธิ์ที่บาง operation สุ่มเสี่ยงจำเป็นจะต้องให้ DevOps ที่มีสิทธิ์สูงกว่าทำให้ และอัพเดตมาตรฐานปัจจุบันให้เป็นเทคโนโลยีล่าสุด เรื่องนี้ผมเลยคิดว่าผมและทีมทำไว้ได้ดีแล้ว

System admin ผมคิดว่าเป็นสกิลพื้นฐานที่ไม่ว่าจะตำแหน่งไหนก็จำเป็นต้องมี แต่ปีนี้ที่สัมภาษณ์มาคนที่มาจากสาย DevOps กลับขาดสกิล System admin ส่วนหนึ่งคือคนที่ย้ายสายงานมาและอยู่ในทีมที่มีคนทำ function อื่นๆ ให้เลยไม่ถูกบีบบังคับให้เรียนรู้ และผมก็คิดว่ามันเป็นสกิลที่เรียนยากเหมือนกัน ถ้าให้อธิบายแบบโปรแกรมเมอร์จะบอกว่าเหมือนเขียนภาษา C คือโปรแกรมเมอร์จะมีความเชื่อว่าเขียนภาษาหนึ่งเป็นไปภาษาอื่นก็ไม่ยาก แต่จะเขียนภาษา C ให้ได้ดีต้องเข้าใจทฤษฎีเรื่อง memory model ของคอมพิวเตอร์ด้วย จะโยนคนเขียน Python ไปเขียน C เลยไม่ง่ายเหมือนกับให้คนเขียน Python ไปเขียน JavaScript ตอนนี้แผนของทีมใหม่คือเราจะลองเปิดรับแยกกันดูโดยไม่ต้องมอง skill ด้านอื่น อาจจะทำให้ได้คนตรงมากขึ้น

อันหนึ่งที่ผมอยากให้มีคือคนทำงานสาย Technical IT ควรจะมี Homelab โดยเฉพาะที่มันตรงกับ job function ตัวเอง เช่น ถ้าเป็น network engineer ก็ควรจะมีอุปกรณ์ network ไว้ซ้อมที่บ้าน (ผมมารู้ว่า Palo Alto ในต่างประเทศมีขายแบบเอาไปลองเล่นที่บ้านด้วยนะ ถ้าเป็น VM ก็หลักพัน ผมยังไม่เคยถามในไทยว่ามีไหม) หรือ software engineer ก็ควรจะมีเว็บส่วนตัว ซึ่งมันจะ force เลยว่าต้องทำ System admin เพราะมันไม่มีคนในทีมช่วยทำแล้ว (แต่หลังๆ ผมจะเห็นคนหนีไปทำเป็น serverless กันเยอะ…)

ถ้าให้คะแนน ผมคิดว่า System admin ผมอยู่ในขั้นปานกลาง คือให้เซตอะไรก็คงได้ แต่ไม่ใช่ในระดับ tuning หรือ hardening ซึ่งผมก็คงเอาตามที่ search เจอ ไม่ใช่อ่าน document แล้วไปนั่งลองจูนเอง

ส่วนสุดท้ายคือ Reliability ซึ่งผมคิดว่ามันเป็นปัญหาใหญ่ของทีม มันน่าจะเริ่มจาก What get measured get done ก่อน เราอยากให้เว็บไม่ล่มเลยต้องตีโจทย์ก่อนว่าเว็บล่มคืออะไร (ภาษา SRE เค้าจะบอกว่าเซต SLO) เกิดจากอะไรบ้าง แล้วสรุปเป็นขั้นเป็นตอนได้ว่าต้องทำอะไรบ้าง ตอนนี้ทำไปแล้วกี่ % ซึ่งตั้งแต่ทำงานมาก็รู้สึกว่าทำมาไม่ค่อยตรงเป้า

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

Architect

มีคนถามผมบ่อยว่าตำแหน่งนี้ทำอะไร ทำ SRE หรือเปล่า เห็นวันๆ เขียนแต่บล็อกที่เกี่ยวกับ SRE

จริงๆ ไม่ใช่เพราะ Architect มีหลายคนแต่มีแต่ผมที่เขียนบล็อกเป็นประจำ แล้วผมค่อนข้างสนใจงานพวก system administration ก็เลยทำเยอะ รวมถึงว่าบางอันที่เป็น coding ก็อาจจะเป็น competitive advantage ของบริษัทเลยเอาไปเล่าไม่ได้มาก เมื่อเทียบกับว่า Infra ที่มันไม่ใช่ product จะลอกไปก็ไม่ทำให้เราเสียโอกาสแต่อย่างใด

เวลามีคนถามว่างานผมทำอะไร เหมือนคำตอบผมจะเปลี่ยนทุกปีจนไม่รู้จะว่ายังไงดี

ตอนเค้ารับผมเข้าทำงาน CEO บอกผมว่าคิดว่าอะไรดีต่อบริษัทก็ทำ เป็นเหตุผลนึงที่ผมรู้สึกว่าเรามี mutual trust กันแล้วน่าทำงานด้วย ก็เลยรับ offer

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

ปีที่สองผมจำไม่ได้เหมือนกันว่าทำอะไรไปนอกจาก Analytics ซึ่งอันนั้นก็คล้ายๆ กันคือมันไม่เข้าธีมของ product team ไหนสักเท่าไรและมันเป็นปัญหาที่ยาก Chief ก็เลยหยิบมาทำกันสองคน ผมทำขาเข้า (เพราะตอนนั้นผมเขียน Go) ส่วนหัวหน้าผมทำ data pipeline (ซึ่งผมก็ไม่อิน แต่ปีนี้เริ่มอยาก rewrite มันอยู่บ้างนะ) ปัจจุบันส่งให้ทีมดูแล้วแต่ก็ยังจะหาเวลาไปรื้อ infra อยู่บ้างเพราะ scale มันใหญ่ขึ้นทุกวันๆ

ปีที่สามผมดู Infra as Code platform ตัวใหม่ กับ Security ซึ่งก็เลยเป็น acting AppSec และ Infosec ไปพร้อมกัน แต่ก็ยังมองหาคนมาช่วยทำ job function พวกนี้ เพราะเราอยากได้ DevSecOps ซึ่งผมไม่ได้ตาม และคงไม่มีเวลาไป actively ส่องหาช่องโหว่ ส่วน Infosec นั้นคิดว่าจริงๆ เป็นปัญหาที่ใหญ่กว่า Engineering เยอะ รวมถึงมี Legal มาเอี่ยวด้วย ต้องมีคนที่ดูเฉพาะจริงๆ นอกงานพวกนี้แล้ว process ภายในถูกทีม Engineering Manager ปรับให้มีการ review design spec ด้วย ก็เป็นอีก job function นึง

ปีนั้น Head of Product ให้คำนิยามตำแหน่งผมว่าเป็น auditor คือไล่จับผิดว่าใครทำอะไรผิดแล้วไปบอกวิธีแก้ให้ถูก ซึ่งตอนนี้ก็จะเป็นโมเดลเหมือนเป็นที่ปรึกษาของบางทีมอยู่ (แบ่งๆ กันไปตามความสนใจ) เราแอบดูว่าทีมทำอะไรตลอดเวลา ทีมก็จะให้ความไว้วางใจและสบายใจด้วยว่ามีคำถามยากๆ ก็มีคนชัดเจนว่าต้องถามใครไม่ใช่ถามลอยๆ มันเป็น relationship ที่ดีกว่า auditor เยอะและมันอาจจะแก้ปัญหาได้ก่อนจะเกิด

ปีนี้ธีมใหญ่ๆ ผมต้นปีคงจะเป็นพวก improvement ต่างๆ จาก security ในปีที่แล้ว และช่วงท้ายปีมี release product ไปตัวนึง และตอนนี้กำลังดู tooling สำหรับ DevOps & Service mesh

โดยสรุปจาก job function ทั้งหมดที่ทำมา ผมเลยมองๆ ว่าจริงๆ แล้วผมไม่ใช่ expert สักอย่างแค่ผมรู้ทุกอย่างมากกว่าที่คนอื่นรู้โดยเฉลี่ยแค่นั้นแหละ และเอามันมา mix กันได้ซึ่งคนที่เซียนแต่สายเดียวอาจจะมองไม่เห็น

RuneKit

ปีนี้เลิกเล่น RuneScape แล้ว หลังจาก level 99 ทุก skill แล้ว ส่วน 120 ผมรู้สึกว่ามันไกล และเริ่ม burn out แล้วก็เลยเลิกเล่นไปก่อน หลังเลิกเล่นค่าไฟลงมา 2,000 เพราะการ์ดจอเปิดทั้งวันกินไฟมาก ก็มีความคิดอยู่ว่ากลับไป grind Old School RuneScape แต่คิดว่ามัน grind skilling ไม่สนุกเท่า RS3 และก็น่าจะเป็นเกมเดียวกัน burnout อยู่ดี

ก่อนจะเลิกเล่นได้ลองโปรแกรม Alt1 เป็นโปรแกรมช่วยเล่นโดยมันจะ OCR หน้าจอเกมหาข้อมูลต่างๆ แล้วเขียน web app มาดึงข้อมูลเหล่านั้นไปใช้ได้ ซึ่งการออกแบบแบบนี้มันเจ๋งมากๆ คือฟีลเหมือน Electron แต่มี API ที่เชื่อมต่อกับเกมได้ ในขณะที่ API Surface ก็ไม่ได้อนุญาตอะไรกว้างเกินไป ทำให้รัน 3rd party app ได้ security แบบเดียวกับ web browser ปกติ ไม่ต้องกลัวโดน hack ข้อจำกัดคือ Alt1 มีเฉพาะใน Windows เท่านั้น

ผมเองเล่นแต่ใน Linux แล้วก็รำคาญที่ทำงานไปเล่นไปแล้วพลาด event ไปเพราะไม่มีแจ้งเตือน เลยไปเขียนตัว host แบบเดียวกันขึ้นมาดู เรียกมันว่า RuneKit (ตาม SwiftKit โปรแกรมสลับ server RuneScape ชื่อดังเมื่อหลายสิบปีก่อน) ก็เป็นครั้งแรกที่เขียน PySide (Qt) คิดว่ามันทำอะไรได้หลากหลายดี จะเสียแค่ว่า license ที่เป็น GPL คงจะเอาไปใช้ในงานประจำยากหน่อยเพราะ Qt ราคาแพงมากๆ และ PySide เองมีปัญหาพอสมควรเช่นมันไม่ retain object ที่ pass ไปให้ Qt เมื่อโดน GC แล้วก็เป็น use-after-free bug มันก็จะแปลกๆ ที่เขียน Python แต่ต้องคิดเรื่อง memory management คนใช้งานก็จะบ่นว่ามันแครชเยอะหน่อย

ตอนทำ RuneKit ก็ลองพวก packaging ต่างๆ ด้วยว่า Python app จะ ship เป็น Desktop app ได้ยังไงบ้าง แล้วก็ยังรู้สึกว่ามัน painful กว่าฝั่ง server เยอะ

  • บน Linux ตั้งใจว่าจะไม่ทำ Snap แน่ๆ ก็จะเหลือ AppImage กับ Flatpak ซึ่งผมว่าอันหลังดีกว่า
  • ปัญหาของ Flatpak คือมันเหมือน Docker แต่ไม่มี package manager มาให้ต้อง inherit base images เอาอย่างเดียว (แต่ multiple inheritance ได้นะ) แล้ว base image ที่ build Qt ก็ไม่มี QtWebEngine จะทำเองก็ยากมากๆ (มันคือ Chromium ซึ่ง build ยากและยังใช้ Python 2 build อยู่) สุดท้ายก็เลยต้องยอมไปใช้ AppImage
  • AppImage ไอเดียง่ายดีแต่มัน impure มากๆ เทียบกับ Flatpak วิธีคือเอาโปรแกรมอัดใส่ iso แล้วใส่หัวของ iso เป็น shell script ที่จะ mount iso ให้เหมือนกับพวก self-extracting zip
  • การสร้าง AppImage เลยจะคล้ายๆ Docker แต่จะต่างกันที่มันจะไม่ ship library พื้นฐานที่ OS ควรมีอยู่แล้วเพื่อลดขนาดไฟล์ กลายเป็นว่ามีความยากอีกระดับคือถ้าอยากให้รันได้ทุก OS ต้องไป build บน Linux เก่าที่สุดที่ support แต่สำหรับฝั่ง user แล้วชอบกันมาก โหลดมาได้ไฟล์เดียว รันได้ทันทีไม่ต้องติดตั้งอะไรอีก จะถอนก็ลบไฟล์ได้เลย
  • บน Mac ลอง packager มาหลายตัว สุดท้าย PyInstaller ก็ใช้งานบน Python 3.9 ได้ แต่ก็พบว่าตอนนี้ Mac ต้อง sign .app ด้วย Developer certificate ($100/yr) เท่านั้นถึงจะ double click ได้เลย ทำให้ user ที๋โหลดไปต้องไปปลด sandbox ใน Terminal ก่อนจะรันได้

สำหรับฝั่ง community อย่างที่บอกปีก่อนว่าเบื่อจะ build open source community แล้ว มันควรจะเป็นแบบ “แสงอาทิตย์ไม่คิดเงิน” คือดวงอาทิตย์ปล่อยแสงไปแล้วใครจะใช้ประโยชน์อย่างไรก็เรื่องของเขา แต่โวยอะไรดวงอาทิตย์ไม่ได้เขาไม่รับฟัง

ใน RuneKit พอมี Linux version ที่ใช้งานได้จริงแล้ว user กลุ่มแรกๆ นี้กลับช่วย provide support ให้คนที่ตามหลังมาได้ดีมากๆ ก่อนหน้าผมเคยมีคนใช้ Pascal เขียน Alt1 เวอร์ชั่น Linux มาก่อนแต่คนกลุ่มนี้เค้ารันไม่ได้ ก็เลยไม่มี community เกิดขึ้น ส่วนฝั่ง Mac เหมือนจะมีแต่ user แต่ไม่มีใครที่ช่วยแก้ปัญหาจริงๆ สักเท่าไร ก็คงเป็นอย่างที่มี game dev คนนึงเคยเขียนว่าทำเกมรองรับ Linux เนี่ย ขายไม่ค่อยได้ แต่ bug report ที่ได้จาก Linux user คุณภาพสูงมาก และกระทบ OS อื่นด้วย

Gaming

หลังจากเลิกเล่น RuneScape ก็พอมีเวลาเล่นเกมอื่นๆ บ้าง เท่าที่เห็นใน HLTB ก็

  • Transport Fever 2 ซื้อมาปีที่แล้ว เกมดีนะ คิดว่ามัน improve experience มาเหนือ OpenTTD มาก โดยเฉพาะว่าเราไม่ชอบต่อรถไฟแล้วเลยไม่ได้สนใจ depth ในส่วนนั้นเท่าไร โหมดนั่งรถเล่นนี่ชิลมากๆ
  • Leisure Suit Larry in the Land of the Lounge Lizards: Reloaded เกมนี้ได้ยินชื่อเสีย(ง)มานาน เล่นแล้วก็คิดว่ามีแต่มุกสัปดนและไม่มีเรื่องอื่นๆ ให้ชมเท่าไร เทียบกับ Secret of Monkey Island ไม่ติด
  • Trails in the Sky SC หลังจากเล่นภาคแรกไว้หลายปีก่อนและติดค้างคาใจมากๆ ภาคต่อทำได้ดีเว่อร์ๆ ชนิดว่าวันที่ไม่เล่นจะมัวแต่คิดอยู่ว่าบทถัดไปจะเกิดอะไรขึ้น
  • Fallout 4 ตอนแรกคิดว่าจะไม่ชอบ แต่ SimSettlement ก็ทำให้มันสนุกดี เสียดายที่ engine มันยังสะดุดๆ อยู่ ถ้ามีเกม cities builder & trading ที่ไม่ต้องทำสงครามแบบ Age of Empire ก็น่าเล่นนะ
  • Toem มีคนแนะนำมา ชิลดี ก็ชอบเหมือนกันนะ
  • Impostor Factory จากผู้สร้าง To the Moon คิดว่าภาคนี้เรื่องมันงงๆ ลืมเนื้อเรื่องเกมก่อนๆ ไปเยอะแล้ว ยังไม่ impact เท่า Finding Paradise อ่ะ
  • Trails in the Sky 3rd เป็นเนื้อเรื่องต่อจาก SC แต่หลังจบเรื่องไปประมาณ 6 เดือน ตัว gameplay เปลี่ยนไปเยอะคิดว่าไม่สนุกเหมือนเป็นรวมเรื่องสั้นมากกว่า บางเรื่องก็ทำดีมากๆ บางเรื่องก็ powerpoint presentation เลย เรื่องน่าเศร้าคงจะเป็นว่า Sky series ทำให้เรารักทุกคนใน Liberl มากๆ แต่ภาคนี้จะเป็นภาคสุดท้ายที่จะได้เจอทุกคนแล้ว นอกจากออกมาเป็นตัวประกอบในภาคอื่นๆ เล็กน้อย
  • Return of the Obra Dinn เพิ่งเล่นจบก่อนปีใหม่พอดี มันไม่ ‘สนุก’ เหมือนเกมทั่วๆ ไป ไม่ได้ ‘ยาก’ เหมือน Puzzle game อื่นๆ ด้วยแต่เนื่องจากทั้งเกมเป็น Puzzle ใหญ่ๆ อันเดียวทำให้เราใช้เวลาคิดได้มากกว่า Puzzle game ที่ต้องรีบๆ คิดเพื่อไปด่านถัดไป เป็น design ที่เฉพาะตัวมากๆ สรุปแล้วเล่นไป 14 ชั่วโมงกับเกมที่มันไม่มี climax อะไร เจ๋งอยู่นะ

2020 & 2021 Prediction

ปีที่แล้วเดาว่า COVID ยังอยู่กับเรา ปีนี้เดาถูก ปีหน้าคิดว่า COVID ยังมีอยู่อย่างน้อยครึ่งปี ดูท่าทีแล้วคิดว่ารัฐบาลต่างๆ น่าจะใช้วิธี downplay แทนว่ามันไม่ใช่ปัญหาเพื่อให้โลกมันไปต่อได้ (แต่เราคิดว่ามันจะไม่ใช่ปัญหาจริงๆ แปลว่าต้องเลิกปิดประเทศ เลิกสวม mask เลิกวางเจลล้างมือ แบบนั้นถึงจะกลับสู่ old normal)

เรื่องโค้ดปีหน้าคิดว่า Golang Generic กำลังจะมา ส่วนตัวรู้สึกว่ามันจะแก้ปัญหาหลายๆ อย่าง แต่มันจะทำให้ design ใน Go เปลี่ยนไป ส่วนหนึ่งที่ชอบ Go คือมันเขียนเป็น Java ไม่ได้ ต่อให้เป็นคนย้ายจาก Java มาก็ต้องทิ้งความเป็น Java ส่วนหนึ่ง (แต่ก็ยังพอเห็น design แบบนี้อยู่บ้าง เช่นใช้ Dependency injection) ยังไม่รู้ว่าพอมี Generic แล้วจะทำให้เราอยากเขียน Go น้อยลงไหมนะ..

ปีนี้เห็นคนไปเที่ยวต่างประเทศบ้างแล้ว ก็คิดอยู่ว่าอาจจะไปเที่ยวบ้างถ้าช่วงกลางปีเป็นต้นไปสถานการณ์ดูดีขึ้น ไม่ต้องกักตัวก่อน-หลังเดินทาง

New Year Resolution

ปีนี้คิดว่า “เตรียม” open source ไว้หลายอย่างแต่ไม่ได้ทำเลย ปีหน้าอยากจะ open source ของข้างในออกมามากขึ้น น่าจะมีสัก 2-3 ตัวเลยล่ะที่โยนโค้ดออกไปได้

Language Maturity by Library

ช่วงนึงเคยนั่งดูภาษาใหม่ๆ เผื่อจะเลือกมาเขียน

อย่างนึงที่พบคือภาษาเองไม่ได้สำคัญเท่ากับ library ที่ภาษานั้นมี เช่น คนเขียน Ruby กลุ่มใหญ่ๆ ก็ไปเพราะ Ruby on Rails, ถ้าจะเขียน data science ถ้าไม่ใช้ Python แล้วก็ทำงานลำบากมาก

ตอนที่หัด Rust แรกๆ นานมาแล้ว ตอนนั้นก็พบว่า library ของภาษาค่อนข้างมี maturity ต่ำมาก คือบางอันก็มีแต่ใช้งานไม่ได้ บางอันก็ไม่มี เลยคิดว่าทำ checklist ขึ้นมาว่าภาษาควรจะมี library อะไรบ้างถึงจะใช้งานทั่วไปได้บ้าง เวลา evaluate ภาษาจะได้ดูได้ง่ายขึ้นว่ามันพร้อมใช้งานแล้วหรือยัง

Language fundamentals

คิดว่าภาษาสมัยใหม่น่าจะมีพวกนี้อยู่แล้ว อาจจะเป็น first class เลยด้วยซ้ำคือรองรับในภาษาเลย ถ้าเป็นภาษาเก่าแบบ C อาจจะไม่มี

  • Unicode string และ function ที่จัดการกับตัวอักษร เช่น to uppercase, lowercase
  • Byte array (uint8 array) ในบางภาษามีแต่ string ก็มี ไม่สามารถเก็บ raw bytes ได้
  • Data structure ต่างๆ ที่สำคัญคือ ArrayList (Array ที่ไม่ระบุจำนวนสมาชิกล่วงหน้า) และ Map (Key-value store)
  • Threading ซึ่งถ้าเป็นภาษาเฉพาะทางหน่อยอาจจะไม่มี เช่น PHP หรือ JavaScript จะไม่อยู่ในแกนของภาษา
    • Synchronization primitives เช่น Mutex, RWLock, Barrier, Atomic operations
  • Timers ต่างๆ เช่น get time, sleep, monotonic clock (นาฬิกาที่เดินไปข้างหน้าอย่างเดียวถึงแม้ user จะปรับเวลาเครื่อง)
  • Date/Time calculation (with timezone) ซึ่งความยากคือ timezone เป็นข้อมูลที่ dynamic ประเทศต่างๆ อาจจะปรับเวลา daylight saving เมื่อไรก็ได้ บางภาษาเช่น Java ก็รวมฐานข้อมูลเข้ามาใน runtime บางภาษาเช่น Python ก็มีการเก็บ timezone แต่ไม่มีข้อมูลโลกจริงต้องไปใช้ library ภายนอก (pytz)
  • String templating พื้นฐาน ก็คือแบบ sprintf
  • Regular Expression
  • Pseudorandom และ Secure random
  • Path mutation function เช่น basename, dirname, join path
  • OS signal handler (ทำอย่างไรเมื่อโดน SIGINT?)

อีกส่วนที่จะช่วยได้เยอะ คือภาษาสามารถโหลด dynamic library ภาษา C เข้ามาได้และเรียกฟังค์ชั่นจากภาษา C ได้ซึ่งจะทำให้การต่อยอดขั้นถัดไปได้เยอะ

Interop

โปรแกรมที่ยากกว่า Programming มัธยมมักจะเริ่มต้องเชื่อมต่อกับระบบอื่นๆ บ้าง ซึ่งที่คิดว่าจำเป็นจะต้องมีคือ

  • Base64
  • JSON serializer/deserializer ซึ่งถ้าให้ดีควรจะใช้งานกับ data structure ใดๆ ของภาษาก็ได้ (POJO)
  • TCP/UDP socket
  • TLS socket ซึ่งง่ายที่สุดก็คือใช้ C FFI คุยกับ OpenSSL แต่บางภาษาก็อาจจะ implement ใน runtime แล้วไม่มี API ให้
  • Data encryption, hashing ซึ่งส่วนมากที่เห็นก็จะใช้ OpenSSL ทำเหมือนกัน
  • Byte stream encoder/decoder
  • Gzip
  • HTTP ซึ่งต้องใช้ฟีเจอร์หลายๆ ข้อด้านบน

Advanced language fundamentals

  • Unit testing library
    • Report เป็นแบบ Junit XML (ซึ่งก็น่าจะต้องมี XML encoder)
  • Documentation generator บางภาษาอาจจะไม่มีที่เขียนในภาษาตัวเอง แต่ไปแก้ tool ภาษาอื่นเช่น Sphinx, Doxygen ให้เข้าใจไฟล์ของมันได้แทน
  • Command line argument parser ผมค่อนข้าง prefer แบบ UNIX แต่บางภาษา (เช่น Go) ก็ทำแบบของตัวเองก็มี
  • Async IO บางภาษาก็ built in ไปเลย เช่น Go หรือหลายๆ ภาษาก็มี await keyword แล้วแต่ยังต้องแยก function ระหว่างประเภทที่เป็น sync กับ async ซึ่งผมคิดว่าไม่ดีเท่าไร (What color is your function?) จุดที่น่าสังเกตในภาษานั้นๆ คือใครจัดการ event loop เช่นใน Go, JavaScript นั้น runtime จัดการให้ ส่วนใน Python ถึงจะมี async แต่เราต้อง start event loop เองทำให้ทำงานลำบาก เรียกว่ามีเป็น library ยังไงก็ไม่ดีเท่า support ภายในภาษาเอง
  • Templating ขั้นสูง
    • Handlebars คิดว่าเป็นมาตรฐานต่ำสุด คือมี if, loop เท่านั้น
    • ขั้นสูงไปกว่านั้นควรจะมี variable filters (หรือ arbitrary function call), auto HTML escape, template inheritance ซึ่งถ้ามีหมดนี่ เท่าที่เห็นมักจะเป็นสไตล์ Django/Jinja (Smarty/Twig, Twigy, Pongo2)
  • Data validation ซึ่งจริงๆ เขียนเป็น if/else ก็ได้ แต่จะทำให้โค้ดรกและซ้ำซ้อน
  • Big number หรือจำนวนที่ใหญ่กว่าขนาด max int ปกติ
  • Decimal คือจำนวนทศนิยมที่แม่นยำ มักใช้ในการเงิน
  • Logging ซึ่งควรจะมีฟีเจอร์ดังนี้
    • Leveled logging คือกำหนดระดับของ log ได้ เช่น trace, debug, info, warning, error, fatal และปิดระดับที่ไม่ต้องการได้
    • Logging facility คือ config log level/output แยกตาม module ได้
    • JSON format / Human format ท่าที่น่าสนใจคือ library บางตัวเช่น bunyan ออกเป็น JSON เสมอ แล้วค่อย pipe ใส่ tool ให้จัดรูปใหม่บน client side แทน
    • Structured logging คือระบุ key-value ประกอบ log ได้โดยไม่ต้องนั่งเขียน message
  • Curses หรือ terminal GUI

Advanced interop

Standard ใหม่ๆ ที่ใช้หลายอันเริ่มมีความซับซ้อนสูงจนหลายๆ ภาษาอาจจะมีไม่ครบ ซึ่งที่คิดว่าควรจะมีคือ

  • YAML ซึ่งเป็น superset ของ JSON มี edge case มากมาย แต่ก็นิยมใช้เป็น config file จึงควรจะต้องรองรับไว้
  • Protobuf 3 ข้อนี้ผมคิดว่าค่อนข้าง opinionated เพราะ Thrift ก็มีคนใช้พอสมควรเหมือนกัน แต่คิดว่าควรจะมี binary encoding สักรูปแบบที่ portable ข้ามภาษาได้
  • HTTP/2 ผมยังไม่ค่อยเห็นคน implement API HTTP/2 ออกมาตรงๆ จะเป็นลักษณะว่าทำให้ HTTP client ใช้ HTTP/2 ได้แบบ transparent มากกว่า
  • SQL Database Access ซึ่งหลายๆ ภาษามักจะมี API กลาง (PDO, JDBC, database/sql) และ database driver แยกส่วนกันชัดเจน

Use case specific

ในขั้น use case ที่ใช้งานได้จริง ภาษาควรจะมี library พวกนี้ตามแต่ use case

  • gRPC client ถ้ามี 2 ข้อด้านบนแล้วจึงจะสามารถ implement ได้ เช่นเดียวกันผมคิดว่าข้อนี้ค่อนข้าง opinionated มากๆ มันเป็น standard ที่ซับซ้อนมากๆ และยังพอจะ design หลบไปใช้ HTTP ได้อยู่
  • gRPC server คิดว่าควรจะแยกข้อกันกับ client ด้วย ผมคิดว่า server สำคัญกว่า client แต่มักจะ implement ยากกว่า ท่าที่ gRPC เคยทำในหลายๆ ภาษา (Python, JavaScript) คือเรียกไปที่ C FFI เลย
  • Desktop GUI library ซึ่งแม้แต่ใน Go ผมก็ยังเห็นว่ามันยังไม่ค่อย mature เท่าไร
  • Graphics drawing library
  • Image processing เช่น เปิดไฟล์ภาพ ย่อขยาย ปรับสี, สว่าง มืด, blur
  • Generate QR code อาจจะเป็น terminal หรือ image
  • WebSocket client/server
  • Monitoring support เช่น Remote exception catcher, tracing, metrics
  • Unix function ต่างๆ เช่น syslog, shared memory