1 คะแนน โดย GN⁺ 2024-12-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Advent of Code อีเวนต์ปริศนาโปรแกรมมิงประจำเดือนธันวาคม ถูกออกแบบมาเพื่อลดกำแพงด้านทักษะและการเลือกภาษา ทำให้เข้าร่วมได้เพื่อวัตถุประสงค์หลากหลาย เช่น การฝึกฝน การศึกษา และการแข่งขัน
  • ไม่จำเป็นต้องมีพื้นฐานวิทยาการคอมพิวเตอร์หรืออุปกรณ์ประสิทธิภาพสูง และทุกโจทย์มีวิธีแก้ที่ทำงานเสร็จภายในไม่เกิน 15 วินาทีบน ฮาร์ดแวร์อายุ 10 ปี
  • หากแก้ไม่ออก ควรไล่จำกัดขอบเขตปัญหาตามลำดับ: ตรวจตัวอย่าง สร้าง test case เอง ตรวจสอบอินพุต ขอคำใบ้จากเพื่อนหรือ subreddit
  • FAQ ปี 2024 สรุปนโยบายการดำเนินงาน เช่น การเปลี่ยนความยาวอีเวนต์, การยกเลิก global leaderboard, กฎของ private leaderboard, การใช้ AI และข้อจำกัดด้านการคัดลอก·เผยแพร่ซ้ำ
  • การแข่งขันด้านความเร็วเป็นทางเลือก ผู้เข้าร่วมสามารถโฟกัสกับการแก้ปริศนาและการเรียนรู้ในแบบที่เป็นประโยชน์กับตนเองได้

ลักษณะของ Advent of Code และเงื่อนไขการเข้าร่วม

  • Advent of Code เป็นอีเวนต์รูปแบบ Advent calendar ที่ประกอบด้วยปริศนาโปรแกรมมิงขนาดเล็ก
  • ปริศนาถูกออกแบบสำหรับระดับทักษะที่หลากหลาย และสามารถแก้ด้วย ภาษาโปรแกรมมิง ที่ต้องการได้
  • ถูกนำไปใช้ได้หลายแบบ เช่น เตรียมสัมภาษณ์ ฝึกอบรมในบริษัท งานมหาวิทยาลัย แบบฝึกหัด การแข่งขันความเร็ว และการท้าทายกันระหว่างผู้เข้าร่วม
  • ไม่จำเป็นต้องมีพื้นฐานวิทยาการคอมพิวเตอร์ เพียงมีความรู้โปรแกรมมิงเล็กน้อยและทักษะแก้ปัญหาก็เข้าร่วมได้
  • ไม่ต้องใช้คอมพิวเตอร์ประสิทธิภาพสูง และทุกโจทย์มีวิธีแก้ที่ทำงานเสร็จภายในไม่เกิน 15 วินาทีบน ฮาร์ดแวร์อายุ 10 ปี

ขั้นตอนการแก้เมื่อไปต่อไม่ได้

  • หากแก้ไม่ออก ก่อนอื่นควรตรวจสอบโปรแกรมด้วย ตัวอย่าง ที่รวมอยู่ในปริศนา
  • หากผลลัพธ์ของตัวอย่างไม่ถูกต้อง ให้กลับไปอ่านคำอธิบายโจทย์ใหม่ แล้วตรวจดูส่วนที่เข้าใจผิดหรือพฤติกรรมของโปรแกรมที่ต่างจากที่คาดไว้
  • หากตัวอย่างถูกต้องแต่คำตอบยังผิด ให้สร้าง test case ที่สามารถตรวจคำตอบด้วยมือได้เอง แล้วนำไปทดสอบกับโปรแกรม
  • ควรตรวจสอบด้วยว่าได้ใช้อินพุตของปริศนาทั้งหมดครบถ้วนแล้วหรือไม่
  • หากยังติดอยู่ สามารถขอความช่วยเหลือจากเพื่อน หรือกลับมาแก้ใหม่ภายหลังได้ และอาจขอคำใบ้ได้จาก subreddit

การใช้งานเว็บไซต์และการยืนยันตัวตน

  • หากเปิดใช้งาน JavaScript อยู่ สามารถเลือก code block ทั้งหมดได้ด้วยการ คลิกสามครั้ง
  • การยืนยันตัวตนใช้ OAuth เพื่อตรวจสอบตัวตนผ่านบริการภายนอก
    • ตอนล็อกอิน ข้อมูลประจำตัวจะถูกส่งให้เฉพาะบริการภายนอกนั้น ไม่ใช่ Advent of Code
    • บริการภายนอกจะแจ้งเซิร์ฟเวอร์ Advent of Code ว่าผู้ใช้คือตัวจริง
    • โดยทั่วไปจะไม่มีข้อมูลเพิ่มเติมถูกเปิดเผย นอกเหนือจากข้อมูลที่มักเผยแพร่สาธารณะอยู่แล้ว
    • Advent of Code จะจดจำ ID เฉพาะ ชื่อ URL และรูปภาพจากบริการยืนยันตัวตน
  • หากตัวอักษรบนเว็บไซต์อ่านยาก สามารถใช้สไตล์ชีตทางเลือกแบบคอนทราสต์สูงได้
    • Firefox รองรับ View → Page Style → High Contrast เป็นค่าเริ่มต้น

ความยาก เวลาเผยแพร่ และความยาวของอีเวนต์

  • ความยากและหัวข้อของปริศนาจะแตกต่างกันไปในแต่ละอีเวนต์
  • โดยทั่วไปปริศนาจะยากขึ้นเมื่อเวลาผ่านไป แต่ความยากที่รู้สึกได้อาจแตกต่างกันมากตามชุดทักษะของแต่ละคน
  • ปริศนาจะเผยแพร่เวลา เที่ยงคืน EST/UTC-5
    • เพราะเป็นเวลาที่ผู้ดูแลสามารถตรวจสอบได้อย่างมั่นคงว่าโจทย์ทำงานได้โดยไม่มีปัญหา
    • ไม่จำเป็นต้องเข้าร่วมตอนเที่ยงคืนก็ได้ และการแข่งขันภายในกลุ่มหรือพื้นที่สามารถใช้ private leaderboards ได้
  • จำนวนวันของอีเวนต์มีการเปลี่ยนแปลง
    • การดำเนินงาน Advent of Code ต้องใช้เวลาว่างจำนวนมากทุกปี และการทำปริศนากินเวลาส่วนใหญ่ในนั้น
    • หลังจากรักษาตารางเดิมมา 10 ปี จึงจำเป็นต้องมีการเปลี่ยนแปลง
    • ปริศนาจะเริ่มวันที่ 1 ธันวาคมเพื่อให้หมายเลขวันที่ตรงกัน เผยแพร่ทุกวัน และสิ้นสุดใน ช่วงกลางเดือนธันวาคม

Leaderboard และการแข่งขันความเร็ว

  • global leaderboard ถูกยกเลิกแล้ว
    • เป็นหนึ่งในปัจจัยสร้างความเครียดมากที่สุดต่อผู้ดูแล โครงสร้างพื้นฐาน และผู้ใช้จำนวนมาก
    • ผู้เข้าร่วมบางส่วนจริงจังกับการแข่งขันมากเกินไป และถึงขั้นมีพฤติกรรมอย่างการโจมตี DDoS
    • ผู้ใช้จำนวนมากสรุปผิดว่าตนเองเป็นโปรแกรมเมอร์ที่แย่กว่า เพียงเพราะเวลาของตนช้ากว่าคนที่ถูกนำไปเปรียบเทียบ
    • เริ่มต้นในปี 2015 ในฐานะฟีเจอร์สนุก ๆ แต่ตลอด 10 ปี กลายเป็นปัญหาที่ใหญ่ขึ้นเรื่อย ๆ
  • มุมมองแบบอ่านอย่างเดียวของ private leaderboard สามารถแชร์ได้
    • ห้ามใช้ฟีเจอร์หรือข้อมูลนี้เพื่อสร้าง global leaderboard ใหม่
  • เวลาแก้โจทย์ที่รวดเร็วเป็นเรื่องทางเลือก
    • หากต้องการแก้ให้เร็ว ต้องใช้ทักษะเพิ่มเติมหลายอย่างและการฝึกฝนจำนวนมาก นอกเหนือจากการแก้ปริศนาเอง
    • โค้ดสำหรับ speed-solve มักดูแตกต่างอย่างสิ้นเชิงจากโค้ดที่จะผ่าน code review
    • สามารถเลือกแนวทางตามเป้าหมายที่เป็นประโยชน์กับตนเอง และจะเพิกเฉยต่อการแข่งขันความเร็วทั้งหมดก็ได้

การใช้ AI และกฎของ private leaderboard

  • หากอยู่ใน private leaderboard ควรตรวจสอบ กฎที่คาดหวัง กับผู้ดูแล
  • หากกฎไม่ตรงกัน สามารถหา private leaderboard อื่นหรือสร้างเองได้
  • กฎของ private leaderboard อาจรวมถึงเวลารันสูงสุด ภาษาที่อนุญาต เวลาแรกที่เปิดปริศนาได้ เครื่องมือที่ใช้ได้ และแม้กระทั่งต้องสวมหมวกตลกระหว่างทำหรือไม่
  • ไม่แนะนำให้ใช้ AI ในการแก้ปริศนา Advent of Code
    • มีการเปรียบเทียบว่า การส่งเพื่อนไปยิมจะทำให้ตัวเองแข็งแรงขึ้นได้หรือไม่
    • ปริศนาถูกออกแบบให้น่าสนใจเมื่อมนุษย์เป็นผู้แก้ และไม่ได้คำนึงว่า AI จะแก้ได้หรือไม่
    • หากเป้าหมายคือฝึกเขียนพรอมป์ต์ให้ AI แบบฝึกหัดอื่นที่ออกแบบมาเพื่อเป้าหมายนั้นอาจเหมาะสมกว่า

ไอเดียปริศนา บั๊ก และนโยบายการคัดลอก

  • ไม่ควรส่งไอเดียปริศนา
    • ไม่รับไอเดียเนื่องจากประเด็นทางกฎหมาย เช่น ลิขสิทธิ์และ attribution
    • เพื่อหลีกเลี่ยงความเป็นไปได้ที่จะนำบางส่วนไปใช้โดยไม่ได้ตั้งใจ อีเมลที่ดูเหมือนเป็นไอเดียปริศนาก็จะไม่ถูกอ่าน
  • หากคิดว่าพบบั๊กในปริศนา ควรตรวจสอบใน subreddit ก่อน
    • หลังจากปริศนาเผยแพร่ไปแล้วหนึ่งชั่วโมง จะมีคนจำนวนมากแก้เสร็จแล้ว ดังนั้นหลังจากนั้นโอกาสที่จะเป็นบั๊กจึงต่ำมาก
  • Advent of Code ใช้งาน ได้ฟรี แต่ไม่ได้หมายความว่าสามารถคัดลอกได้อย่างเสรี
    • ไม่ควรรวมส่วนใดของ Advent of Code เช่น เนื้อหาโจทย์หรืออินพุตของตนเองไว้ใน repository โค้ด
    • เมื่อสร้างเว็บไซต์ ไม่ควรทำให้ดูเหมือน Advent of Code หรือใช้ชื่อที่คล้ายกัน

ประกาศทางกฎหมายและขอบเขตที่อนุญาต

  • Advent of Code เป็นเครื่องหมายการค้าจดทะเบียนในสหรัฐอเมริกา
  • องค์ประกอบการออกแบบ ข้อความ สไตล์ และแนวคิดของ Advent of Code เป็นทรัพย์สินแต่เพียงผู้เดียวของ Advent of Code และไม่สามารถคัดลอกหรือใช้งานได้หากไม่มีความยินยอมเป็นลายลักษณ์อักษรอย่างชัดเจน
  • ข้อความลิขสิทธิ์ระบุปี 2015-2025 Advent of Code และสงวนลิขสิทธิ์ทั้งหมด
  • สามารถลิงก์หรืออ้างอิงถึงปริศนา Advent of Code ได้ในการอภิปราย ชั้นเรียน ซอร์สโค้ด สิ่งพิมพ์ ฯลฯ รวมถึงในบริบทเชิงพาณิชย์
  • Advent of Code ไม่อ้างสิทธิ์ความเป็นเจ้าของหรือลิขสิทธิ์ใน การ implement วิธีแก้โจทย์ ของผู้ใช้

1 ความคิดเห็น

 
GN⁺ 2024-12-02
ความคิดเห็นจาก Hacker News
  • ฉันชอบ AoC เลยใช้ Rust แก้มาตลอด 2~3 ปีที่ผ่านมา และเล่นกันใน Discord แบบช่วยกันทำเฉลยที่เร็วที่สุด
    ระหว่างนั้นก็ได้เรียนรู้ทั้งเทคนิคการปรับแต่งประสิทธิภาพสารพัด, อัลกอริทึมขั้นสูง และ SIMD
    รอบนี้เลยกำลังลองแก้ทั้ง Rust และ Go เพื่อดูว่าจะได้ชอบหรืออย่างน้อยก็ทนใช้ Go ที่ใช้ในงานได้ไหม หรือจะยืนยันสมมติฐานว่าไม่ค่อยชอบและควรใช้เฉพาะตอนจำเป็น

    • ช่วงหลายปีที่ผ่านมาก็แก้ด้วย Go มาตลอด ถึงจะไม่ค่อยมีเวลาหรือสมาธิพอจะไปไกลเกิน day 6 แต่สำหรับงานแบบนี้ถือว่าค่อนข้างดี
      มันใช้งานได้จริง, ตั้งค่าสภาพแวดล้อมและงานจุกจิกน้อย, มีฟังก์ชันที่ต้องใช้ส่วนใหญ่อย่างการอ่าน/พาร์สไฟล์มาให้ในตัว, ประสิทธิภาพก็ดีและค่อนข้างใกล้ฮาร์ดแวร์จึงมีหลุมพรางด้านประสิทธิภาพแอบแฝงน้อย
      ฉันไม่เคยใช้ Rust เลยเทียบตรง ๆ ได้ยาก แต่ถ้ามองแบบผิวเผินจะรู้สึกว่ามันใช้งานจริงน้อยกว่า
      AoC ไม่ได้ต้องการมาตรฐานระดับโปรดักชันอย่างความปลอดภัยของหน่วยความจำมากนัก ดังนั้นในโจทย์ช่วงหลัง ๆ ความใช้งานจริงกับประสิทธิภาพจึงดูสำคัญกว่าความปลอดภัย
    • อยากรู้แนวทางการแก้ให้เร็วใน Rust ถ้ามีลิงก์ที่พอจะแชร์ได้ก็อยากอ่าน
    • ถ้าแชร์ Discord ได้ก็คงดี
      ทุกปีฉันพยายามลองปรับความเร็วด้วย Zig: https://github.com/ManDeJan/advent-of-code
    • Go ไม่ใช่ "Golang" และมี เวลา compile ที่ดีกว่า Rust อีกทั้งไม่พยายามยัดการใช้งาน concurrency หลายแบบที่เข้ากันไม่ได้ให้มารวมกัน
      ตลกตรงที่ฉันกลับมีภาวะกลืนไม่เข้าคายไม่ออกเพราะอยากพยายามชอบ Rust เหมือนกัน
    • อยากรู้ว่าปกติจัดโครงสร้างโปรเจกต์ AoC กันอย่างไร
      เคยจะลองทำด้วย Rust แต่ไม่แน่ใจว่าควรแยกเป็นโมดูลตามแต่ละวัน หรือให้แต่ละวันเป็นไฟล์ไลบรารีแล้วค่อยผูกเข้ากับจุดเข้าใช้งานหลัก
      ถ้ามีรีโพสาธารณะก็รบกวนแชร์หน่อย
  • ความท้าทายของปีนี้คือเขียนด้วย C แบบไม่มี standard library และไม่มี allocator
    ต้องสามารถรันบน STM32 ที่มี SRAM 32KB ได้
    เมื่อ 2 ปีก่อนเคยลองทำด้วย assembly แต่สุดท้ายยอมแพ้หลังเสียเวลาหลายชั่วโมงไปกับการทำ standard library สำหรับ assembly แล้วหันไปใช้ Rust แทน

    • ปีก่อนฉันลองทำด้วย C บน Amiga 1200 เครื่องจริง โดยใช้คอมไพเลอร์/รันไทม์ DICE ของ Matt Dillon
      ทำไปได้ไม่ไกลนัก แต่พอไม่มี memory protection แล้วมันยากขึ้นมากจริง ๆ
      ปีนี้ Amiga ของฉันมีอัปเกรด 060 ที่มี MMU แล้ว อาจจะลองกลับไปทำอีกถ้าหาวิธีใช้มันได้
    • ปีนี้ก็ยังใช้ Common Lisp เหมือนเดิม แต่โจทย์วันแรกฉันตั้งใจจะแก้ด้วยทุกภาษาที่ฉัน "พอใช้เป็น"
      C ก็รวมอยู่ด้วย และมันทรมานมากเพราะไม่มี hash table
      https://git.sr.ht/~q3cpma/aoc2024/tree/master/item/01
      ถ้าโพสต์ลิงก์รีโพไว้ให้ตามความคืบหน้าได้ก็คงขอบคุณมาก
    • ข้อจำกัดนั้นฟังดูยากมาก แต่ขอให้โชคดี
      ปีก่อนฉันแก้ ทุกข้อด้วย C โดยไม่ใช้ไลบรารีภายนอกเลย [1] และสนุกมาก
      มันบังคับให้กลับไปทำสิ่ง low-level ที่ลืมไปแล้วเอง เช่น heap และยังต้องเขียน numerical routine เองด้วย ซึ่งง่ายกว่าที่คิด
      [1] https://github.com/sebastianotronto/aoc/tree/master/2023
    • ถ้าเรียก RPC ได้ อย่างน้อยใน RAM 32KB ก็ทำอะไรก็ได้ :-)
    • มองอีกแบบหนึ่ง การใช้แค่ sh กับเครื่องมือ CLI มาตรฐานที่ไม่ Turing-complete ก็อาจน่าลองเหมือนกัน
      ประมาณว่าใช้ grep ได้แต่ใช้ awk ไม่ได้ ซึ่งจำกัดคล้ายกันแต่ไม่มีบั๊ก memory corruption ร้ายแรง
  • ปกติฉันทำ AoC ด้วย Common Lisp แต่ปีนี้กำลังลอง Swift
    สำหรับภาษากระแสหลักที่เป็น static type แล้ว มันค่อนข้างโอเคกับงานจุกจิกแบบนี้
    https://github.com/codr7/aoc24/tree/main/swift/Sources/aoc
    ปีนี้ค่อนข้างแปลกหน่อย เพราะฉันกำลังเตรียมอีเวนต์ที่งานใหม่
    เพราะคิดว่ามันช่วยให้นักพัฒนาได้เรียนรู้การแก้ปัญหาจริง มากกว่าการแค่เอา framework มาต่อกัน
    แต่แล้วหัวหน้าใหม่กลับกลายเป็นคนที่ทำงานด้วยไม่ได้อย่างสิ้นเชิง เลยต้องลาออก
    สุดท้ายก็คงเหลือแค่ฉันกับ Emacs เหมือนเดิม

    • ถ้ายังไม่ได้ทำ ลองเข้าร่วม Swift leaderboard ดูก็ดี: https://forums.swift.org/t/advent-of-code-2024
      การได้เทียบวิธีแก้ที่ต่างกันน่าสนใจมากทีเดียว
    • อยากรู้ว่าใน Swift การพาร์สและจัดการสตริงไม่ได้ทรมานมากใช่ไหม
      เมื่อก่อนฉันเคยจะลองทำ AoC ด้วย Swift แต่หมดไฟไปเยอะเพราะเรื่องนี้
      ฟังก์ชันสั้น ๆ แบบ one-liner เชิงฟังก์ชันนั้นดูดี แต่พอผ่านไปสักสัปดาห์ ภาระเรื่อง parsing น่าจะหนักมาก
    • อยากรู้ว่าคุณเขียน, compile และรันเฉลยทั้งหมดใน Emacs เลยหรือเปล่า
      ปีนี้ฉันก็อยากลอง Swift แต่รู้สึกว่าแค่จะทำ AoC แล้วต้องเปิด Xcode มันดูเยอะเกินไป
  • กลับมาอีกแล้ว ฤดูกาลแห่งการเขียน ตัวพาร์สอินพุตที่ซับซ้อนขึ้นเรื่อย ๆ ตลอด 25 วัน

    • ฉันเกลียดโจทย์แบบนั้นที่สุด
      ปัญหาที่แท้จริงคือการพาร์สอินพุตให้อยู่ในรูปที่จัดการสะดวก และพอพาร์สเสร็จแล้วที่เหลือก็มักง่าย
    • ผ่านไปไม่กี่วันสุดท้ายก็ต้องใช้ regex อยู่ดี และทุกปีก็ลืมจนต้องกลับไปเรียนใหม่
    • ไม่ได้แปลว่าตัวพาร์สอินพุตจะซับซ้อนขึ้นตามวัน
      ที่ซับซ้อนขึ้นคือโจทย์เอง และแม้แต่โจทย์ยาก ๆ แถววันที่ 22 หรือ 23 อินพุตก็มักยังเป็นแค่บรรทัดของจำนวนเต็มคั่นด้วยช่องว่าง หรือกริดของจุด คล้ายกับโจทย์ง่าย ๆ ช่วงวัน 1~3
    • มันเป็นแค่การใส่เรื่องเล่าน่าสนุกให้กับการพาร์สอินพุต
    • ฉันคิดว่า scanf กับ state machine มีประสิทธิภาพกว่าพาร์สเซอร์สไตล์ split/explode มาก
  • ปีนี้เป้าหมายคือเก็บดาวให้ครบทั้งหมดเป็น 500 ดวง
    เท่ากับว่าต้องทำทุกปี ทุกโจทย์ให้จบ
    ณ สัปดาห์ที่แล้ว มีคนที่มีดาวครบ 450 ดวงอยู่ราว ๆ 1024 คน
    แม้จะเพิ่งเริ่มเอาตอนประมาณ day 6 ของปี 2022 แต่ก็ติดใจ แล้วต้นปี 2023 พอมีเวลาก็เลยไล่ทำปีก่อน ๆ ต่อเนื่อง
    ถ้าเตรียมอัลกอริทึมไว้สักไม่กี่อย่างก็ไม่ได้ยากมาก และยังมีธีมที่วนกลับมาซ้ำในแต่ละปีด้วย
    มันสนุกดีที่ได้กลับมาทบทวนสิ่งที่เหมือนอัลกอริทึมจริง ๆ ที่ปกติไม่ได้จับบ่อยนัก
    ขอบคุณอาสาสมัครและ Eric และจากนี้ไปกะว่าจะบริจาคทุกปี เป็นอีเวนต์ที่ดีมากจริง ๆ

  • ชอบเพราะมันเป็นหนึ่งในไฮไลต์ของช่วงเวลานี้
    ครั้งนี้ต้องแก้โจทย์บนเครื่องบินที่บินข้ามมหาสมุทรแปซิฟิกไปทางตะวันออก
    สำหรับตัวเอง รวมถึงเพื่อน ๆ เพื่อนร่วมงาน และคนใน HN มันกลายเป็นธรรมเนียมสนุก ๆ ไปแล้ว
    รู้สึกทึ่งอีกครั้งที่ wastl กับเอลฟ์ผู้ช่วยช่วยกันสร้างสิ่งนี้ขึ้นมา
    ถ้าใครได้คุณค่าจากที่นี่และพอทำได้ ก็น่าจะสนับสนุนกันหน่อย
    ถึงจะเป็นโปรเจกต์ที่ทำด้วยใจ แต่ก็มีค่าใช้จ่ายจริงเหมือนกัน

    • มีสปอนเซอร์กับผู้ใช้ AoC++ เยอะมากจนคงมองว่าเป็น โปรเจกต์ที่ทำด้วยใจ เล็ก ๆ ที่แทบจ่ายค่าสมาชิกรายเดือนของ VPS ไม่ไหวได้ยาก
      ถึงอย่างนั้น adventofcode ก็ยอดเยี่ยมจริง ๆ และถ้าทำได้ก็ควรสนับสนุน
      แค่ดูจากขนาดของการสนับสนุนที่ได้รับตอนนี้ ก็ดูเหมือนว่าผู้สร้างน่าจะอยู่สบายพอสมควร
  • ปีนี้ตั้งใจจะลองทำด้วย F# และ Gleam แต่ก็คงเหมือนทุกปี คือไม่น่าจะมีทั้งเวลาและสมองพอทำเกิน 10~12 วัน
    คนที่ใช้ Python น่าจะลอง F# ดูสักครั้ง
    มันให้ความรู้สึกค่อนข้างใกล้กับการสคริปต์ และมี REPL ที่ยอดเยี่ยมด้วย

    • กำลังสานต่อธรรมเนียมการแก้ AoC ด้วย Whitespace [0]
      ปีแรกมันเป็นแรงจูงใจให้สร้างไลบรารีมาตรฐานขึ้นมา เพื่อไม่ให้มันน่าเบื่อเกินไป
      ตอนนี้กลับรู้สึกว่าน่าจะทำเครื่องมือที่ดีกว่านี้ให้เสร็จไปแล้ว
      ดีบักด้วย wsjq[1] ซึ่งเป็น CLI debugger คล้าย gdb ที่เขียนด้วย jq แต่ค่อนข้างช้า
      [0]: https://github.com/thaliaarchi/ws-challenges
      [1]: https://github.com/thaliaarchi/wsjq
    • กำลังทำด้วย bash และอยากดูว่าจะไปได้ไกลแค่ไหน
    • AoC สองครั้งก่อนหน้านี้ฉันทำด้วย F# และจริง ๆ ก็ทำแค่ช่วงไม่กี่วันแรก
      มันสนุกแม้กับคนที่ไม่เคยมีประสบการณ์กับการเขียนโปรแกรมเชิงฟังก์ชันมาก่อน
      ปีนี้ไม่มีเวลาร่วม แต่ถ้าจะทำก็คงเลือก F# อีกครั้ง
    • ฉันเองก็เพิ่งเริ่มเรียน F# และกำลังใช้มันกับ AoC ปีนี้
      ยังอยู่ช่วงต้น ๆ ของเส้นทางสายฟังก์ชัน แต่จนถึงตอนนี้คิดว่า AoC ช่วยได้มาก
    • อยากรู้ว่ารองรับ Linux เป็นอย่างไรบ้าง :)
  • ปีที่แล้วไปติดอยู่ที่ Day 12 ทั้งสัปดาห์
    เวลาตื่นอยู่ทั้งหมดหมดไปกับการคิดว่าจะทำให้มันผ่านได้ยังไง
    ปีนี้เลยใจดีกับตัวเองมากขึ้น เลือกไม่เข้าร่วมและจะไปสนุกกับวันหยุดฤดูหนาวให้เต็มที่

    • มันกินชีวิตมาหลายปีติดกัน และสองครั้งก็เพิ่งไปจบเอาในคืนก่อนคริสต์มาส
      ตอนนี้เลยไม่แตะเลย ความสนุกเปลี่ยนเป็นความเครียดค่อนข้างเร็ว
    • ฟังดูฉลาดดี
      การตั้งขอบเขตและได้พักผ่อนเป็นเรื่องสำคัญ
      สำหรับฉัน Advent of Code เหมือนทางลาดลื่น
      พอความยากสูงขึ้น ตอนแรกมันง่าย จากนั้นก็ยากแบบท้าทายและคุ้มค่า แต่ไม่นานก็กลายเป็นใช้เวลาเยอะเกินไป
      ซึ่งพอถึงตอนนั้น การที่เราลงอารมณ์ไปแล้วก็เริ่มอันตราย
    • เพื่อนเพิ่งแชร์อันนี้มาให้ไม่นาน คิดว่าน่าจะชอบ
      https://eli.li/december-adventure
    • ฉันติดอยู่กับ กราฟคัตพัซเซิล นานสี่เดือน
      ถึงขั้นต้องเขียนเอนจินกราฟแบบใช้แรงขึ้นมาเพื่อหาสามเส้นเชื่อมที่ยาวที่สุดที่ต้องตัด
      พอแก้ได้แล้วไปดูวิธีของคนอื่น กลับเห็นว่าใช้ตัวพิสูจน์ประพจน์ของ Meta จบในประมาณ 10 บรรทัด
      สำหรับฉันมันดูเหมือนทางลัดสุด ๆ
  • ชอบ AoC มาก
    ไม่ต้องไปสนใจว่า AI bot จะแก้หรือเปล่า หรือมีคนตื่นเช้ากว่าเราไหม แค่ทำเพื่อความสนุกของตัวเองก็พอ
    จะชอบเพราะตัวความท้าทายเอง หรือเพราะอยากลองภาษาใหม่ก็ได้ทั้งนั้น
    ฉันชอบแก้ด้วย สไตล์ฟังก์ชันของ Kotlin ให้ต่างจากงานประจำมากที่สุดเท่าที่ทำได้
    วันนี้ก็โพสต์คำตอบไว้ด้วย ใช้ยูทิลิตีอยู่เลยไม่ใช่ Kotlin ล้วน ๆ แต่การค่อย ๆ รวมฟังก์ชันเจ๋ง ๆ จนกลายเป็นเหมือนไลบรารีก็เป็นส่วนหนึ่งของความสนุกเหมือนกัน
    https://github.com/Matsemann/algorithm-problems/blob/main/ad...

    • ชอบฟังก์ชัน transpose
      หลายปีที่ผ่านมาใช้ Python NumPy แต่ปีนี้มาใช้ Kotlin แล้วในโจทย์วันแรกสิ่งที่คิดถึงที่สุดคือ ฟังก์ชัน transpose
      โค้ดของฉันอยู่นี่: https://github.com/charelF/AdventOfCode/blob/main/kt/src/y20...