Advent of Code 2024

 (adventofcode.com)
1 ポイント 投稿者 GN⁺ 2024-12-02 | 1件のコメント | WhatsAppで共有
  • 12月のプログラミングパズルイベント Advent of Code は、実力や言語選択の壁を下げ、練習・教育・競争などさまざまな目的で参加できるように設計されている
  • コンピュータサイエンスの背景や高性能な機材がなくても参加でき、すべての問題には 10年前のハードウェア で最大15秒以内に終わる解法がある
  • 解法に行き詰まったら、例題の確認、自作の テストケース、入力の検証、友人や subreddit のヒントという順で問題を絞り込めばよい
  • 2024年のFAQには、イベント期間の変更、global leaderboard の廃止、private leaderboard のルール、AIの利用、複製・再配布の制限といった運営ポリシーが整理されている
  • スピード競争は任意であり、参加者は自分にとって有用なやり方でパズルを解き、学ぶことに集中できる

Advent of Codeの性格と参加条件

  • Advent of Code は小さなプログラミングパズルで構成された Advent calendar 形式のイベントである
  • パズルはさまざまな実力レベルを対象としており、好きな プログラミング言語 で解くことができる
  • 面接準備、社内教育、大学の課題、練習問題、スピード競争、参加者同士の挑戦などに活用されている
  • コンピュータサイエンスの背景は必須ではなく、多少のプログラミング知識と問題解決力があれば参加できる
  • 高性能なコンピュータも不要で、すべての問題には 10年前のハードウェア で最大15秒以内に終わる解法がある

行き詰まったときの解法手順

  • 解法に行き詰まったら、まずパズルに含まれている 例題 でプログラムを検証すべきである
  • 例題の結果が合わないなら、問題文を読み直し、誤解していた点や想定と異なるプログラムの動作を確認する
  • 例題は合っているのに正答にならない場合は、手計算で答えを確認できる テストケース を自分で作ってプログラムに適用する
  • パズル入力全体を漏れなく使っているかも確認すべきである
  • それでも行き詰まるなら、友人に助けを求めたり後で再挑戦したりでき、subreddit でヒントを得ることもできる

サイトの利用と認証

  • コードブロックは JavaScript が有効なら トリプルクリック で全体選択できる
  • 認証には OAuth を使い、外部サービスで本人確認を行う
    • ログイン時の資格情報は Advent of Code ではなく、その外部サービスにのみ提供される
    • 外部サービスは Advent of Code サーバーに、ユーザーが本人であることを伝える
    • 通常は、すでに公開されている情報以外の追加情報は明らかにならない
    • Advent of Code は認証サービスの一意ID、名前、URL、画像を記憶する
  • サイトの文字が読みにくい場合は、高コントラストの代替スタイルシートを使える
    • Firefox は View → Page Style → High Contrast を標準サポートしている

難易度、公開時間、イベント期間

  • パズルの難易度とテーマはイベントごとに異なる
  • 一般的には時間がたつほどパズルは難しくなるが、個人のスキルの組み合わせによって体感難易度は大きく変わりうる
  • パズルは EST/UTC-5 の深夜0時 に公開される
    • その時間が、運営者が安定して問題なく動作しているか確認できる時間だからである
    • 深夜0時に参加できなくても問題はなく、地域内の競争には private leaderboards を利用できる
  • イベント日数は変更される
    • Advent of Code の運営には毎年多くの自由時間が必要で、パズル制作がその大半を占める
    • 10年間日程を維持したのち、変化が必要になった
    • パズルは日付番号に合わせて12月1日に始まり、毎日公開され、12月中旬 に終了する

リーダーボードとスピード競争

  • global leaderboard は廃止される
    • 運営者、インフラ、多くのユーザーにとって最大級のストレス要因のひとつだった
    • 一部の参加者は競争を過度に深刻に受け取り、DDoS攻撃のような行動まで起きた
    • 多くのユーザーが、自分の時間が比較対象より遅いという理由で、自分をより劣ったプログラマーだと誤って結論づけていた
    • 2015年に楽しい機能として始まったが、10年のあいだに問題が徐々に大きくなっていった
  • private leaderboard の読み取り専用ビューは共有できる
    • ただし、この機能やデータを使って新たな global leaderboard を作ってはならない
  • 速い解答時間は任意である
    • 速く解くには、パズルを解くこと以外にもさまざまな追加スキルと多くの練習が必要になる
    • speed-solve コードは、コードレビューを通すコードとはまったく違って見えることが多い
    • 自分にとって有用な目標に合わせてアプローチを選び、スピード競争を完全に無視しても構わない

AIの利用と private leaderboard のルール

  • private leaderboard に参加しているなら、運営者に期待されるルール を確認すべきである
  • そのルールが合わなければ、別の private leaderboard を探すか、自分で作ることもできる
  • private leaderboard のルールには、最大実行時間、許可される言語、パズルを最初に開ける時間、使用できるツール、作業中にばかげた帽子をかぶる必要があるかどうかまで含まれうる
  • Advent of Code のパズルを解く際の AI利用は推奨されない
    • 代わりに、友人をジムに行かせたら自分が強くなれるか、という比喩が使われている
    • パズルは人間が解いて面白いように設計されており、AIが解けるかどうかは考慮していない
    • AIプロンプトの練習が目的なら、その目的向けに設計された別の練習のほうが適しているかもしれない

パズルのアイデア、バグ、複製ポリシー

  • パズルのアイデアは送るべきではない
    • 著作権や attribution のような法的問題のため、アイデアは受け付けていない
    • 誤って一部を使ってしまう可能性を避けるため、パズルのアイデアに見えるメールも読まない
  • パズルのバグを見つけたと思ったら、まず subreddit で確認すべきである
    • パズル公開から1時間もたてばすでに多くの人が解いているため、それ以降はバグである可能性は非常に低い
  • Advent of Code は無料で 利用 できるが、複製まで自由というわけではない
    • コードリポジトリに、パズル本文や自分の入力など Advent of Code の一部を含めるべきではない
    • Webサイトを作るとき、Advent of Code のように見せたり、似た名前を付けたりしてはならない

法的告知と許容範囲

  • Advent of Code は米国の登録商標である
  • Advent of Code のデザイン要素、文言、スタイル、概念は Advent of Code の単独財産であり、明示的な書面による同意なしに複製または使用することはできない
  • 著作権表示は 2015-2025 Advent of Code であり、すべての権利を保有する
  • 議論、授業、ソースコード、印刷物などで Advent of Code のパズルにリンクしたり参照したりすることは、商業的文脈でも可能である
  • Advent of Code は、ユーザーの 解法実装 に対する所有権や著作権を主張しない

関連記事

1件のコメント

 
GN⁺ 2024-12-02
Hacker News の意見

  • AoC が好きで、この2〜3年は Rust で解いており、Discord でみんなと一緒に最速の解法を作るような遊び方をしていた
    その過程で、さまざまな性能最適化のコツ、高度なアルゴリズム、SIMD を学んだ
    今回は、職場で使っている Go を好きになれる、あるいは我慢できるようになるのか、それともやはり微妙だという仮説を確認して本当に必要なときだけ使うことにするのかを見るため、Rust と Go で解いているところ

    • ここ数年 Go で解いてみたが、day 6 以降に進む時間や集中力はいつも足りなかったものの、こういう用途にはかなり良かった
      実用的で、環境設定や横道の作業が少なく、ファイル読み込み/パースのような必要な機能の多くが組み込まれており、性能も良くハードウェアに近いので隠れた性能上の落とし穴が少ない
      Rust は使ったことがないので比較は難しいが、ごく表面的に見ると、より実用性に欠けるように感じる
      AoC ではメモリ安全性のようなプロダクション基準はそれほど必要ないので、後半の問題では安全性より実用性と性能のほうが重要に見える
    • Rust で素早く解くアプローチが気になるので、共有できるリンクがあれば見てみたい
    • Discord を共有してもらえるとうれしい
      毎年 Zig で速度最適化に挑戦しようとしている: https://github.com/ManDeJan/advent-of-code
    • Go は「Golang」ではなく、Rust よりコンパイル時間が良く、相性の悪い並行処理の使い方を無理に結合しようとしない
      むしろ逆に、Rust を好きになろうとしているというジレンマがある
    • AoC プロジェクトをどう構成しているのか気になる
      Rust でやってみようとしたが、日付ごとにモジュールを分けるべきなのか、各日をライブラリファイルにしてメインのエントリポイントにつなぐべきなのか、感覚がつかめない
      公開リポジトリがあれば共有してほしい

  • 今年の挑戦は、標準ライブラリやアロケータなしで C で書くこと
    32KB SRAM を持つ STM32 で実行できなければならない
    2年前はアセンブリでやってみたが、アセンブリ用の標準ライブラリを何時間も作った末に諦めて Rust に乗り換えた

    • 去年は実機の Amiga 1200 上で C でやってみて、DICE という Matt Dillon のコンパイラ/ランタイムを使った
      あまり進められなかったが、メモリ保護がないと本当に難しくなる
      今年は Amiga に MMU 付きの 060 アップグレードがあるので、それをどう活用するかを見つけて、またやってみるかもしれない
    • 今年も Common Lisp でいくが、初日の問題は自分が「知っている」すべての言語で解いてみることにした
      C も含めたが、ハッシュテーブルがなくて本当につらかった
      https://git.sr.ht/~q3cpma/aoc2024/tree/master/item/01
      進捗を見られるようにリポジトリのリンクを載せてくれるとありがたい
    • その制約はかなり難しそうに聞こえるが、幸運を祈る
      去年は外部ライブラリなしで C ですべての問題を解き [1]、とても楽しかった
      忘れていた低レベル要素、たとえばヒープのようなものを自分で実装することになり、数値ルーチンも自作することになったが、思ったより簡単だった
      [1] https://github.com/sebastianotronto/aoc/tree/master/2023
    • RPC 呼び出しさえ可能なら、32KB RAM の中でも何でもできる :-)
    • 対称的に考えるなら、sh とチューリング完全ではない標準 CLI ツールだけを使うのも検討に値する
      grep はよくて awk はだめ、という具合だが、同じように制限的でありながら致命的なメモリ破壊バグはない

  • ふだん AoC は Common Lisp でやるが、今年は Swift を試しているところ
    静的型付けの主流言語としては、こういう細かい操作にかなり向いている
    https://github.com/codr7/aoc24/tree/main/swift/Sources/aoc
    今年は少し変で、新しい職場でイベントを準備しているところだった
    開発者たちがフレームワークをつなぎ合わせるより、実際の問題解決を学ぶのに役立つと思ったからだ
    ところが新しい上司がどうしても一緒に働けない人だと分かり、辞めざるを得なかった
    結局いつものように、自分と Emacs だけが残ることになりそうだ

    • まだなら Swift リーダーボードに参加してみるといい: https://forums.swift.org/t/advent-of-code-2024
      互いの解法を比較するのはなかなか興味深い
    • Swift での文字列パースと操作はかなり苦痛ではないのか気になる
      以前 Swift で AoC をやろうとしたが、その部分のせいでかなり冷めた
      小さな関数型のワンライナーは良かったが、1週間ほど経つとパースの負担が大きくなりすぎそうだ
    • 解法の作成、コンパイル、実行をすべて Emacs でやっているのか気になる
      今年 Swift を試してみたかったが、そのために Xcode を立ち上げるのは少し大げさな感じがする

  • また来たな、だんだん複雑になる入力パーサを25日間書く季節が

    • そういう問題がいちばん嫌い
      本当の問題は入力を扱いやすい形にパースするところにあり、いったんパースが終われば簡単になる
    • 数日たつと結局正規表現を使うことになり、毎年忘れているのでまた覚え直さなければならない
    • 入力パーサが日を追うごとに複雑になるわけではない
      複雑になるのは問題そのもので、22日目や23日目あたりの難しい問題でも、入力はたいてい空白区切りの整数行や点のグリッドのような形で、1〜3日目の簡単な問題と似ている
    • 入力パースに面白いストーリーを付けているだけ
    • split/explode スタイルのパーサより、scanf と状態機械のほうがはるかに効果的だと思う

  • 今年は星をすべて集めて、合計 500個の星 を埋めるのが目標
    つまり全年度・全問題を終えるということ
    先週時点で、全体で450個の星を持っている人が約1024人ほどいた
    2022年のday 6あたりでようやく始めたけれどハマって、2023年初めに時間があったので過去年度を一気に解いた
    いくつかアルゴリズムを用意しておけば極端に難しくはなく、毎年繰り返されるテーマもある
    普段あまり触らない、実際のアルゴリズムのようなものを学び直す楽しさがある
    ボランティアの皆さんとEricに感謝しているし、これからは毎年寄付しようと思う。本当に良いイベント

  • この時期のハイライトの一つなので好き
    今回は太平洋を東向きに渡る飛行機の中で解かなければならなかった
    自分にとっても、友人・同僚・HNの人たちにとっても楽しい恒例行事になった
    wastlと手伝いのエルフたちが作ってくれて、改めてすごいと感じる
    ここから価値を得ている人は、可能なら支援するといいと思う
    情熱プロジェクトではあるけれど、実際に費用がかかるのも事実

    • スポンサーやAoC++ユーザーが非常に多いので、VPSの月額料金を払うのに苦労する小さな 情熱プロジェクト と見るのは難しそう
      それでもadventofcodeは本当に素晴らしいし、可能なら支援するのがよい
      ただ、現在受けている支援の規模を見ると、制作者はかなりうまくやっているのではないかと思う

  • 今年は F#とGleam でやってみようと思っているが、毎年のことながら10〜12日以上続ける時間と頭はなさそう
    Pythonを使っている人はF#も一度試してみるといいと思う
    スクリプティングにかなり近く感じられるかもしれないし、優れたREPLもある

    • AoCを Whitespace で解く伝統を続けているところ [0]
      最初の年は退屈しすぎないように、標準ライブラリを作る動機になった
      今となっては、もっと良いツールを完成させておけばよかったと思う
      jqで書いたgdbのようなCLIデバッガであるwsjq[1]でデバッグしているが、遅い
      [0]: https://github.com/thaliaarchi/ws-challenges
      [1]: https://github.com/thaliaarchi/wsjq
    • bash でやっていて、どこまで行けるか見ている
    • 過去2回のAoCは F# でやったが、実際には序盤の数日だけだった
      関数型プログラミングの経験がなかった人間にも楽しかった
      今年は参加する時間がないけれど、もしやるならたぶんまたF#を選ぶと思う
    • 私もF#を学び始め、今年のAoCで使っているところ
      まだ関数型の旅の初期段階だが、今のところAoCは役に立っていると思う
    • Linux対応はどうなのか気になる :)

  • 昨年はDay 12で 丸一週間詰まり、解き方を考えるのに起きている時間をすべて食われた
    今年は自分に少し寛容になって参加せず、冬休みをきちんと楽しもうと思う

    • 何年も連続で生活を食いつぶされ、2回はクリスマスイブにようやく終えることにもなった
      今ではまったく見ない。楽しさがかなり早くストレスに変わる
    • 賢明に見える
      境界線を引いて休みの時間を楽しむのは大事
      私にとってAdvent of Codeは滑りやすい坂道のようなもの
      難易度が上がるにつれて最初は簡単で、その次はやりがいのある難しさになるが、いつの間にか時間を使いすぎる
      その頃にはすでに感情的に入れ込んでしまっているのが危ない
    • 友人が最近これを共有してくれたが、気に入りそう
      https://eli.li/december-adventure
    • グラフカットのパズル で4か月詰まった
      切るべき最長の3本の辺を見つけるために、力学ベースのグラフエンジンまで書く必要があった
      解いた後で他の人たちの解法を見たら、Metaの命題ソルバーを使って10行ほどで終わらせていた
      私にはものすごい裏技のように見えた

  • AoCが好き
    AIボットが解いているのか、他の人がもっと早起きしているのかを気にする必要はなく、ただ自分の楽しみとして解けばいい
    挑戦そのものが好きだからでも、新しい言語を試したいからでも構わない
    私は仕事とは違うやり方をしたいので、できるだけ Kotlinの関数型スタイル で解くのが好き
    今日の解法も上げておいた。ユーティリティを使っているので純粋なKotlinではないが、便利な関数を集めて一種のライブラリを作るのも楽しみの一部
    https://github.com/Matsemann/algorithm-problems/blob/main/ad...