บันทึกจาก Conference🎤 — National Coding Day 2024
สวัสดีครับ ผมได้มีโอกาสไปงานใหญ่ประจำปีสำหรับชาว Dev อย่าง National Coding Day ซึ่งปีนี้สถานที่จัด Conference คือ True Digital Park ในบทความนี้จะมาสรุปเนื้อหาบางส่วนในแต่ละเซสชันที่ผมได้เข้าร่วมกันครับ
Why is coding in English
When learning to code, you don’t need to know one language, you need to know two, English and code.
เป็นหัวข้อที่น่าสนใจผิดคาด เพราะความคิดของเราคือ Coding ยังไงก็ต้องใช้ภาษาอังกฤษเป็นหลักสิ แต่ถ้าเราลองเปลี่ยนจากชื่อ function เป็นภาษาท้องถิ่นคงจะรู้สึกแปลกไม่น้อย คุณ Anthony Shaw ได้พามาสำรวจแง่มุมต่างๆ ของภาษาที่เราใช้สื่อสารกับโค้ดที่เราเขียน ด้วยข้อมูลและสถิติต่างๆ แล้วทำไม English ถึงกลายเป็น Standard ล่ะ คงด้วยความง่าย และมีแบบแผนชัดเจน เหมาะมากพอมาเป็น ASCII และต่อให้นักพัฒนาคุยกันด้วยคนละภาษา แต่ก็ยังอ่านโค้ดให้เข้าใจได้ตรงกัน
อีกประเด็นนึงที่ชอบคือ เรามองตัวภาษาเป็นตัวกลางในการสื่อสาร แล้วอาจเป็นตัวกำหนดขอบเขตการถ่ายทอดไอเดียและความรู้ด้วย กล่าวคือ ถ้าคนในทีมเรามี Skill สูงมาก แต่ไม่ได้พูดภาษาเดียวกับเรา เขาอาจจะไม่สามารถสื่อสารไอเดียที่คิดกับทีมได้แบบ 100% ด้วยกำแพงของภาษา
พูดถึง LLM กับภาษา เจ้า AI เองไม่ได้รับรู้ภาษาแบบที่เราเข้าใจ แต่มันรับข้อมูลเป็น Byte Pair Encoding แบ่ง Token ตรงนี้ทำให้มันเก่งการตอบภาษาอังกฤษมาก พอเป็นภาษาไทยจะเห็นข้อจำกัดที่ชัดเจน ทั้งจำนวนข้อมูลที่น้อยเมื่อเทียบกับภาษาอื่น การหยุดประโยคที่ไม่มีจุด (.) และปัญหาคลาสสิคอย่างการแบ่ง Spacing อย่างไรก็ตามมีโมเดลที่คนไทยพัฒนาอย่าง Typhoon ให้ลองไปใช้กันดูได้
สุดท้ายอยากให้ Embrace และกระตุ้นให้นักพัฒนาได้ Communicate กันด้วยภาษาอื่นๆ รวมถึง Tools for non-English ให้มากขึ้นด้วย
Data is not SEXY anymore
ทุกคนมีความเป็น Data Analyst อยู่ในตัว
พี่ทอยเริ่ม Session ด้วยการไล่เรียง “ยุคสมัยของข้อมูล” ตั้งแต่
- การบันทึกลงกระดาษปาปิรุส
- การทำสำเนาจำนวนมากด้วยแท่นพิมพ์
- สร้างเครื่องคำนวณ เพื่อวิเคราะห์และประมวลผลข้อมูล
- เข้าสู่ยุค WWW (World Wide Web)
- สร้าง Smart phone ของ IBM
- Search engine ที่เข้ามามีบทบาทในโลก Digital
ถัดมาเป็น Breakthrough ของ AI
- ปี 2012 กำเนิด AlexNet โดยผู้ร่วมออกแบบมีแต่ตัวตึงวงการทั้งนั้น
- Start with AI Seeing เมื่อคอมพิวเตอร์เริ่มมองเห็นเหมือนมนุษย์
จะเห็นการพัฒนาทุกอย่างล้วนต่อยอดจากสิ่งเก่า และกลายเปลี่ยนแปลงเป็นสิ่งที่หลีกเลี่ยงไม่ได้เลย
คราวนี้พูดเปเปอร์สุดฮอตเมื่อหมายปีที่แล้ว Data Scientist: The Sexiest Job of the 21st Century แต่แล้วในปี 2022 ก็มีบทความ Is Data Scientist Still the Sexiest Job of the 21st Century? จากผู้เขียนคนเดิมออกมา สรุปแล้วมันยังไงกันแน่
“Data ไม่ sexy แต่กลายเป็นความจำเป็น” ไม่ได้มีความดึงดูดแต่ก็ขาดไม่ได้สำหรับธุรกิจและองค์กร ข้อมูลทำให้เราตัดสินใจได้ดีขึ้น สุดท้ายเราใช้ข้อมูลเพื่ออะไร แน่นอนว่าไม่ใช่แค่ output ที่บอกว่าโมเดลเก่งแค่ไหน แม่นยำเท่าไหร่ แต่เป็น outcome ที่จะต้องสร้าง Impact และตอบโจทย์ธุรกิจรวมถึงแก้ปัญหาให้เราด้วย
พี่ทอยทิ้งท้ายว่า Intelligence คืออะไร ถ้ามันคือความฉลาด แล้วเราจะฉลาดเพื่ออะไร คำตอบคือ เพื่อให้เราสามารถอยู่รอด (Survive) ในโลกที่มีการเปลี่ยนแปลงได้
Enjoy Coding in the Age of GenAI: Tips for Programmers
ถ้าเรารู้ว่าเราทำสิ่งใดแล้วมีความสุข เรามักจะทำสิ่งนั้นได้ดี
พี่ๆ จาก BorntoDev มาแชร์ใน Session นี้ โดยตั้งคำถามว่า เรามีความสุขในการเขียนโปรแกรมไหม ถ้ามีสิ่งนั้นคืออะไร?
- ได้คิดไอเดียใหม่ๆ
- แก้ไขปัญหาต่างๆ
- ได้ลองจับเครื่องมือใหม่ๆ
แล้วสิ่งที่ไม่ทำให้ไม่มีความสุขล่ะ?
- การเริ่มต้นโปรเจคใหม่
- ใช้เครื่องมือที่ไม่คุ้นเคย
- เจอ Bug ที่แก้ไม่ได้
เอาล่ะ ถ้ามีเครื่องมืออย่าง AI เข้ามาช่วย จะทำให้ทุกอย่างง่ายขึ้นไหม
- ใช้ Prompt เพื่อถาม-ตอบสิ่งที่ต้องการ หรือ Generate codeโดยถ้าเรารู้ Pattern ที่ใช้บ่อยๆ สามารถสร้างเป็น Template เพื่อช่วยเขียน Prompt ให้ง่ายและสะดวกขึ้น
- ใช้ AI มาช่วยใน SDLC ตั้งแต่ Planning วิเคราะห์ Requirement เป็นคู่ Pair ตอนเขียนโค้ด รวมถึงเขียนเทสหรือช่วยเจนข้อมูลให้ด้วย
ทั้งนี้ AI เหมือนดาบสองคม ถ้าเราเชื่ออะไรไปเสียทุกอย่าง เราอาจลำบากทีหลังได้ ควรใช้บนฐานความเข้าใจ ใช้ให้เหมาะสมกับงาน สิ่งที่สำคัญไม่แพ้กันคือผู้ใช้งาน AI ต้องมีพื้นฐานในความรู้ในด้านนั้นๆ เพียงพอเพื่อให้ใช้ประโยชน์ได้สูงสุดนั่นเอง
Data Model: Your Way to Success with MongoDB Developer Tools
Data Modeling is not so different from plaining a route.
หัวข้อนี้มาคุยเรื่อง Data Model โดยพี่ๆ จาก MongoDB Thailand User Group
แน่นอนว่า Relational มาก่อนอย่างช้านาน ใจความหลักคือ
- Schema: กำหนดรูปแบบและลักษณะของข้อมูลในฐานข้อมูล
- Relation: ความสัมพันธ์ระหว่างข้อมูลในตารางต่างๆ ผ่านคีย์ (Keys) เช่น Primary Key และ Foreign Key เพื่อสร้างการเชื่อมโยงระหว่างข้อมูลในฐานข้อมูล
- Normalization: กระบวนการจัดการโครงสร้างข้อมูลให้เหมาะสม โดยลดความซ้ำซ้อน (Redundancy) และป้องกันความผิดพลาด (Anomalies) ในการจัดเก็บข้อมูล เช่น การแยกข้อมูลออกเป็นตารางย่อยที่มีความเฉพาะเจาะจง
พอเป็น MongoDB ซึ่งจัดเป็น Document database ซึ่งมีแนวคิดสืบมาจาก Key-Value Database แต่มอง value เป็น data บางอย่างที่จัดเก็บเป็นโครงสร้าง อีกข้อที่สำคัญคือ สิ่งไหนที่ถูก Access พร้อมกัน ควรเก็บที่เดียวกัน
จุดเด่นของ Session นี้คือมีการจำลอง Situation เพื่อให้เห็นภาพตัวอย่างในการเอาใช้งานจริง อธิบายเรื่องการเลือกใช้ Access Pattern และ Trade-off รวมถึงวิธีการปรับปรุง Collection แบบปลอดภัย
Embedding vs Referencing
- Embedding: Read performance ดี ใช้แค่ operation เดียวในการดึงข้อมูล แต่ระวังต้องเรื่อง Document size ที่ใหญ่เกินไป (Limit 16MB)
- Referencing: ลดโอกาสที่ Document size จะเกินลิมิต เพราะใช้ reference เอา แต่ตอนดึงข้อมูลจะมีความซับซ้อนและช้าลงได้
มีการแนะนำ MongoDB Atlas CLI สำหรับ automate management และ MongoDB for VS Code ให้ใช้ในงาน dev ได้สะดวกขึ้น นอกจากนี้พวก MongoDB Compass ใช้เป็น Analysis tools ก็จำเป็น เพื่อ Optimize ได้เพิ่มเติม
ตอนจบ Session ผมได้มีโอกาสถามพี่ๆ Speaker เพิ่มเติม เกี่ยวกับการใช้ Schema Validation ได้ความว่าจริงๆ ข้อดีของ MongoDB ที่ทุกคนทราบคือความยืดหยุ่นและปรับได้ง่ายในช่วง Early stage ที่รองรับโครงสร้างที่จะปรับเปลี่ยนได้อีก การ validate ขึ้นอยู่กับหลายปัจจัย เช่น เราต้องมั่นใจมากว่าโครงสร้างที่เป็นผลลัพธ์ของเราจากการออกแบบนั้นสมบูรณ์มาก ซึ่งจะไปคล้ายกับแนวคิดแบบ Relational อีกกรณีคือเราแคร์ความถูกต้องของโครงสร้างข้อมูลมาก โดยเฉพาะการที่เราต่อฐานข้อมูลกับหลายๆ แอปและไม่มั่นใจว่าข้อมูลที่ได้รับเข้ามาจะสอดคล้องกัน ก็ใช้ Schema Validation ได้ โดยมี Concern เล็กน้อยเกี่ยวกับ Performance ในขา Write เปรียบเหมือนรถที่วิ่งอยู่แล้วมีด่านตรวจจำนวนมากๆ ทำให้ไปถึงที่หมายได้ช้าลงนั่นเอง
Domain-Driven Design in Action: Lessons Learned from Developing Thailand’s Lottery Platform
การสร้างว่าลำบากแล้ว การดูแลรักษายากกว่าเยอะ
Session นี้นำโดยพี่ต้น มาแบ่งปันเรื่องราวของการทำ DDD กับโปรเจค Lotto (บอกตามตรงผมสนใจโปรเจคนี้ตั้งแต่สมัยตอนสอบสัมภาษณ์เข้า Arise by INFINITAS วันนี้ได้ฟังแบบเต็มๆ ซักที)
โดย Overview เป็น DDD ตามฉบับมาตรฐาน แต่ที่น่าสนใจและสำคัญที่สุดคือ การทำความเข้าใจ Business เอาล่ะ คงมีคำศัพท์มากมายที่คนเล่นลอตเตอรี่เขารู้ แต่ Dev เกาหัวไม่หยุดเช่น รูดหน้า วิ่งบน หวยฮานอย ฯลฯ สิ่งเหล่านี้ต้องอาศัย Domain expert มาช่วย พอจัดการ Ubiquitous language เสร็จก็ทำ System Design, Flow UXUI และ User Story Mapping เพื่อให้เข้าใน User journey
พูดถึงการจัดการทีม แบ่งเป็น Squad ใช้ Scrum ซึ่งต้องมีการ Communication ที่แข็งแรง ทั้งระหว่าง BA + Developer และ Tester เพื่อให้โฟกัสและ Manage งานในทีมได้ ลด overhead
กลับมาที่ Bounded contexts แล้วแจกจ่ายแบ่งงานให้แต่ละทีม พิจารณาวิเคราะห์ Domain หรือแบ่ง Sub Domain ตามข้อมูลที่มีอยู่ พอทุกอย่างเริ่มเข้าที่ก็ลงแรง resource ได้อย่างมีประสิทธิภาพ เช่น
- Core ซึ่งเป็นหัวใจหลักของธุรกิจ ยังไงต้องใช้คนของเราเอง
- Generic สามารถหาเครื่องมือมาช่วยทุ่นแรงได้ ไม่ต้องทำเองทั้งหมด
- Support อาจจะใช้ของที่มีพร้อมอยู่แล้วเช่น Customer profile จาก Core Bank
มีการยกตัวอย่างเรื่อง Gap analysis จาก Existing system เราพิจารณาดูก่อนว่ามีระบบไหนในองค์กรที่ใกล้เคียงกันและสามารถนำมา Reuse ใช้ได้เลย ซึ่งในความเป็นจริงอาจมีระบบที่ใช้หลักการใกล้เคียงกัน แต่สุดท้ายก็นำมาใช้ไม่ได้ก็มี
ทีมได้ออกแบบ ER Diagram เริ่มต้นจากไม่กี่ตาราง แต่พอทำ Tactical Design with Aggregate ไปเรื่อยๆ เราจะได้เห็น Domain ใหม่ๆ ที่ตอนแรกไม่มีออกมาอีกเพียบ
พูดถึง Non-functional requirement ซึ่งมักจะเกี่ยวข้องกับ stability and security เป็นสิ่งที่ต้องพิจารณาตั้งแต่แรก เช่น ผู้ใช้งานกี่คน พีคช่วงไหนบ้าง สัดส่วนการใช้งานในแต่ละ Feature ซึ่งในบางครั้งเราคงไม่รู้หรอกว่าเท่าไหร่ และครอบคลุมไหม ต้องปรับจูนอย่างต่อเนื่อง Keyword คือ Speed และ Volume
สุดท้ายการทำ DDD ให้สำเร็จ ต้องอาศัยความร่วมมือหลายฝ่าย และการนำ Session ต้องใช้คนที่มี Know-how สามารถจูงใจและพาทีมไปสู่เป้าหมายได้
AI Safety 101
In the future world where AI can help us achieve whatever we desire, Awareness and understanding our own desire will become a crucial skill.
เริ่มต้นพี่คริสจำลองสถานการณ์ว่า ถ้าเราบอก AI ให้ไปเก็บสะสมแสตมป์ให้หน่อย โดยที่ไม่ได้กำหนดวิธีการใดๆ อะไรจะเกิดขึ้น ถ้าคิดแบบโลกสวยก็คงไปหาแลกสะสมแบบปกติ แต่ตรงกันข้ามมันอาจจะคิดการใหญ่กว่านั้นเช่น ชิงมาจากเจ้าของ หรือ Hack ระบบเพื่อทำให้ได้แสตมป์จำนวนมากกับเรา (ซีนนี้แอบนึงถึงสแตนด์ Harvest ของชิเงจี้เลย)
ชี้ให้เห็นว่า Artificial General Intelligence (AGI) ที่เราสร้างเพื่อให้คิดและทำงานแทนเราให้บรรลุเป้าหมาย แต่ก็ต้องมี “กรอบบางอย่าง” เพื่อไม่ให้มันทำอะไรที่แปลกจนเกินไป สรุปได้ว่า อยากให้ AI เก่งแบบเว่อวัง แต่ก็ต้องมีกรอบที่เก่งกว่าไว้ใช้ป้องกัน แบบนี้มันดูย้อนแย้งหรือเปล่านะ จากนั้นพี่คริสก็เริ่มแชร์เกี่ยวกับ Alignment Problem ทำยังให้ AI ทำในสิ่งที่ต้องการ แต่ไม่ใช่ควบคุม
Avoid Negative Side Effect
- Maximizer: ยกตัวเช่นบอกทำให้มนุษย์มีความสุข มันอาจจะลงเอยด้วยการมาควบคุมสารเคมีในสมองคนเพื่อให้รู้สึกดี
- Satisfier: แสวงหาแนวทางที่ “ดีพอ” โดยไม่ก่อให้เกิดความเสียหาย และไม่เกินขอบเขตที่มนุษย์จะแก้ปัญหาได้
- Quantifier: พยายามใช้การวิเคราะห์แบบความน่าจะเป็นเพื่อลดผลกระทบที่ไม่พึงประสงค์ แต่ AI ก็จะคิดเกินไปกว่าเราไม่ได้
Avoid Reward Hacking
คือ AI จะทำอะไรให้ตรงแบบแผนที่วางไว้ เพื่อให้ได้รางวัลตามที่คาดหวัง (Reward) แต่มันก็อาจจะมีกรณีที่มันแอบโกงได้ เช่น บอกให้หาข้อมูลเกี่ยวกับหมูเด้ง เราอ่านแล้วรู้สึกว่ามันไม่ใช่ เลยขอแหล่งที่มาจาก AI เจ้า AI ก็หัวหมอไปแก้ Wikipedia แล้วกลับมาบอกว่านี่ไงแหล่งอ้างอิง (ที่แก้เองกับมือตะกี้) เอาล่ะ เรามีวิธีแก้เผ็ดมันไหมนะ
- RLHF: เป็นเทคนิคการเทรนโมเดลโดยอาศัยมนุษย์จริงๆ มาให้ Feedback ซึ่งความยากคือมันไม่ได้มีอะไรที่แน่นอนขึ้นกับคนให้ Feedback เลย รวมถึงเคสการจงใจตีกรอบแบบอ้อมๆ เช่น พ่อแม่บางคนอยากให้ลูกเป็นหมอ แต่ไม่ได้บอกแบบตรงๆ แต่จะสื่อแบบอ้อมๆ เวลาลูกชอบหรือสนใจอะไรที่เกี่ยวข้อง และทำท่าที่ผิดหวังเวลาลูกไปสนใจอาชีพอื่น เป็นต้น
- KL Divergent: พยายามให้ AI ตอบอยู่ในร่องในรอย ไม่ตอบอะไรที่ผิดแปลกไปจากเดิมมาก โดยใช้สูตรคำนวณ
Instrumental Convergence
- Terminal Goal: เป้าหมายปลายทาง เช่น อยากมีครอบครัวใหญ่และอบอุ่น
- Instrumental Goal: เป้าหมายย่อย เช่น มีเงินทอง มีบ้าน มีคู่ครอง
ในทุกวันนี้ นักลงทุนสนใจมุ่งเป้าให้แต่ AI ฉลาดอย่างไม่หยุดยั้ง ส่วนเรื่อง AI Safety กลายเป็นประเด็นที่นักวิจัยและคนทั่วไปให้คำนึงถึง
A Practical Guide to Managing Argo CD Multi-tenancy
ถ้าไปดู principles ของ GitOps จะพบว่าไม่มีข้อไหนพูดถึง Git เลย
พี่จาก ODDS ได้มาแชร์แนวคิดและกระบวนการทำ GitOps ส่วนตัวยังไม่ได้ลองทำและศึกษาแบบเต็มรูปแบบ คิดว่าหัวข้อนี้น่าจะมีประโยชน์ เริ่มจาก
Desired state → Actual state
Desired state คือสถานะที่เรากำหนดว่าต้องการที่จะเป็น ส่วน Actual state คือสถานะที่เกิดขึ้นจริง
- Declarative: ระบบสามารถถูกจัดการ desired state ด้วยการเขียนแบบ declarative (YAML, JSON)
- Version and Immutable: desired state ถูกทำให้ไม่เปลี่ยนแปลง ในแต่ละเวอร์ชัน (Git, GitHub, GitLab)
- Pull automatically: มีซอฟต์แวร์คอยดึง desired state ที่ถูก declare ไว้แบบอัตโนมัติ (ArgoCD, FluxCD)
- Continuous Reconciled: จับตาดู actual state เพื่อเตรียมที่จะ apply desired state
ประโชน์จากการใช้ GitOps คือ deploy ได้ไหลลื่น, ปลอดภัยมากขึ้น, Rollback ได้ง่าย, ตรวจสอบได้ง่ายและจบปัญหาเรื่อง Configuration drift
GitOps ไม่ได้ระบุว่าต้องใช้ tools อะไร แต่ Argo CD ดูจะเป็นตัวเลือกที่เหมาะ เพราะเป็น UI เข้าใจง่ายและใช้งานได้สะดวก support Role-based access control (RBAC) และ Single sign-on (SSO)
จากนั้นก็เป็นการสาธิต Practical Guide สำหรับการจัดการ Argo CD แบบ multi-tenancy โดยสรุปคือ
- Explore multi-tenancy needs
- Start with RBAC and AppProject
- Look for new solutions
- Iterate and improve
Software Licenses — The good, the bad & the ugly
A good license is your legal shield, a bad one can be a trap
คุณ Tobias Meixner เป็น Co-Founder ของ Hubql มาพูด Software license ส่วนตัวตั้งใจมาฟังหัวข้อนี้โดยเฉพาะ เพราะว่าช่วงที่ผ่านมีข่าวที่เครื่องมือต่างๆ ที่ใช้ในการ Dev เปลี่ยน license กลายเป็นว่ากระทบการทำงานต้องหาใช้ตัวที่เป็น Alternative จะเห็นว่าเรื่องพวกนี้ใกล้ตัวและสำคัญมาก
Software License หมายถึง:
- เราจะใช้ software อย่างไร
- ใครเป็นเจ้าของ (Owner)
- จะเกิดอะไรขึ้นถ้าเราใช้ผิดวิธี
จากนั้น Tobias ก็อธิบายแต่ละ License และถามคำถามกับผู้เข้าร่วมว่า Tools ตัวนี้ใช้ License แบบไหนอยู่นะ เราเข้าใจถูกหรือเปล่า ขอแปะตัวอย่างให้เห็นภาพ https://choosealicense.com/licenses/
จากนั้นก็สรุปแนวทางการใช้ License ไว้ดังนี้
สำหรับ Vendor
- เข้าใจ Business model
- ปรับแนวทางการใช้ License ให้เหมาะกับ Revenue goal
- พิจารณาตลาด (open-source vs proprietary, freemium model, etc)
สำหรับ User
- ต้องอ่าน License ที่ใช้ทั้งหมด อย่าข้าม
- ทำความเข้าใจการใช้งานและข้อกำหนดต่างๆ
- เช็คความเหมาะสมและเข้ากันได้กับโปรเจค
- พิจารณาในระยะยาว
- มีแผนจัดการความเสี่ยง (ตรวจสอบ license บ่อยๆ และทำ document)
Tools สำหรับตัวช่วยเรื่อง License
- GitHub’s License detection
- SPDX License List
- Black Duck Software Composition Analysis
- Mend.io
- Snyk
- Semgrep
Harnessing Open Source for Career Growth: Insights from FOSSASIA
It’s about using global knowledge to solve local problems
คุณ Hong Phuc Dang และ Mario Behing จาก FOSSASIA มาแชร์ในส่วนของการเติบโตในสายเทค โดย FOSS มีเป้าหมายหลักคือ
- Accelerates innovation
- Democratizes access to technology
- Fosters global collaboration
แนะนำสำหรับคนที่ชอบความท้าทาย CodeHeat เป็น Event สำหรับคนที่ต้องการ contribute Free and Open Source software (FOSS) และ open hardware มาเรียนรู้และปล่อยของกัน
นอกจากนี้ FOSSASIA ก็มีการสนับสนุน Event และ Workshop ต่างๆ และในปีหน้า จะมี FOSSASIA Summit 2025 มาจัดที่กรุงเทพฯ อีกด้วย
Closing Session
หลังจากจบทุกหัวข้อแล้วก็กลับมาที่รวมห้อง Auditorium เพื่อบันทึกภาพรวม สิ่งที่ประทับใจคงเป็นการที่ผู้เข้าร่วมงานได้แชร์ Feedback กันออกมามากมาย ถือว่าเป็นการให้ทั้งความรู้และจุดประกายให้นักพัฒนาทุกรุ่น ได้มีแรงบันดาลใจในการเขียนโค้ดต่อไป ขอบคุณผู้จัดและผู้สนับสนุนที่จัดงานที่ได้พบปะ Developer เก่งๆ ได้มาแชร์ความรู้กันครับ เตรียมรอปีหน้าได้เลย
