ได้ไปฟังอะไรที่งาน National Coding Day 2024: Workshop Day บ้าง?
งาน National Coding Day ไม่แน่ใจว่าจัดมาแล้วกี่ปี แต่ปีนี้เป็นปีแรกที่มี workshop ให้เพื่อน ๆ ชาวโปรแกรมเมอร์ได้ลองทำ แล้วเอากลับไปเล่นที่บ้านต่อ
ซึ่งเราก็ได้เป็น 1 ใน speaker ในวัน workshop ด้วยล่ะ ซึ่งไม่ได้มาดินแดนแห่งกระติกนํ้า เอ้ยยยย ที่ไมโครซอฟต์นานมากกกแล้ว ถ้าถามว่านานขนาดไหนอ่ะเหรอ ย้อนบล็อกดูก็ประมาณ 10 ปีที่แล้วอ่ะ สมัยที่ยังมี cross-platform ของ Microsoft อ่ะ นานลื้มมม
Minseo Chayabanjonglerd
แน่นอนว่าไมโครซอฟต์ยังตั้งอยู่ที่เดิม ชั้น 38 ตึก CRC ที่ All Season Place ตอนนี้ฟีลเหมือนมาตามรอยสถานที่ถ่ายทำ MV Supernova ของ aespa แน่นอนว่าตึกใน MV เป็นตึก M Thai คือทางซ้ายมือของรูป
บรรยากาศก็จะเป็นประมาณนี้ ป้ายไมโครซอฟต์ด้านหน้า โซนเครื่องดื่มด้านใน มีกาแฟสดด้วย แล้วก็วิวของตึกนี้
อันนี้ Room 1 และ Room 2 ฝากต๋องถ่ายมาเพื่อดูลาดเลา แหะ ๆ ซึ่งห้องทั้งสามในงานสามารถขยายออกได้นะ ตรงฉากกั้นสีฟ้าอมเขียวอันนั้น
และแน่นอนเรามาไม่ทัน session ตอนเที่ยง แล้วถ้าเข้า Room 1 คือนั่งพื้นแน่นอน
GitHub for Devs: Boost Your Productivity and Innovation | Kittikorn Prasertsak
workshop ของคุณเปรม borntodev มาถึงเจอเรื่อง GitHub Actions ที่สร้าง workflow ในการทำงาน ซึ่งก็ต้องคำนึงถึง security ด้วย ตอนมาเขาก็รันไปได้สักพักล่ะ
จาก Github นี้ ฉันผู้มาไม่ทันตอนแจก Notion ก็พยาย๊ามมมมหาจนเจอ
PrameKittikornGithub Secret เก็บ key ได้ปลอดภัยกว่าไฟล์ .env ที่บางคนอาจจะเผลอ push code ขึ้นไป สามารถไปดูใน Settings แล้วไปที่ Secret and variables แล้วเลือกเป็น Actions สามารถจัดการ secret ต่าง ๆ ในนี้ได้เลย สร้างใหม่ new repository secret แล้วก็ใช้งานเหมือน env ปกติเลย
ส่วนตัว Github Actions สามารถ check pipeline ได้ ถ้าใช้ฟรีเก็บไว้ 3 เดือนก็ถือว่าเหลือเฝือ และดูว่า runtime ต่อเดือนเท่าไหร่ เราใช้เพียงพอไหม
แล้วอันนี้ คือ Cheat Sheet ของ Github Actions ที่ทาง BorntoDev ทำไว้ (แล้วหารูปนี้เจอแค่ในช่องทาง IG 🤔)
Github Copilot มีให้ใช้บน VS Code ใช้แล้วชีวิตดีขึ้นเยอะในบางสายงาน เขียนพวกทำ CRUD (Create, Read, Update, Delete) ปกติ ถ้างานซับซ้อนแบบ 9arm ที่เป็นสายงาน hardware อะไรงี้แนะนำให้เขียนเอง แล้วก็ถาม Colpilot ใน VS Code ได้เลย ราคาค่อนข้างถูกกว่า เลือก model เองได้ว่าอยากใช้เจ้าไหน
tool ที่เหมาะกับ senior ที่ดูแลน้อง ๆ สามารถใช้บริการ Github Codespaces เหมือนเป็นคอมใน online มีการ set environment ต่าง ๆ ไว้แล้ว และเลือก template ให้ ส่งลิ้งไปให้น้อง ๆ ลองเล่นได้ ถ้าอยากได้เครื่องแรง ๆ สามารถ setup ผ่าน on-cloud ได้เลย
(ก็คือจริง ๆ เราเห็นคนใช้สิ่งนี้ demo มาก่อน พอเรามาเตรียม workshop ก็ติดเรื่อง node version ก็เลยใช้อันนี้ในการ workshop แหละง่ายดี เขารองรับ node 20 เลยนะ อีกความจริงนึงคือทางเราเป็น Android Developer ซึ่งในงานแน่นอนว่าไม่ได้แตะอะไรพวกนี้เลย)
สุดท้ายฝากร้านคอร์สฟรี สำหรับการใช้ Github แบบพื้นฐาน
และอันนี้คือ Notion ของ session นี้ฮะ
Solving the “Developer’s Experience Equation” | Dave Rawitat Pulam
เป็น session ที่คนมานั่งฟังจนต้องขยายห้อง และเป็นแนว talk show 90 นาที ไม่มีสไลด์ มีแต่เขียนบนกระดาน กราบคาวระเลยฮะ
Choice ของ Programming language มีผลอย่างไรต่อ experience เช่น ประเด็นที่วงการเราถกเถียงกันเมื่อไม่นานมานี้ อย่างภาษา Rust vs Go
Context Switching มีผลอย่างไรกับ dev? เช่น แก้งานด่วน production ไฟไหม้ แล้วต้องรีบแก้ แล้วจำได้ไม่หมดว่าต้องแก้ยังไง
Production Development เช่นสถานการณ์ในตอนนี้ ไม่มีสไลด์ แต่จอโปรเจกเตอร์เปิดปิด และต้องขยายห้อง
ทีมที่มีขนาดใหญ่ขึ้น คนในทีมของเรารู้อะไรอยู่ก่อนแล้ว และรู้อย่างไร เช่น ถามเรื่อง OOP อาจจะได้คำตอบจากแต่ละคนที่ไม่เหมือนกัน, user ของเราคือใคร แล้วเข้าใจพื้นฐานตรงกันหรือไม่ ถ้าไม่ check ความเข้าใจตรงกับแล้วจะส่งผลไปที่ production on prod
อะไรคือ equation และทำไมต้อง solve มัน?
ให้ในห้องยกตัวอย่างสมการมา จะได้ประมาณนี้
v = at
E = mc^2
F = ma
a^2 + b^2 = c^2
w = fs
คำตอบแรกตอบยาก คำตอบต่อมาเริ่มง่ายขึ้น
และทั้งหมดมาจากฟิสิกส์หมดเลย มาจากความสัมพันธ์ระหว่างกัน ถ้าให้ค่านึงมา ก็จะหาค่าที่เหลือได้ เช่น จากสมการ v = at ให้ v มา ให้ t มา เราก็หา a ได้ถูกม่ะ
ซึ่งการ solve ไม่ยากเท่าการสร้างสมการ แล้วสมการพวกนี้ถูกสร้างมาได้ยังไง?
เช่น ถามคนในห้องว่าเป็น developer หรือไม่? จะได้ผลเป็น Boolean คือ ใช่ไม่ใช่
Software Developer เท่ากับ programmer หรือไม่? เราใช้นิยามในการตอบต่างกัน เราต่างไม่รู้นิยามซึ่งกันและกัน เราไม่สามารถใช้ common sense ทั้งหมดได้ ความเข้าใจของเราไม่ตรงกันเสมอ แต่จะมีจุดที่ตรงกลางตรงกัน แบบ intersection กัน
Functional programming เช่น microservice
แล้วภาษา programing คู่อื่น ๆ ในห้องยกตัวอย่าง Python vs Ruby, Clojure vs Scala, Java vs C#, PHP vs Perl, js vs java, js vs ts, Lua vs Ruby ถ้ามันไม่มีผลเลยคนจะไม่เถียงกัน (กะจะตอบ Java vs Kotlin หรือ Objective-C vs Swift ล่ะ แต่ฝั่ง mobile native มันไม่ได้เปลี่ยนภาษาบ่อยเท่าสาย web dev แหละ ฝั่งเราเปลี่ยนไปใช้ตัวใหม่ที่ดีกว่า)
ปล. ภาษา C# มาจาก C++++
equation เป็น subset หนึ่งของ model แล้วไม่จำเป็นต้องเท่ากันด้วย แปลว่า become ก็ได้ เช่น f(x) = 3x + 5 เราใช้เครื่องหมายเท่ากับได้หลายความหมาย ก็คืออะไรมาผสมกับอะไร แล้วกลายเป็นอย่างไร
แล้วต้องเป็น model ยังไง แล้วเกิดขึ้นได้อย่างไร?
อะไรคือความแตกต่างในการสร้างจรวด และการสร้างบั้งไฟ? สเกล ความซับซ้อน และอีกหลายเรื่อง ถ้าเรากำลังสร้างบั้งไฟไปดวงจันทร์จะได้ไหม ถ้าได้ก็ดี
แล้ววิธีการสร้าง model ล่ะ?
Developer experience คำตอบตอบไม่ง่าย ถ้ายกตัวอย่าง good และ bad เราอาจจะตอบได้ แล้วเข้าใจมันง่ายขึ้น ต้องตอบสองปัญหาสองอันนี้ให้ได้ วิธีการอะไรที่แปลงตัวนี้ไปตัวนั้นได้ และให้มีดีขึ้นได้อย่างไร
เอา good กับ bad มา union ได้ DevEx as a result
การพูดเรื่อง set ทางคณิตศาสตร์
- คุยเงื่อนไขแบบ non-binary
- แจกแจงสมาชิกแต่ละตัว
แล้วมันต่างกันยังไง มีปัจจัยอะไรบ้าง ขนาดเป็นยังไง
แล้วปัจจัยอะไรที่ทำให้ A เกิด B
f(x) => e ε Exp
e คือมีผลต่อ experience ยังไงบ้าง
เช่นทำ web app ทำ CRUD 1 row จะทำยังไงได้บ้าง เช่น
- ใช้ assembly ซึ่งเป็น set ของภาษา (x86) แล้วประสบการณ์ชีวิตดีไหม แน่นอนว่าไม่! คนใช้คือ hardware programmer, system programmer
- ใช้ PHP อาจจะไม่ได้ชอบ แต่มันง่ายที่สุด แล้วง่ายสำหรับเราคนเดียว หรือคนอื่นในทีมด้วย
แล้วเลือกภาษาโปรแกรมตามอะไร เช่น ใช้ตามบอเทคชั้นนำ ดูจาก architecture
แล้วมีเวลาให้เรียนรู้นานเท่าไหร่ และมีผลหรือไม่ เช่น
- บางคนใช้เวลาส่วนใหญ่กับอ่านโค้ดชาวบ้านจาก code review แล้วกด merge branch แล้วเราดูอะไรบ้าง เช่น commit message `conbine bug fixed` ซึ่งกี่ตัวก็ไม่รู้ and `feature update`
- File change มี 1 file change ไฟล์ใหญ่ที่สุดเคยเจอมา ไฟล์ใหญ่ที่ speaker เจอมาคือหกหลัก ชงกาแฟเสร็จยังเปิดไฟล์ไม่ได้ มี attibute เกือบหมื่น และไม่มี unit test ที่ speaker เจอมา method สั้นสุด 1 บรรทัด ยาวสุด 1000 บรรทัด คนอื่นอาจจะเจอยาวกว่านี้ก็ได้แต่อย่าเลยมันน่ากลัว
- ดูอะไรได้อีกบ้าง: line change, commit date
จากสถานการณ์แบบนี้ แน่นอนมันต้องเป็น bad แหละ
แล้ว change นี้เกิดมาเพื่อสร้าง feature หรือแก้บัค เราไม่รู้ แล้วใช้พลังงานกับสิ่งที่ไม่ควร figure out แล้วเราจะไป cheery pick ที่ตรงไหน ก็ไม่รู้
ดังนั้น 1 commit เป็น 1 งานที่เล็กที่สุดที่เป็นไปได้
ความเป็นไปได้ที่จะไม่เจอคน commit แบบนี้ก็ยังมีอยู่
เราควรแยกโปรเจกต์ในการเรียนรู้การทำงาน หรือทำใน production code
เราควรแยก poc code จากงานจริงหรือไม่ ถ้าไม่แยกเกิด Test on production
แล้วเรา commit code บ่อยแค่ไหน?
Model เช่น มีโลก มีเรา, ทำไมสองโปรแกรมนี้ไม่เหมือนกัน, ทำไม software สองตัว ทำไมคนใช้เยอะใช้น้อย, ทำไม software โตเร็วจัง หรือทำไมช้าจัง, ทำไมคนนี้นิสัยไม่ดีจังน้า
ถ้าไม่มีความแตกต่าง เราจะสังเกตุอะไรได้บ้าง พอมีความแตกต่างก็สามารถเทียบกันได้ หรือตัวมันเทียบตัวมันเอง ในเวลาแตกต่างกัน
เช่น ล้างรถและฝนตก เป็นความบังเอิญทางวิทยาศาสตร์
เปลี่ยน stage ได้ด้วย energy แล้ว software ของเราตอนนี้ stage เป็นยังไง โดย stage ปัจจุบัน เป็น s+ และ stage ที่เปลี่ยนไปเป็น s+ + ΔT โดย ΔT ต้องมีค่าน้อยที่สุดที่เป็นไปได้ คือเข้าสู่ศูนย์ ซึ่งความจริงเป็นไปไม่ได้ เช่น sprint นึงมี 2 weeks แล้วระยะเวลานี้บริบทใดควรใช้บ้าง
Commit วันละครั้งใหญ่ไหม ใหญ่ แต่อาจจะไม่ใหญ่ก็ได้แล้วแต่อีก
สมการฟิสิกส์บอกความจริงอะไรบางอย่าง observe อะไรบางอย่างกับ physical world แล้วไปทดลองออกมาเป็น understanding กลายเป็น model ต่าง ๆ และคนสนใจตรงที่ action/practice ว่าปัญหาตรงนี้แก้อย่างไร
ฟิสิกส์เป็น study natural ด้วยวิธี แล้วเปลี่ยนแปลงเป็น dynamic อย่างไรได้บ้าง? ในการสร้าง model ในทดลอง paradigm มี pillar 3 ตัว หนึ่งในนั้นมีระบบ
- ระบบ คือ system ประกอบด้วย components ต่างๆ ในระบบ และ define คุณสมบัติบางอย่าง default คือมีอะไรที่มันต้อง solve มี solvsing stage เป็นภาวะ และมีแรงเป็นตัวเปลี่ยน stage อะไรที่มีผลต่อการเปลี่ยน stage ของ software ล่ะ เช่น ความต้องการของลูกค้า, user, feedback, คู่แข่ง, การเมืองในองค์กร, เปลี่ยนผู้บริหาร, เปลี่ยนกฏหมาย, เปลี่ยนงบประมาณ และทีมเราเป็นส่วนนึงในการเปลี่ยนแปลงหรือไม่ และมีผลขนาดไหน
- แล้วเอาอะไรกระจาย knowledge energy หรืออะไร เชื่อมน้อยลงความแตกต่างมากขึ้น
- nagative energy negative experience หรืออะไรเล็ก ๆ น้อย ๆ ทีมใหญ่ขึ้น common น้อยลงเป็นธรรมชาติ ถ้าไม่ agree bottom why ในจุดนึง แล้วเปลี่ยนยังไงได้บ้าง เช่น coding convention แล้วโค้ดเขียนมาจากความเข้าใจบางอย่าง และเคยเอา model มา develop บางอย่างไหม แยกตาม base-on ความเข้าใจที่ตรงกัน แปลงให้มัน eligible ขึ้นเรื่อย ๆ commit มาจาก complement ว่าเราจะต้องทำอะไรบ้างก่อนเริ่มทำงาน เหมือนเล่นเกมส์เก็บเควส ให้แตกงานออกมาเป็น task ย่อย ๆ commit ละ 1 ชั่วโมงโดยประมาณ ทั้งทีมจะรู้ก่อนได้
ทำไม estimates ไม่แม่น เพราะมันก็ไม่น่าแม่นอยู่แล้วนั่นเอง
อันนี้รูปที่จดจากกระดาน
หลังจาก session นั้นคนมีเริ่มทยอยกลับล่ะ เราก็ไปเตรียมพูด session ของเราต่อ แหะ เป็นห้องเล็ก ประมาณสิบกว่าคนได้ หลาย ๆ คนก็ทำตามไปเรื่อย ๆ แต่จะเดินไปส่องก็เกรงใจ แหะ ๆ ช่วงหลังเลยเน้นอธิบายเพราะดีเทลมันก็เยอะแหละ ทุกคนก็ได้ของกลับบ้านไปทำต่อ
ตัวสไลด์เป็นอันนี้
เดี๋ยวจะทำเป็น hands-on ให้ทำตามกันง่าย ๆ อดใจรออีกหน่อยนึงนะ
สุดท้ายนี้ก็ขอบคุณทุกคนที่มางานนี้ แล้วก็มาฟัง session เราด้วยนะ ตอนกลับก็ไปรับของที่ระลึกจากทางสมาคมโปรแกรมเมอร์ และคุยกับทีมงานนิดนึงก่อนกลับ ทุกคนดูแลดี แอบเกร็ง ๆ เล็กน้อย ไม่ค่อยได้เจอคนในสมาคมเท่าไหร่ 😆
ติดตามข่าวสารตามช่องทางต่าง ๆ และทุกช่องทางโดเนทกันไว้ที่นี่เลย
ติดตามข่าวสารแบบไว ๆ มาที่ Twitter เลย บางอย่างไม่มีในบล็อก และหน้าเพจนะ
สวัสดีจ้า ฝากเนื้อฝากตัวกับชาวทวิตเตอร์ด้วยน้าา
— Minseo | Stocker DAO (@mikkipastel) August 24, 2020
