โปรเจ็กต์ที่โปรแกรมเมอร์ทุกคนควรลองทำ (2019)
(austinhenley.com)- ถ้าเลือกไซด์โปรเจ็กต์ยาก โปรเจ็กต์อย่าง โปรแกรมแก้ไขข้อความ, เกม 2D, คอมไพเลอร์, มินิระบบปฏิบัติการ เป็นจุดเริ่มต้นที่ดี เพราะยิ่งทำซ้ำก็ยิ่งได้เรียนรู้กว้างขึ้น
- โปรแกรมแก้ไขข้อความทำให้ได้ลงมือสร้างโครงสร้างการเก็บเอกสาร การทำงานของเคอร์เซอร์ การเลิกทำ/ทำซ้ำ และการตัดบรรทัดด้วยตัวเอง จึงได้ฝึก โครงสร้างข้อมูลและการนามธรรม
- แม้แต่เกม 2D ง่าย ๆ อย่าง Space Invaders ก็เผยให้เห็น โครงสร้างพื้นฐานของการเขียนโปรแกรมเกม ตั้งแต่การวาดหน้าจอ การจัดการอินพุต เกมลูป การจัดการสถานะของวัตถุ AI ของศัตรู เสียง เชดเดอร์ ไปจนถึงเครือข่าย
- คอมไพเลอร์ Tiny BASIC และมินิระบบปฏิบัติการจะพาให้ลงมือกับ แนวคิดระดับล่าง โดยตรง เช่น lexical analysis·parsing·semantic analysis·code generation รวมถึง cross compiling·bootloading·การจัดการหน่วยความจำ·การจัดตารางงาน
- สเปรดชีตและคอนโซลอีมูเลเตอร์จะผสานความยากของโปรเจ็กต์ก่อนหน้า และต่อยอดไปสู่การสร้าง เครื่องเสมือน ที่เลียนแบบการทำงานจริง
โปรเจ็กต์ที่ควรลองทำซ้ำ
- เมื่อคุณต้องการไซด์โปรเจ็กต์ หรืออยากเรียนรู้ภาษาโปรแกรม·เฟรมเวิร์กใหม่ การทำโปรเจ็กต์เดิมซ้ำหลายครั้งก็ยังทำให้ได้เรียนรู้อะไรใหม่ทุกครั้ง
- โปรเจ็กต์ที่แนะนำมีระดับความยากและขอบเขตการเรียนรู้ต่างกัน
- โปรแกรมแก้ไขข้อความ: โครงสร้างข้อมูล, การทำงานของเคอร์เซอร์, การเลิกทำ/ทำซ้ำ, การแสดงผลบนหน้าจอ
- เกม 2D: การวาดหน้าจอ, การจัดการอินพุต, เกมลูป, การจัดการวัตถุและสถานะ
- คอมไพเลอร์: lexical analysis, parsing, semantic analysis, code generation
- มินิระบบปฏิบัติการ: การบูต, การจัดการหน่วยความจำ, การจัดตารางงาน, ระบบไฟล์
- สเปรดชีตและคอนโซลอีมูเลเตอร์: รวมแนวคิดจากโปรเจ็กต์ก่อนหน้าเข้าด้วยกันในโครงสร้างที่ใหญ่ขึ้น
โปรแกรมแก้ไขข้อความ
- โปรแกรมแก้ไขข้อความเป็นเครื่องมือที่เราใช้ทุกวัน แต่ถ้าลองสร้างเองโดยไม่ใช้คอมโพเนนต์กล่องข้อความพื้นฐาน คุณจะต้องจัดการรายละเอียดของ การย้ายเคอร์เซอร์, การเลือก, การแทรก, และการลบ
- โจทย์ใหญ่ที่สุดคือวิธีเก็บเอกสารข้อความไว้ในหน่วยความจำ
- อาร์เรย์แบบง่ายมีประสิทธิภาพไม่ดีเมื่อแทรกข้อความในตำแหน่งที่ไม่ใช่ท้ายเอกสาร
- โครงสร้างที่ควรลองเปรียบเทียบมีทั้งอาร์เรย์, rope, gap buffer, piece table
- เคอร์เซอร์ไม่ได้เคลื่อนแค่ขึ้นลงแบบตรง ๆ
- เมื่อย้ายไปยังบรรทัดที่สั้นกว่า จะไปยังตำแหน่งที่เป็นไปได้ก่อน แล้วถ้าภายหลังเจอบรรทัดที่ยาวพอ ก็จะพยายามกลับไปยังคอลัมน์เดิม ซึ่งเป็นพฤติกรรม การจำคอลัมน์
- หลังทำเอดิเตอร์พื้นฐานแล้ว คุณสามารถเพิ่มการเลิกทำ/ทำซ้ำและการตัดบรรทัดได้
- แหล่งอ้างอิง
เกม 2D - Space Invaders
- แม้เกมจะเรียบง่าย ก็ยังต้องการโครงสร้างข้อมูลและดีไซน์แพตเทิร์นเฉพาะตัว
- ถ้าใช้ ไลบรารีกราฟิก 2D ขั้นพื้นฐาน อย่าง SDL, SFML, PyGame แทนเอนจินเกมขนาดใหญ่ ส่วนที่น่าสนใจก็จะไม่ถูกซ่อนไว้
- เกมสร้างภาพว่าวัตถุกำลังเคลื่อนที่ด้วยการลบหน้าจอแล้ววาดองค์ประกอบแต่ละอย่างใหม่อย่างรวดเร็ว
- ลำดับการทำงานจริงคือการวนซ้ำภายใน เกมลูป โดยทำการวาด รับอินพุตจากผู้ใช้ และประมวลผลตรรกะของเกมซ้ำไปเรื่อย ๆ
- การจัดการอินพุตต้องคำนึงถึงรายละเอียดอย่างการกดปุ่มหรือปุ่มเมาส์ครั้งแรก การกดค้าง การปล่อย และการดับเบิลคลิก
- ถ้าเอาแต่ตรวจสอบอินพุตอย่างเดียว ส่วนที่เหลือของเกมก็จะหยุดนิ่ง
- การจัดการวัตถุและสถานะของเกมก็ต้องลงมือทำเองเช่นกัน
- factory pattern ช่วยได้ในการสร้างศัตรูที่เพิ่มจำนวนแบบไดนามิก
- สามารถใช้ state machine กับ AI ของศัตรูได้
- หลังจากทำเกมพื้นฐานแล้ว คุณสามารถเพิ่มเมนูไตเติล หน้าจอเกมโอเวอร์ การทำให้รันด้วยความเร็วเท่ากันแม้เครื่องต่างกัน และ AI ศัตรูที่น่าสนใจขึ้นได้
- ถ้าขยายต่อไปอีก ก็สามารถลองทำเอฟเฟกต์เชดเดอร์ เสียง และออนไลน์มัลติเพลเยอร์ได้
- แหล่งอ้างอิง
คอมไพเลอร์ - Tiny BASIC
- คอมไพเลอร์เป็นโปรเจ็กต์สร้างเครื่องมือที่ช่วยให้คนอื่นสร้างสิ่งต่าง ๆ ได้มากขึ้น
- คุณสามารถเขียนคอมไพเลอร์สำหรับ Tiny BASIC ซึ่งเป็นภาษาตระกูล BASIC ขนาดเล็ก ตั้งแต่ต้นจนจบ โดยให้มันแปลงออกเป็นภาษาอื่นที่คุณคุ้นเคย
- ตัวอย่างเช่น สร้างคอมไพเลอร์ Tiny BASIC ด้วย Python แล้วให้ส่งออกโค้ด C#
- ถ้าไม่ส่งออกเป็นแอสเซมบลีหรือ C ก็จะโฟกัสกับตัวคอมไพเลอร์ได้มากกว่า
- ขั้นตอนการพัฒนาจะไล่ไปตามกระบวนการประมวลผลภาษาเป็นลำดับ
- lexical analysis สำหรับแยกโค้ดอินพุตออกเป็นโทเค็น
- syntactic analysis สำหรับตรวจสอบโครงสร้างอินพุตและสร้างการแทนแบบต้นไม้
- recursive descent parsing
- abstract syntax tree
- semantic analysis สำหรับตรวจว่าความหมายของโค้ดถูกต้องและเป็นไปตามกฎของชนิดข้อมูล
- optimization passes
- code generation
- คอมไพเลอร์แบบง่ายสามารถทำเสร็จได้ภายในไม่กี่วัน และหลังจากนั้นยังเพิ่มมาตรฐานไลบรารี, optimization passes, และการปรับปรุงข้อความแสดงข้อผิดพลาดได้อีก
- ใน PeayBASIC มีการเพิ่ม ความสามารถกราฟิก 2D แบบง่ายเข้าไปในมาตรฐานไลบรารี
- แหล่งอ้างอิง
มินิระบบปฏิบัติการ
- อัลกอริทึมและโครงสร้างข้อมูลของระบบปฏิบัติการอาจดูเป็นนามธรรมหรือไม่มีประโยชน์ในห้องเรียน แต่จริง ๆ แล้วสามารถนำไปใช้กับหลายด้าน เช่น เกม หรือโมเดลทำนายพฤติกรรมมนุษย์
- การลงมือทำเองจะช่วยให้เข้าใจลึกขึ้นว่าเกิดอะไรขึ้นภายในระบบปฏิบัติการ
- แม้จะมีอุปสรรคในการเริ่มต้นและเส้นโค้งการเรียนรู้เพราะต้องพึ่งพาฮาร์ดแวร์ แต่ถ้าทำตามหนังสือหรือบทสอน คุณก็สามารถสร้าง OS ที่บูตได้ และรันโปรแกรมที่เขียนเองได้
- หัวข้อที่ได้เรียนรู้มีดังนี้
- Cross compiling
- Bootloading
- BIOS interrupts
- x86 modes
- การจัดการหน่วยความจำและ paging
- Scheduling: เช่น round robin
- File systems: เช่น FAT
- แหล่งอ้างอิง
โปรเจ็กต์ที่ยากขึ้น: สเปรดชีตและคอนโซลอีมูเลเตอร์
- แอปพลิเคชันสเปรดชีตอย่าง Excel เป็นการรวมโจทย์ของโปรแกรมแก้ไขข้อความกับโจทย์ของคอมไพเลอร์เข้าด้วยกัน
- ต้องแทนข้อมูลเนื้อหาในเซลล์ไว้ในหน่วยความจำ
- ต้องสร้าง อินเทอร์พรีเตอร์ สำหรับภาษาโปรแกรมที่ใช้ในสูตร
- แหล่งอ้างอิงสำหรับสเปรดชีต
- คอนโซลอีมูเลเตอร์สำหรับวิดีโอเกมคือโปรเจ็กต์ที่รวมความยากของการสร้างคอมไพเลอร์ ระบบปฏิบัติการ และเอนจินเกมไว้ด้วยกัน
- หากต้องการจำลองคอนโซลจริง คุณต้องเขียน เครื่องเสมือน ที่ทำงานเหมือน CPU และองค์ประกอบฮาร์ดแวร์อื่น ๆ
- และสามารถรันเกมของคอนโซลนั้นบนเครื่องเสมือนนี้ได้
- จุดเริ่มต้นที่แนะนำคือการจำลอง CHIP-8 ซึ่งเป็นคอนโซลเสมือนที่ง่ายกว่าคอนโซลจริง
- สามารถจำลอง NES, SNES, Gameboy, Gameboy Advance ได้เช่นกัน และแม้จะมีเอกสารกับอีมูเลเตอร์โอเพนซอร์สอยู่พอสมควร แต่คอนโซลแต่ละตัวก็มีจุดเฉพาะที่น่าสนใจ
- เกมบางเกมอาจพึ่งพาบั๊กหรือความสามารถที่ไม่ได้ถูกบันทึกไว้ของฮาร์ดแวร์บางชนิด
- PICO-8 ได้กลายเป็นคอนโซล “fantasy” ที่ทำรายได้จริง
- แหล่งอ้างอิงสำหรับอีมูเลเตอร์
โปรเจ็กต์เพิ่มเติมที่มีผู้แนะนำ
- มีการรวบรวมไอเดียโปรเจ็กต์เพิ่มเติมจาก Hacker News, Reddit, Twitter, และอีเมล
- ฐานข้อมูลที่สร้างตั้งแต่ต้น
- เรย์เทรเซอร์
- โคลน MS Paint
- โปรแกรมแก้ไขเวกเตอร์กราฟิก
- ตัวถอดรหัสภาพ
- เว็บแอปห้องแชต
- โปรแกรมคำนวณเลขหลักของ pi
- ยูทิลิตีเทอร์มินัลทั่วไปอย่าง grep
- ไคลเอนต์และเซิร์ฟเวอร์ FTP
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
การสร้างโปรแกรมแก้ไขข้อความ คอมไพเลอร์ ระบบปฏิบัติการ หรือเรย์เทรเซอร์ อาจทำให้คุณเป็นโปรแกรมเมอร์ที่ดีขึ้นได้ แต่ไม่ได้ทำให้เป็นวิศวกรซอฟต์แวร์ที่ดีขึ้นเสมอไป
ตรงกันข้าม มันอาจทำให้ซึมซับแนวคิด “Not Invented Here” แบบหายนะเข้าไป จนแย่ลงสำหรับงานวิศวกรรมซอฟต์แวร์ด้วยซ้ำ
พวกแฮ็กเกอร์มักหมกมุ่นกับทฤษฎีระดับสูงอย่าง Big-O, โครงสร้างข้อมูล, HoTT แต่แทบไม่ค่อยพูดถึงหรือฝึกสิ่งที่จำเป็นต่อวิศวกรรมจริง เช่น “การตัดสินใจว่าจะทำเองหรือใช้ไลบรารี”, “การแยกแยะไลบรารีและเฟรมเวิร์กที่ดี”, “การตัดสินว่าจุดไหนคุ้มจะปรับแต่งประสิทธิภาพ”, “การเขียนโค้ดที่อีกหลายปีก็ยังอ่านได้”, “การมองโปรเจ็กต์เป็นระบบซับซ้อนขนาดใหญ่ที่รวมทั้งการพึ่งพาซอฟต์แวร์และสิ่งที่ไม่ใช่ซอฟต์แวร์”
เพราะอย่างนั้นจึงเสนอเว็บเสิร์ชเอนจินเป็นโจทย์ทางเลือก ไม่ต้องกังวลเรื่องอย่างอัลกอริทึมจับคู่สตริงเพราะคนอื่นทำไว้แล้ว แค่ลอง “สร้าง” เสิร์ชเอนจินและครอว์เลอร์ที่ใช้งานได้จริงขึ้นมาสักตัว แม้ช่วงแรกจะรองรับได้เพียงบางส่วนของเว็บและผู้ใช้พร้อมกัน 1 คนก็ตาม
โปรแกรมแก้ไขข้อความ คอมไพเลอร์ ระบบปฏิบัติการ และเรย์เทรเซอร์ ก็ฝึกกิจกรรมทั้งหมดแบบเดียวกันได้เหมือนกัน
ในฐานะคนที่เคยทำงานกับเรย์เทรเซอร์ที่ใช้ในภาพยนตร์ฟอร์มยาวหลายเรื่อง รายการที่ยกมาข้างบนใช้ได้กับโปรเจ็กต์นั้นทั้งหมด
สุดท้ายแล้วมันใกล้เคียงกับความต่างระหว่างการทำของเล็ก ๆ ที่สนุก กับการเอาข้อจำกัดบั่นทอนจิตวิญญาณแบบที่ทำในบริษัทเพื่อเงินมาใส่จนหมดความสนุกมากกว่า
อย่างแรก บล็อกที่เตรียมไว้ส่วนใหญ่มักแย่มากกว่าดี และผลลัพธ์คือซอฟต์แวร์ก็สะท้อนความแย่นั้นไปด้วย ชีวิตเลยไม่ใช่การใช้ซอฟต์แวร์ แต่เป็นการคอยบำรุงรักษาและประคับประคองของแย่ ๆ เหล่านั้น
อย่างที่สอง ต่อให้คุณภาพของบล็อกดี ก็ยังจำกัดชนิดของซอฟต์แวร์ที่คุณสร้างได้ ตามอุดมคติแล้วเราควรจินตนาการพฤติกรรมที่ต้องการ จากนั้นเขียนซอฟต์แวร์ให้ทำสิ่งนั้น และสร้างบล็อกขึ้นมาระหว่างทาง
ถ้าใช้แต่บล็อกสำเร็จรูป ซอฟต์แวร์ชั้นเยี่ยมจำนวนมากจะไม่มีทางถูกสร้างขึ้นมาเลย และคิดว่านั่นก็เป็นเหตุผลว่าทำไมรอบตัวเราจึงมีซอฟต์แวร์ชั้นเยี่ยมไม่มากนัก
ถ้าคุณกำลังสร้าง “ซอฟต์แวร์ที่แทบไม่ต่างจากของที่เห็นกันอยู่แล้ว” ปัญหาข้อสองก็อาจกระทบน้อยลง และข้อแรกก็อาจพอรับมือได้เพราะใช้งานแค่เส้นทางสุขสันต์เป็นหลัก แต่ซอฟต์แวร์แบบนั้นอีกไม่นานก็จะถูกเขียนโดยAIแทนมนุษย์
ทักษะเหล่านั้นก็สำคัญ แต่เมื่อถึงจุดหนึ่ง คุณต้องพัฒนาพื้นฐาน และการเป็นโปรแกรมเมอร์ที่ดีขึ้นย่อมช่วยทักษะทั้งหมดที่ลิสต์ไว้ข้างบนอย่างชัดเจน
สำหรับผม วิศวกรรมซอฟต์แวร์คือสิ่งที่ทำเพื่อจ่ายบิล ส่วนการเขียนโปรแกรมคือสิ่งที่เริ่มทำเพราะมันสนุก
โปรเจ็กต์ในบทความนี้เป็นประเภทที่ถ้ามีเวลาก็อยากลองทำเล่นเพื่อความสนุก
ถ้ามองจากฝั่ง UI/Web นอกจากสเปรดชีตที่มีประโยชน์มากต่อการเข้าใจระบบการไหลของข้อมูลแล้ว ยังอยากแนะนำสิ่งเหล่านี้
ลองสร้างวิดีโอเกมง่าย ๆ ด้วย Unity หรือ Unreal แล้วคุณจะเข้าใจข้อจำกัดด้านประสิทธิภาพในเกมที่ 30~60fps สำคัญมาก ซึ่งช่วยให้ทำอินเทอร์เฟซที่เร็วในที่อื่นรวมถึงบนเว็บได้ดีขึ้น
การสร้างเฟรมเวิร์ก JavaScriptง่าย ๆ ที่คล้าย React จะช่วยให้เข้าใจการไหลของข้อมูลและการจัดการอีเวนต์
ถ้าลองเขียนไลบรารี HTTP ที่ห่อ XMLHTTPRequest ด้วยตัวเอง แม้ตอนนี้จะมี fetch แล้ว คุณก็จะเข้าใจตั้งแต่พื้นฐานว่าการส่งและอ่านคำขอ HTTP ทำงานอย่างไร ซึ่งจะช่วยตอนดีบักปัญหาอย่าง CORS หรือคำขอ OPTIONS ในภายหลัง
เรื่องนี้มีการคุยกันตั้งแต่ตอนนั้นแล้ว
Challenging projects every programmer should try - https://news.ycombinator.com/item?id=21790779 - Dec 2019 (297 comments)
และยังมีบทความที่เกี่ยวข้องด้วย
More challenging projects every programmer should try - https://news.ycombinator.com/item?id=25489879 - Dec 2020 (223 comments)
ขอสนับสนุนมินิระบบปฏิบัติการอีกเสียง
นักพัฒนาแอปพลิเคชันพึ่งพาความสามารถของระบบปฏิบัติการหลายอย่าง เช่น การจัดการหน่วยความจำและระบบไฟล์ และสุดท้ายก็จะถามว่า “เบื้องหลังสิ่งพวกนี้ทำงานอย่างไร?”
เพราะแบบนั้นผมเลยลองเล่น xv6(https://github.com/mit-pdos/xv6-public) ในเวลาว่าง
การเรียนอัลกอริทึมจัดตารางโปรเซสหลายแบบจากตำรากับการลงมือทำเองนั้นต่างกันโดยสิ้นเชิง และได้เรียนรู้อะไรเยอะมาก
ในฐานะนักพัฒนาแอปมือถือ ความรู้พวกนี้แทบไม่มีโอกาสเกี่ยวข้องกับงานเลย แต่ยืนยันได้เลยว่ามันสนุกมาก
การลองทำ พัฒนาเกม 2D โดยไม่ใช้เอนจินเป็นประสบการณ์ที่ทำให้ถ่อมตัวที่สุด และทำให้ตระหนักว่าคอมพิวเตอร์เร็วขึ้นอย่างเหลือเชื่อแค่ไหน
ต่อให้ทำสิ่งที่มั่นใจว่าน่าจะช้ามาก มันก็ยังรันได้ เพราะแม้แต่ Game Boy ก็ยังคำนวณได้เป็นล้านครั้งต่อวินาที เลขหนึ่งล้านนั้นใหญ่กว่าที่คิดมาก
แบบว่า “เดี๋ยวนะ วาดโดยไล่หาสไปรต์ทั้งหมดทุกครั้งเลยเหรอ? ไม่มีการคำนวณ diff แบบฉลาด ๆ ที่รู้ว่าต้องเปลี่ยนอะไรบ้าง และไม่มีบัฟเฟอร์ตัวที่สองที่อ้างอิงเฟรมก่อนหน้าเพื่อลดงานเลยเหรอ?” แล้วพอไปเห็นเกมที่ซับซ้อนกว่านี้มากซึ่งเริ่มใช้เทคนิคพวกนี้จริง ๆ ก็ยิ่งน่าทึ่งขึ้นไปอีก
ตัวอย่างเช่น sprite atlas เป็นวิธีใช้งานโครงสร้างข้อมูลแบบนี้ที่พบได้บ่อย เพราะไม่มีเหตุผลจะต้องอัปโหลดสไปรต์หลายภาพที่มักถูกเรนเดอร์ในรูปแบบคาดเดาได้ซ้ำ ๆ ทุกครั้ง แค่อัปโหลดภาพใหญ่ภาพเดียวแล้ว sample เอาบางส่วนก็พอ
ถ้ามองด้วยมาตรฐานปัจจุบันก็จริง ฮาร์ดแวร์เชิงพาณิชย์ระดับทั่วไป แม้จะไม่ใช่เกมมิงพีซี ก็ยังจัดการสิ่งเกือบทั้งหมดเมื่อราว 15 ปีก่อนได้ด้วยการเรนเดอร์แบบทื่อ ๆ วาดฉากแล้ววาดใหม่อีกครั้ง
มีแค่ฮาร์ดแวร์ล้วน ๆ กับแอสเซมบลี จึงต้องจัดการกราฟิก เสียง อินพุต การจัดการหน่วยความจำ และอย่างอื่นทั้งหมดด้วยมือ
ถ้ามีสภาพแวดล้อมแบบย่อส่วนที่ทำให้โปรแกรมเมอร์มือใหม่จัดการสิ่งเหล่านี้ทั้งหมดเพื่อสร้าง เกม 2D ได้ แต่ลดภาระส่วนเกินที่ต้องแบกเพื่อให้มันทำงานได้ ก็น่าจะเป็นจุดเริ่มต้นที่เหมาะมาก
ถ้าคุณคิดว่าต้องใช้ factory pattern เพื่อสร้าง Space Invaders แปลว่ามีอะไรผิดไปแล้ว
แทบเป็นไปไม่ได้เลยที่ต้นฉบับจะมีแนวคิดด้านการออกแบบแบบนั้นอยู่
พอสมองติดเชื้อสิ่งนั้นแล้ว ก็จะเริ่มมองหาวิธีแพร่เชื้อต่อ
เราอ่านคนละบทความกันหรือเปล่า?
อยากลองทำอะไรที่เป็นกายภาพมากกว่านี้มาก เช่น หุ่นยนต์ โดรนอัตโนมัติ หรือการจำลองความแม่นยำสูงของพลวัตการบินสำหรับยานอวกาศที่มีพารามิเตอร์ GNC ที่ตั้งโปรแกรมได้
มี “Fundamentals of Astrodynamics” ของ Bate, Mueller และคนอื่น ๆ อยู่ และอยากลองทำอะไรสักอย่างในช่วงวันหยุดนี้
ที่พูดถึงการจำลองก็เพราะอย่างอื่นน่าจะแพงมาก สนใจด้าน GNC ของหุ่นยนต์มากจริง ๆ ถ้ามีคำแนะนำเรื่องแหล่งข้อมูลดี ๆ ก็คงดี
หมายถึงอะไรแบบ Segway ที่สามารถยืนทรงตัวอยู่กับที่ได้โดยไม่ล้มหรือพุ่งตกจากโต๊ะ
น่าจะต้องใช้ไมโครคอนโทรลเลอร์, IMU, ตัวควบคุมสเต็ปเปอร์มอเตอร์, มอเตอร์, ล้อ LEGO และอาจจะมีไม้สักชิ้น
ยังไม่เคยทำเอง เลยอาจเดาผิดไปมากก็ได้
อยากฟังเพิ่มเติมว่าหนังสือเล่มนี้มีเนื้อหาอะไร และมีโปรเจกต์แบบไหนที่พอจะลองทำได้บ้าง
หลังจากทำงานกับซอฟต์แวร์มาทั้งวัน การได้ลงมือกับวัตถุจริง ๆ มันดีมาก
คิดว่า ray tracer ขนาดเล็กแบบของเล่นก็เป็นโจทย์ที่ยอดเยี่ยมและน่าลอง
แค่มีทรงกลม แหล่งกำเนิดแสงไม่กี่จุด รองรับการสะท้อนแบบ diffuse และ specular แล้วส่งออกเป็นกราฟิกบิตแมปก็พอ
ถ้าไม่ขยายให้ใหญ่เกินไป ก็เป็นโปรเจกต์ที่กำหนดขอบเขตได้ค่อนข้างดี
พอพยายามเรนเดอร์กราฟิก คุณจะได้เรียนรู้เยอะมากว่าคุณสามารถรีดเค้น เรขาคณิตและโครงสร้างข้อมูล ได้หนักแค่ไหน
https://austinhenley.com/blog/morechallengingprojects.html
https://raytracing.github.io/
https://raytracing-iow.shuttleapp.rs
เป็นรายการที่น่าสนใจ และแม้จะขึ้นอยู่กับนิสัยส่วนตัวและสถานการณ์ของแต่ละคน แต่มันก็เป็นจุดเริ่มต้นที่ดีถ้ากำลังหาไอเดีย
ผมคงไม่ถึงขั้นบอกว่าโปรแกรมเมอร์ทุกคนควรต้องลองทำอะไรบ้าง และขอเขียนแค่สิ่งที่ตัวเองเคยเลือกทำเป็นการส่วนตัว
บน Sinclair ZX Spectrum ผมเคยทำตัวแก้ไขโน้ตเพลงบนบรรทัดห้าเส้นกับ tracker แบบหยาบมาก ๆ และทำ Space Invaders แบบ 2D ที่มีผู้บุกรุกแค่ตัวเดียว
คอมพิวเตอร์เครื่องนั้นไม่ใช่ของผมเองด้วยซ้ำ ส่วนบน 386 ซึ่งเป็นคอมพิวเตอร์เครื่องแรกของผม ผมทำ ตัวบีบอัด Huffman, ดัชนี B-Tree ที่เร็วกว่า DBase/Clipper, ตัวสร้างฟอร์มเชิงวัตถุ และโปรแกรมเบื้องหลังบน DOS หลายตัว ซึ่งหนึ่งในนั้นภายหลังถูกใช้ในกระบวนการติดตั้งของบริษัทใหญ่แห่งหนึ่ง
ไม่กี่ปีต่อมา ผมก็ทำตัวตรวจอีเมลสำหรับ dial-up, พาร์เซอร์เขียนมือสำหรับ syntax highlighting, และสิ่งที่คล้ายสเปรดชีต ซึ่งทุกวันนี้ก็ยังทำอยู่ น่าจะยังมีอะไรที่ผมตกหล่นไปอีกแน่ ๆ
เป็นรายการที่ดี ถ้ารักษาไว้ให้เป็น รายการที่มีชีวิต เพื่อให้พัฒนาต่อร่วมกันได้ตามกาลเวลาก็น่าจะดี
อยากเพิ่มอีกสองอย่าง
ถ้าลองสร้าง memcached แบบเบา ๆ จะต้องใช้ทั้งอัลกอริทึมพื้นฐานและแนวปฏิบัติด้านการออกแบบระบบที่ดีผสมกัน เป็นปัญหาที่ “เรียบง่าย” แต่ต้องคิดให้รอบด้านทั้งเรื่อง invalidation, concurrency, memory management และประเด็นอื่น ๆ
การลองสร้าง Docker ของตัวเองก็ดีเช่นกัน มันไม่ได้ซับซ้อนอย่างที่ฟังดู และเปิดโอกาสให้เข้าใจพื้นฐานของ การเขียนโปรแกรมระบบปฏิบัติการ ซึ่งทุกวันนี้วิศวกรมักไม่ได้ใช้กันมากนักในงานประจำวัน