สร้างแพลตฟอร์มแฮกกาธอนด้วย Docker ทั้งที่ยังไม่รู้จัก
นักศึกษาปีแรกสร้างแฮกกาธอนแพลตฟอร์ม เดี่ยวเดี่ยวในชื่อ The Lone Wolf สำหรับ Dogfood 2026 โดยใช้ Docker Compose และ SQLite
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- นักศึกษาปีแรกสร้างแพลตฟอร์มแฮกกาธอนเดี่ยว The Lone Wolf
- สถาปัตยกรรมทำงานผ่าน Docker Compose และใช้ฐานข้อมูล SQLite
- ข้อมูลทดสอบประกอบด้วย 40 ทีม, 30 กรรมการ และ 41 โปรเจกต์
- ระบบบังคับใช้กฎความปลอดภัยและคะแนนผ่านหลังบ้านทั้งหมด
เมื่อเริ่มต้นศึกษาภาคการศึกษาแรกในสาขาวิชาวิศวกรรมคอมพิวเตอร์ (CSE) ผู้พัฒนาพบว่าตนเองยังไม่รู้จักเครื่องมืออย่าง Docker แต่กลับตัดสินใจสร้างแพลตฟอร์มแฮกกาธอนที่โฮสต์ได้ด้วยตนเองและรันผ่าน Docker โดยเป็นโครงงานเดี่ยวในชื่อ The Lone Wolf สำหรับการแข่งขัน Dogfood 2026
การตัดสินใจทางสถาปัตยกรรมที่สำคัญที่สุดคือการทำให้ระบบทั้งหมดทำงานแบบโลคัลและพึ่งพาตัวเองได้ แอปพลิเคชันทำงานผ่าน Docker Compose ใช้ SQLite สำหรับการจัดเก็บข้อมูล และสร้างข้อมูลจำลองขึ้นมาเอง โดยไม่มีการพึ่งพาฐานข้อมูลบนคลาวด์ API ภายนอก หรือระบบยืนยันตัวตนจากภายนอก ซึ่งในตอนแรกดูเหมือนข้อจำกัดตามโจทย์ แต่ภายหลังได้กลายเป็นรากฐานสำคัญของระบบที่ต้องจำลองการทำงานทั้งหมดจากจุดเริ่มต้นที่สะอาดได้
การที่นักศึกษาเลือกสร้างระบบโดยปราศจากบริการภายนอกมาช่วยรองรับความผิดพลาด ถือเป็นแนวทางปฏิบัติที่ดีเยี่ยมในการเรียนรู้การพัฒนาซอฟต์แวร์ เพราะบังคับให้ต้องทำความเข้าใจกลไกภายในของคอนเทนเนอร์และการจัดการฐานข้อมูลตั้งแต่ระดับล่างสุด แทนที่จะพึ่งพาบริการสำเร็จรูปบนคลาวด์
ความท้าทายประการต่อมาคือการบังคับใช้กฎเกณฑ์ของระบบ เช่น การจำกัดเวลาส่งผลงาน ซึ่งแทนที่จะซ่อนหรือปิดการใช้งานปุ่มส่งงานที่หน้าบ้าน (UI) ผู้พัฒนาได้เลือกให้ระบบหลังบ้านเป็นผู้ตรวจสอบและปฏิเสธคำขอโดยตรง เพื่อป้องกันการส่งข้อมูลผ่านการเรียก API โดยตรง หลักการนี้ถูกนำไปใช้กับการแบ่งแยกสิทธิ์การใช้งานระหว่างผู้เข้าร่วมแข่งขันและกรรมการด้วยเช่นกัน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในส่วนของข้อมูลทดสอบ (Fixture) ที่ระบบต้องรองรับถูกออกแบบมาให้มีความซับซ้อนสูง โดยมีรายละเอียดดังนี้:
- 40 ทีมผู้เข้าแข่งขัน
- 30 กรรมการตัดสิน
- 41 โปรเจกต์
- 8 แทรกการแข่งขัน
- 126 คะแนนการตัดสิน
ข้อมูลทดสอบยังมีกรณีที่ซับซ้อน เช่น ชุดการตรวจที่ยังไม่เสร็จสิ้น กรรมการที่ให้คะแนนเท่ากันทุกโปรเจกต์ และโปรเจกต์สองรายการชื่อ Dry Harbour ที่มาจากทีมเดียวกัน ซึ่งกรณีหลังนี้ช่วยให้ผู้พัฒนาเข้าใจว่าแบบจำลองข้อมูล (Data Model) อนุญาตให้หนึ่งทีมมีหลายโปรเจกต์ได้ ดังนั้นข้อมูลทั้งสองจึงต้องคงอยู่ตามกฎของระบบแทนที่จะถูกลบทิ้งแบบอัตโนมัติ
กระบวนการให้คะแนนและการคัดเลือกผลงานยังมีความซับซ้อนในเรื่องของการปรับเทียบมาตรฐานคะแนน (Score Normalization) เนื่องจากกรรมการแต่ละคนมีพฤติกรรมการให้คะแนนที่แตกต่างกัน เช่น บางคนใช้ช่วงคะแนนเกือบทั้งหมด ขณะที่บางคนให้คะแนนใกล้เคียงกันเกือบทุกโปรเจกต์ ทำให้ระบบต้องคำนึงถึงพฤติกรรมของข้อมูลจริง ไม่ใช่แค่การใส่สูตรทางคณิตศาสตร์ตายตัว
นอกจากนี้ ฟีเจอร์การลงคะแนนเสียงของชุมชน (Community Voting) ซึ่งในตอนแรกดูเหมือนจะเป็นเรื่องง่าย แต่ในทางปฏิบัติกลับมีความซับซ้อนสูงมาก เนื่องจากต้องรองรับการลงคะแนนที่จำกัดด้วยโทเค็น การสุ่มบัตรลงคะแนน การป้องกันการโหวตซ้ำ ระบบแสดงความคิดเห็น การจำกัดอัตราการเรียกใช้งาน (Rate Limiting) และการซ่อนผลคะแนนในขณะที่การโหวตยังดำเนินอยู่
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น