【ハッカソン初参加！】技育CAMPの2023マンスリーハッカソンvol.9に参加しました！

こんにちは、regiです！先日に技育CAMPの2023マンスリーハッカソンvol.9に参加させていただいたため、今回はその参加記を書かせていただきます！

はじめに

私自身は今回がハッカソン初参加でした。初めは即席チームを組ませていただく形で参加しようかも考えましたが、ハッカソンを通して初挑戦してみたい技術がフロントエンド側にもバックエンド側にもインフラ側にもあったため、今回は個人参加という形を取りました。もう勉強がメインですね。

開発したプロダクト

概要

私は「ごほうびマネージャー」というサービスを開発しました。どういうサービスかというと、「頑張った自分にご褒美♪」という日常での些細な出来事を管理することが出来るWebアプリケーションです！

簡単に何が出来るかを説明すると、「『ハッカソン』を『600』分頑張ったら『ハーゲンダッツ』のごほうび！！」というふうに、『』の部分をユーザが設定することが出来て、そこから実際に設定した内容を頑張った時間を送信することで、その総時間に応じてごほうびをGETすることが出来ます。本サービスでは「『ハッカソン』を『600』分頑張ったら『ハーゲンダッツ』のごほうび！！」という設定の1セットを「サイクル」と呼んでいます。

デモ

※ハッカソン期間中ではUIの作りこみに割く時間が無かったため、簡素なものとはなっていますが許してください！

まずはアカウントの登録をしてみます。

次に、先ほど登録したアカウントでログインしてみます。

ログインすると、TOPページに飛びました。

当然ですが、まだサイクルが設定されていないため、早速設定していきましょう！

「サイクルを作ってみる！」を押すと、このようなページに飛びました。

先ほどの例の通りに入力し、「これで作る！」を押してみます。

そうすると無事にサイクルが作られ、それがTOPページにも反映されました！

次に、早速「がんばりを報告する！」を押してみましょう！

「がんばりを報告する！」を押すと、このようなページに飛びました。

今回は500分と入力し、「報告！」を押してみます。

そうすると無事にTOPページに反映され、「あと600分！」の表記が「あと100分！」というふうに変わりました！

試しにまた「がんばりを報告する！」を押して、時間を報告してみましょう！

今回は400分と入力し、「報告！」を押してみます。

そうすると無事にTOPページに反映され、「あと100分！」の表記が「あと300分！」というふうに変わりました！

そして、もともと設定していた「600分」を超えたため、ハーゲンダッツのごほうびが1回分もらえました！嬉しい！

最後に、「使ったごほうびを報告する！」を押してみましょう！

「使ったごほうびを報告する！」を押すと、このようなページに飛びました。

今回は1回と入力し、「報告！」を押してみます。

そうすると無事にTOPページに反映され、「1回分」の表記が「0回分」というふうに変わりました！

またごほうびGET出来るようにこれからも頑張ろう！

技術スタック

今回はフロントエンドはReactで実装し、バックエンドはPythonで実装しました。そして、構成はAWSサーバレス構成を採用しました。具体的な構成は以下の通りです。

これは余談ですが、AWSサーバレス構成において最終的には以下のような構成を目指していましたが、当然ながら時間が足りなかったために上のような構成となりました...。期間が2週間の個人開発で初挑戦技術を欲張るのはやめよう！

初めてチャレンジしたこと

• AWSサーバレス構成の構築
• API Gatewayの導入
• Lambdaの導入
• DynamoDBのテーブル設計
• IAMロールの設定と付与
• CloudFrontの導入
• Terraformの導入
• Reactの導入
• SPAの採用
• セッション認証の実装
• ブランチのマージ時にPull Requestを必須にするように設定
• 独自ドメインの取得

チャレンジしたかったが手が回らなかったため、今後行なっていきたいこと

• Route 53の設定
• ACMで発行したSSL証明書の設定
• Golangの導入とパフォーマンス比較
• KMSを用いた環境変数の暗号化
• 本サービスの機能実装もろもろ
• 可読性の考慮
• 変数名や関数名の命名規則の整備
• TerraformやReactのディレクトリ構成の最適化
• CloudFrontとS3の構成のTerraformでの管理
• 開発環境や本番環境の整備
• 動作やパフォーマンスのテスト全般

ハッカソンを完走した感想

私自身は「アッと驚くサービスを作ってやろう！」という気持ちよりも「インフラ面で構築したことがない構成を構築してみたい！特にサーバレス！」という気持ちの方が勝っていたため、他のチームの方々の発表ではサービスの機能やUIなどが私のそれらと比べると凄すぎて、もうずっとこちらがアッと驚かされっぱなしでした...。それに、「スライドとか2～30分くらいで作ったもので良いか～」と思っていたら、他のチームの方々はスライドも「ガチ」で作っていたため、恥ずかしくなってしまいました(泣)

しかしながら、本来の目的であったサーバレス構成の構築をTerraformを用いて行なうことを実際に成功させることが出来たため、非常に嬉しくなりました！これからもインフラ面を中心に知識を付けていき、様々な構成を実際に構築していきたくなりました！

また、もしも再びハッカソンに参加させていただく機会がありましたら、しっかりとサービスの機能やUI、スライドにも力を入れたいと思います(笑)

RatedのAHCに初めて参加してみました

こんにちは、regiです。

先日初めてRatedのAtcoder Heuristic Contest(AHC019)に参加してみました。

結果は786人中104位となり、初参加にしてヒューリスティック緑になることができました！

この記事では、私がAHCに初めて参加するにあたって、やって良かった点や反省点などを半ば日記形式で書きました。なお、今回の知育パズル問題の取り組み方に対してという意味合いよりも、ヒューリスティックコンテスト自体の取り組み方に対してという意味合いの方が強いため、その問題概要や具体的な解法などはあえて一旦書くのをやめておきます。

そもそもなぜAHCに参加することに？

私自身はもともと前々からヒューリスティックとそのコンテスト自体には興味がありましたが、なんやかんや学業やICPCなどで時間を取られていたため、今までなあなあにしてしまっていました。しかしながら、それらも1~3月に落ち着き始めたため、そのタイミングで試しに初めてヒューリスティックについて本格的に調べて触れてみたら…そのままハマってしまいました。その流れで、「ヒューリスティック面白いからコンテストにも参加してみたい！だから次のAHCに参加してみよう！」と強く思うようになり、AHC019に参加してみたというわけです。このようにしてAHC019に参加することを決めたのは、その開始日の2週間ほど前だったと思います。

コンテスト開始前の私はどうだったか

コンテスト開始日の2週間ほど前の私は以下のような状態でした。

「モンテカルロ法とかは大昔になんちゃって実装をしたことがある程度で、MCTSは1ミリも知らない。ビームサーチや焼きなましは薄らどういうものかは分かるけど…具体的な処理とかはよく知らないし、当然実装も1ミリもやったことない。」

(↑初心者丸出しです。)

「この状態ではAHCに参加したとしても、なんちゃって実装しか出来ないまま終わりそうだ…。」という危機感を持ったため、急いでそのビームサーチや焼きなましなどの手法について書かれた記事を読み漁ってみると、焼きなましを最初に完璧にしておくと良さそうであることが分かったので、まずはその焼きなましを真っ先に学ぶことにしました。焼きなましに関して、具体的な操作を理解することや、局所解にハマらないようにするための考え方については比較的容易に理解を進めることは出来ましたが、その焼きなましの基本的な実装方法と、「どうすればそれを実際にAHCの過去問などで上手く使うことが出来るのか？」を考えることとの2つにおいて個人的に大きな壁を感じました。

まず、焼きなましの基本的な実装方法については、私自身がC++における乱数実装やchronoについてあまり知識がない状態だったからということもあり、C++でどのように実装するべきかを知るために頑張って記事を漁りましたが、あまり私に合うものはありませんでした…。最終的には、同じ大学の方のAHCの過去提出コードを参考にする形で書くことで事なきを得ました...。

そして、それよりも遥かに問題となった「どうすればそれを実際にAHCの過去問などで上手く使うことが出来るのか？」を考えることについては、ヒューリスティックコンテストが強い方の参加記を読み漁ることで、少しずつ出来るようにしていきました。この時点ではまだ少しでしたが…。

そのように精進していった結果、コンテスト開始日の1週間ほど前にAHC012にて初めて焼きなましの実装と実行に成功しました…！

提出 #39573656 - AtCoder Heuristic Contest 012 https://t.co/mP5YuQzKS6
え！！初めての焼きなましで102位相当のスコア出せた！！！！！！

— regi (@Re_code_A) 2023年3月10日

ちなみにコンテスト開始日の1週間ほど前から開始日までは、ずっとCodinGameの過去問にてMCTSの実装を頑張っていました。誰かMCTSの高速化についての記事書いてください…どうしても分からないんです…。AHCで使うことはあまり考えていなかったため、本当にちなみにです。

コンテスト中の私はどうだったか

当然ながら初日から意気揚々と問題を見にいき、その文章を隅から隅まで丁寧に読みました。しかし、何も分かりませんでした。そのまま初日は何一つ良い発想が降ってくることはなく、「ヒューリスティック初心者が長期コンの問題でまともな方針を立てられるわけありませんでした…。」と諦めそうになりました。これはまさに前述の通り、「どうすれば焼きなましを実際にAHCの過去問などで上手く使うことが出来るのか？」を考えることが全く出来なかったというわけです。そのような感じがしばらくだらだらと続き、コンテストの最初の1週間は半ば放心状態でCodinGameでMCTSの実装を進めつつ、AHCも少しずつ考察を進めていくという状態でした。

なんとかしてこの状態から抜け出すために、過去のAHCの上位の方々の参加記を更に読み込むことにしましたが、これをしたことが後々かなり役立ちました。具体的には、例えばterryさんのAHC013の参加記から「近傍を複数採用する」や「破壊してから再構築する」というアイデアを得ることで、大きくスコアを伸ばすことができました！その過程の中で「こういうふうに今の解と近傍解との評価値の差がなだらかになっていって、焼きなましが局所解にハマりにくくなるのか…。」ということを直感的ではありましたが実感することが出来たので、焼きなましにおいてそれを意識することの大切さを私自身のコードからも学ぶことができました！

また、他にも多くの参加記を通して得た更に大事なこととして、「どんなに強い方でも100%理論のみで勝負しているわけではなく、理論でははっきり分からない部分はとりあえず書いてみることに重きを置いている傾向にありそう」ということを知ることができました。実のところ、この部分は私自身かなり誤解していまして、「強い方々はもう初日から理論的に確実な手法を採用して、残りの期間では微調整などに専念しているのだろう」と無意識に考えていたため、「最初の1週間で理論的に確実だと思われる方針が何も立たない自分はなんて情けないんだ！」という気持ちに支配されていました。ヒューリスティックにおいて、この考えは命取りだったと…今は思います。もしかすると、初参加から順調にスコアを伸ばすことができたのは、この考え方に改めることができ、それを意識してコンテストに取り組むことができたおかげなのかもしれません。

結果は良かったとはいえ、それでも反省点の方が多かったのも事実で、私のローカル環境は今回のAHC019において、スコアを効率良く上げていくための環境とはとても言える状態ではありませんでした…。具体的には、サンプルは一括処理することが出来ないからいちいち全部手打ち、optunaが使えないからハイパーパラメータは全部雰囲気で決定、ローカル環境のCPUが遅いからAtCoderのコードテストでデバッグ、プロファイラも無いうえに私自身もC++はどの処理が遅いのかが把握出来ていないので、それをちまちま調べていくところから開始、などと…もしかしたらヒューリスティックコンテストの強い方々が見たら失神してしまうかもしれません…。ここを徹底するとスコア改善に掛ける時間も大幅に削ることができるだろうと思うので、ここもできる限り最適化していきたいですね…！

それに、bitboardによる高速化を知っていたのに試さなかったのは明らか怠慢であったため、その点も反省したいです…。

やって良かったと思うこと

・他の方の焼きなましなどの実装方法をコードを見て回ったこと

・ヒューリスティックコンテストが強い方々の参加記を、解法からその解法へと行き着いた過程までしっかりと読み込んだこと

・焼きなましの性能を上げるうえでの考え方について、しっかりと様々な記事を参考にしたこと

やっておけば良かったと思うこと

※コンテストまでに時間がたくさんあったわけではないので一部は仕方ないものもありますが、挙げるとしたら以下のようになります。

・optunaを使えるようにしておくこと

・高性能CPUを使えるようにしておくこと

・サンプルの一括処理を出来るようにしておくこと

・プロファイラを使えるようにしておくこと

・bitによる高速化の威力を知っておくこと

・実装法による実行時間の差異をある程度把握しておくこと

・ビームサーチ辺りを完璧にしておくこと

感想

正直、初参加では上位50%に入れればいいな程度に思っていたため、まさかパフォ1908を取って一気にヒューリスティック緑色になれるとは思っていませんでした…。このような結果となったのは、間違いなくしっかりと自分なりにヒューリスティックに継続して向き合えたからだと感じるため、本当に嬉しく思います。しかしながらヒューリスティックは奥が深く、やっておけば良かったことを考え始めると結構出てきてしまいました。これらにも向き合うことで、よりヒューリスティックの奥深さを堪能することができ、もっと実力も上げていくことが出来ると考えているため、これからもヒューリスティックを学んでいきたいです！良い問題をありがとうございました！

第3回KLab Server Side Campに参加させていただきました！

初めに

初めまして、私はregiと言います。普段は競技プログラミング、音楽ゲームなどに力を入れている大学生です。執筆時点では大学4年生です。

私は2022年9月上旬にご縁がありまして、KLab様が主催されている「第3回KLab Server Side Camp」に参加させていただきました！

今回の記事では、その報告をしていきたいと思います！

KLab Server Side Campとは？

それは、KLab様が開発された音楽ゲームを通して、そのアプリのサーバサイドの技術はどうなっているのかを「講義形式での説明→各々実習」という形で理解を深めて経験も積もう！といったインターンです！期間は5日間です。また、第3回ではオンライン開催でした。

「SQLは講義や開発で触ったことある程度…sshはよく分からない…でも音楽ゲームの知識は豊富」といった私でも一通りの実装をすることが出来たので、「このインターン気になるけど、SQL？よく分からないから無理そう…」などと思ってしまっている方々も、気になると思ったらとりあえずエントリーしてみるべきです！

また、KLab Server Side Campについて詳しく知りたい方は、下の記事も是非読んでみてください！

http://dsas.blog.klab.org/archives/2022-01/52381462.html

インターンの流れ

1日目

初めに参加者の方々やメンターの方々が皆それぞれ自己紹介をし、それからインターンで使うCodespaces, MySQL, SQLAlchemy Core, ipythonの扱い方や概要などを教えていただきました。扱い方に関して実習も交えながらの説明であったため、理解した上で安心して後半の課題にも望むことが出来ました、本当にありがとうございました！

関係無いですが、この日に私のノートPCの内臓マイクがとうとう機能しなくなってしまったので、私だけ何もしゃべれない状態でした...メンターの方々には迷惑を掛けてしまいました...。そのため、この日の夜に近所のドン・○○○○まで行ってマイクを買いました(笑)

2日目

FastAPI, pydantic, Swagger UIの扱い方や概要などを教えていただきました。また、ここで音楽ゲームのマルチプレイをするためのRoom APIをいくつか実装するという課題が与えられました。少し補足すると、RequestやResponse、その他Enumなどの構造体の仕様も与えられた状態で、それをもとに各自で実装していく形でした。

私はipython上でSQLAlchemy Coreの挙動をいろいろ確認して「Djangoを使っていたときはデータベース操作の際にSQLを書いていなかったけど、やっぱりSQL書いた方が挙動分かりやすくていいな！」と呑気に感動していたら、各Room APIのRequestやResponseのクラスやその他構造体を実装しただけで終わってしまいました、反省...。

3日目

データベース操作におけるトランザクションについて教えていただきました。それ以外は基本与えられた課題の続きをしました。

私はRoom APIの半分ほどを実装し終えました。このとき、データベースのテーブルに格納するデータとして何を採用するべきか迷いましたが、「どういったタイミングでデータを取得したいか」や「さらに機能を拡張する」などの観点からも考えると良いということをメンターの方々や他の参加者の方々から知ることができ、無事データベースの構成を考えて作ることができました。ありがとうございました！

ちなみに、この日のインターンが始まる前や終わった後にその音楽ゲームの全曲フルコンを狙っていましたが、1曲だけどうしても出来ないものがあったので断念しました...。実は指がかなり硬いので、人差し指中指薬指の6Kは辛かった。

4日目

同様に課題の続きをしました。この日からRoom APIの実装を全て終え、実際に音楽ゲームのマルチプレイを他の参加者の方々とテストプレイし始めていた方も居ました。

私も形だけはRoom APIの実装を全て終えましたが、数々の原因不明のバグに見舞われてしまいました...。このとき、あと数十分でインターンが終わる時間であったため、他の参加者の方々のテストプレイの方に合流してました(笑)　実際にテストプレイに合流すると、参加者の方々が「ホストが退出した際にはホストやその部屋をどうするか？」や「ライブ中に途中で人が抜けた場合はどうするか？」などについて話していました。特にホスト退出問題に関して私は当初、「ホストが退出した際はその部屋そのものを削除する仕様」にしようと考えていましたが、「部屋はそのまま残して、まだそこにいる誰かにホストになってもらう仕様」にしようと考えている方も居て、「どちらにした方がユーザのためになるのか...？」と執筆時点の今になって不思議に思いました。

5日目

最終日では、午前に課題進め、午後から資料作成、成果発表、懇親会という流れで締めくくられました。

私は最後の課題を進める時間内で全てのバグを取り切ることが出来なかったので、インターン中に私の音楽ゲームでマルチプレイテストすることは出来ませんでした...。しかしながら、今までサーバサイドに関して理解があやふやであった部分が整理され、より体系的に理解出来た気がするので、大満足でした！

資料作成、成果発表では、文字通り成果発表用の資料を作成し、参加者1人ずつ発表していく流れでした。その後になんどKLab様から第3回KLab Server Side Campの修了証を頂きました...！ハンコ部分はこだわってデザインなされたそうで、嬉しかったです！

そして懇親会では、メンターの方々や他の参加者の方々と技術、またはその他の趣味について話し合う機会があり、素敵な時間を過ごすことが出来ました。特にメンターの方々には興味深い技術に関する話をたくさんしていただけたため、時間の経過が早かったです(笑)　その中でも、音楽ゲームの作り方、特にゲームエンジンらや判定部分、描画部分などの話も詳しくしていただけました...。元々「そういうことに関しても教えていただけたりしないかな...」と薄々考えていたため、非常にありがたかったです...。

ちなみに、この懇親会を通して、私の中に眠っていた「音楽ゲームを作りたい！」という気持ちが大きくなったため、現在Unityの本を既に買い、早速開発し始めています(笑)

現時点では私が遊べる用として開発していますが、もしもこの気持ちがより大きくなって私が作った音楽ゲームを配信することになりましたら、そのときは是非とも遊んでいただきたいです！

特に学びたい・押さえておきたいと感じたこと

・FastAPI

・SQLAlchemy Core

・pydantic

・Swagger UI

・テストの設け方について

・循環Importについて

・コード上の長い文字列の表示について

・SQLに格納出来るデータの容量制限について

・リファクタリングについて

・Makefileについて

・データベースの構成方法について

・ゲームエンジンについて

感想

率直に言いますと非常に楽しかったです！サーバサイドに関する知識も深まり、音楽ゲームの作り方も詳しく教えていただけたので、私にとって非常に濃い5日間となりました！

運営やメンターの方々、他の参加者の方々、そしてその他このインターンに関わった方々、本当にありがとうございました！

最後に

2022年9月14日現在、第4回KLab Server Side Campも行なわれることが決定しており、エントリー受付中です！

↓エントリーはコチラから！↓

https://klab-hr.snar.jp/jobboard/detail.aspx?id=MxhYoTHEWuM

日程:2022年12月26日(月)〜2023年1月6日(金) ※平日5日間

【2022年12月下旬】

1日目:12月26日(月)

2日目:12月27日(火)

3日目:12月28日(水)

【2023年1月上旬】

4日目:1月5日(木)

5日目:1月6日(金)

※第1次応募締切:10/3(月)まで

最後まで読んでいただきありがとうございました！ではまたいつか！

1年以上放置した競プロのモチベが完全復活した話

前書き

regiです。今回は「モチベーションが0になった経緯と、本題の1年以上競技プログラミングを放置した私が、どうしてそのモチベーションを完全に取り戻すことに至ったのかという経緯」を誰かに知ってもらいたくなったので、このような記事を書きました。また、この記事を書いたおおよそ1年前に主にTwitterで交流させていただいた方々に「競プロ復帰しました...！」ということを伝えたかったのもあります。

注意

この記事で読者が得られる有益な情報はほぼほぼ無いと思います。本当に私がポエムを書いているだけです。そのため、そういう目的でこの記事を開いてくれた方々にとってはあまりお力になれないと思います、申し訳ありません...。

モチベーションが0になった経緯

記憶が定かではない部分に関しましては、一応断定せずに「～だったのだと思います」などのように濁しています。

初めに、私自身が思う、私の競プロに対するモチベーションが0になってしまった本質的な理由を挙げますと、「精進を間違った方法でストイックにやりすぎたこと」です。

そもそも私は競プロというものを高校同期Aから教えてもらい、「よっしゃ！Aと同じくらいのレーティング目指したる！」という気持ちで始めました。当時のAは青コーダーだったため、必然的に私は青コーダーになることを長期的な目標としたわけです。そのため、私はAtCoderを初めたその日からいきなりABC-Dの水diff辺りに解説を参考にしながら挑戦するほどまでに、レーティングを伸ばしたいという意識が強かったです。そのようなチャレンジ精神溢れる精進をしていても、今の自分と比べて背伸びした問題を通せたときの喜びはいつだって計り知れないほど大きいものであり、私は競プロを楽しんでいたのだと思います。水コーダーになるまでは。

正直、今考え直してみますと、自分はもう水コーダーになってからはもう競プロを楽しめていなかったのではないかと思っています。なぜかと言うと、自力でACをすることに執着しすぎてしまったからです。そのため、分からない問題に1問でも当たったらその1問に3~4時間とか、最長でまるまる2日とか、普通に考えていたりしました。今考えると、自力ACにこだわって1つの問題に何時間も費やすのは明らか非効率ですし、体力も浪費してしまいます。少なくとも私自身には、このような精進方法は合わなかったのだと思います。もちろん自力でACすることにも意味はある面もあるとは考えていますが、そこは今回の記事では割愛させていただきます。このような間違った精進方法でストイックに競プロをやった結果、私は問題を開くことすら億劫になっていってしまうほど、以前のような競プロを楽しんでいた自分は死んでしまったのだろうと思います。

しかしながら「青コーダーになる」という目標により、私は泣きそうになりながら精進を続けていました。それほど「青コーダー」という称号は私を狂わせました。そして死にそうになるほど精進を重ね、2020年9月13日、私は無事に青コーダーになることができたのです。そうして長期的な目標が消えてしまったため、私の競プロにおけるモチベーションはほとんど無くなりました。頑張って「黄コーダーも目指すぞ！」と意気込んでもみたのですが、おそらく私の身体は全力で「嫌だ！！！！」と叫んでいたのだろうと思います。そういうふうに頭の中がいっぱいになっていたタイミングでレーティングが1645から1604になり、そこでとどめを刺されました。そこで完全にモチベーションが0になりました。本当に心が折れてしまいました。

1年以上競技プログラミングを放置した私が、どうしてそのモチベーションを完全に取り戻すことに至ったのかという経緯

初めに、私自身が思う、1年以上競技プログラミングを放置した私が、どうしてそのモチベーションを完全に取り戻すことに至った上で最も大きかった出来事を挙げますと、「AtCoderにUnrated参加機能が追加されたこと」です。

私は競プロをやらなくなってしまった頃、Twitterの競プロ用アカウントも次第に浮上しないようになり、ほぼほぼ競プロ界隈から姿を消したも同然でした。そうなってしまってはいたものの、私も「競プロなんて今の私にはもういらない！二度とやらない！」ときっぱり切り捨てていたわけではなく、むしろ、また純粋に競プロを楽しみたいと結構考えており、私はずっと「もう一度だけでもABCに出たい..！」と思っていました。しかしながら当時の私のレーティングは1604であり、おそらくパフォ1580辺り切った瞬間、「青コーダー」という称号が剥奪されてしまうため、非常に出るのが嫌でした。おそらくそれで水コーダーに落ちてしまったらモチベーションが0越えてマイナスになり、それこそもう二度と競プロのことを考えたくないとまで思ってしまうのではないかという懸念があったからです。そのようにならないためには、忘れてしまったテクニックやアルゴリズム、データ構造などの知識を取り戻した上で、億劫になっていた精進をどうしてもやる必要がありましたが、すっかり生活の中から競プロというものが消えてしまった私にとってはかなりハードルが高いものでした...。開発関連でTwitterの競プロ用アカウントに浮上した度にそのようなグダグダした考えを頭の中に巡らせていました。しかし、ある日当然、私はこの苦しみから解放されることになりました。AtCoderにUnrated参加機能が追加されたのです。

AtCoderのUnrated参加機能は、本来RatedのコンテストをUnratedとして参加できるという機能であり、本来はNoSub対策として追加された機能だと認識しております。(ちょくだいさん、間違っていたらすみません><) 実はこういった機能を妄想していて、「こんな機能があったら良いな～」とちょくちょく考えるほどであったため、実際にUnrated参加機能追加が発表されたときはかなり嬉しかったです...。もっと言うと、私の開発が落ち着いた翌々日に発表されたため、おそらくちょくだいさんが狙っていました。(絶体無い)

Unrated参加本当にありがとうございます……………………
AtCoder復帰します

— regi (@Re_code_A) December 1, 2021

そして、私は実に1年2ヶ月振りにAtCoderのコンテストに出ることが出来ました...。レーティングを気にすることなく。

ABC230でのパフォーマンスは1152であり、当然と言えば当然の結果となりました。しかしながら、私はコンテストをリアルタイムで参加したことで、「どのような問題が出るかというワクワク感」や「難しめの問題の解法が分かったときの達成感」、「コンテスト終了後のTLの賑わい」などといったことを思い出し、競プロの楽しさも思い出すことが出来ました。こうして、競プロを楽しんでいた自分は生き返ったのだと強く感じます。今思えば競プロを始めた頃の私も、コンテストをリアルタイムで参加することが楽しかったのだろうと思います。愚かなことに、私はそれをずっと忘れていました。ここで、私はこれからのコンテストを全てUnratedとしてでも参加していこう！と思えるほどに競プロのモチベーションが戻りました。

また、なぜかその週はABC、AGC、ARCと3日連続で開かれていて、最近のAtCoderを知らなかった私ですら驚きました。当然その週のAGCもARCもUnratedとして参加しました。その結果、AGCではパフォ1576、ARCでは1979と想像以上に良い結果となり、非常に驚きました。おそらく考察の仕方を思い出すことが出来たのだと思います。私はこれを受け、いち早く実際のコンテストでの立ち回り方の感覚を取り戻し、もっと様々な問題を解けるようにしたいと思い、バチャをしたいと考えました。そして、これは競プロというものを1年以上放置した競プロerの特権なのですが、なんとそのAtCoderで全問初見のコンテストバチャがし放題になります！(すみません、全問とは言いましたがA問題は許してください)

そのため私は、さっそく5日間に5回もバチャをしました。この時点でももう十分競プロのモチベーションが復活しています。おそらくこの2週間前の自分にこのことを伝えようとしてもまともに取り合ってくれないでしょう。この結果を見るに、現時点の実力でも青コーダーを維持することが出来そうだと感じられたため、かなり嬉しくなりました。

そして、昔とは精進方法を変え、現在ではバチャを中心として問題を解き、時間内に解けなかった問題はすぐ解法を見るようになりました。そうした結果、精進に対して億劫になっていた気持ちがすっかり消えたことに気付きました。おそらく私にはこのような精進方法が合っていたのだと思います。「実力をある程度戻すことができたこと」や「精進を楽しくすることが出来るようになったこと」を受け、私はふと、「このような状態になれた今の私であれば、黄コーダーを目指せるのではないか」と思うようになりました。

さらにこの直後で「競プロ忘年会2021」が開催され、私も参加させていただきました。競プロ関連のオンサイトイベントは初めての参加だったにもかかわらず、当時の私は競プロを1週間前に復帰した身であったため、数人と少し話して静かに帰宅することになってしまうのだろうなと感じていましたが、そんな私でも皆さんはとても親切にしてくださったため、とても楽しく、有意義な一日となりました。感謝してもしきれません...。そして、会場内やTwitterでも、私のことを覚えてくださった方々が居たという事実にも励まされました。本当に急遽参加して良かったです、今後のオンサイトイベントもなんとしても出たいと思います。本当にコロナ落ち着いて欲しいです...。そうして私の競プロのモチベーションは完全復活しました！

これからは

まあまあ考えて分からない問題はすぐ解法を見るということを徹底しつつ、心が競プロから離れてしまったら、その度にUnrated参加をして楽しさを思い出せたらと考えております。もしも読者の中に、心が競プロから離れてしまっている方が居ましたら、私のように精進方法などを見直してみたり、Unratedとして楽しむ目的でコンテストに参加してみたりするともしかしたら良いかと思います。そして、私の復帰を喜んでくださった方々、黄コーダーを応援してくださった方々、本当にありがとうございます...。卒業研究などがどの程度忙しくなるかが未だに分からず、そういった部分で不安が残りますが...2022年では黄コーダーを目指していきます！

まずは初めの一歩として、忘れてしまったことを取り戻しつつ、次回のABCでは1年2ヶ月振りにRatedとして参加してみようと考えています！頑張ります！

精進の振り返り【2020年9月号】

まえがき

regiです。唐突に、その月でどんな精進をしたのかを月末にまとめておいて、数ヶ月後辺りに自分で見返して「うわあ！」したいと思ったので、今月からそういう記事を書き始めます。また、秘密の精進ノートに書いてうふふするのも良かったのですが、どうせなら記事に書いておこうというノリで始めました。何かの間違いでだれかの役に立つかもしれないので...。

今月のAtCoderレーティング変化

2020/09/13   Rating 1546->1619

入青しました！下に入青記事のリンクを載せておきます。

regichan.hatenablog.com

2020/09/19   Rating 1619->1659

変なバグらせがいっぱい発生したけど、レート伸びて嬉しかった。

2020/09/20   Rating 1659->1666

UnionFindちゃんと最小費用流ちゃんにボコボコにされた。恋人の整数ちゃんは600点くれてよしよししてくれた。好き。(惚気話)

2020/09/26   Rating 1666->1645

最小費用流ちゃんと仲良くなりたくて、遅延セグ木ちゃんそっちのけで距離を縮めてたら、遅延セグ木ちゃんにボコボコにされた。

今月に作ったライブラリ

エラトステネスの篩を用いて素因数分解を高速に行うライブラリ

某ABCで犯罪を犯してしまったので、罪滅ぼしのために作りました。

フォード・ファルカーソン法

デニック法は気が向いたら作ります。

プライマルデュアル法

ポテンシャルを導入して、最短路をダイクストラで求められるようにしました。また、最初にベルマンフォードを回すことで、負のコスト辺も張れるようにもしました。ただし、負の閉路の対処はまだよく知らないため、それはこれから勉強して書き換えます。

区間更新・区間最小クエリの遅延評価セグメント木

非再帰にしたいです...。(小声)

抽象化もしたいです...。(小声)

区間加算・区間和クエリの遅延評価セグメント木

非再帰にしたいし、抽象化もしたいぜ。

木の重心を求めるライブラリ

こどふぉに出てきてびっくりしたから作りました。

LCS

一応作りました。

ベルマンフォード法

ベルマンフォードを再び回し、各ノードにおいて、最短路長を永遠に小さくできるようなノードであるか否かの判定をする機能もつけました。今後、ベルマンフォード法だけでなく、最短路を求めるアルゴリズムライブラリ全てに復元機能をつけておきたいですね。

今月に解けるようになった問題

フロー全般(最大流や最小カット、最小費用流、最大マッチング、最小点被覆など)

結構さまざまな問題見て解いたため、ある程度は感覚を掴めた気がしますが、まだまだできないので、さらに解いて学んで武器にしたいです。

有向グラフにおける最長路問題

有向グラフにおける最長路問題ってベルマンフォード法使うと解けるんですね、びっくりしました。その実装は以下の問題で練習することができます。皆さんも是非とも。

https://atcoder.jp/contests/abc061/tasks/abc061_d

FFTやSCC、2-SATなど、ACLで取り上げられているアルゴリズムを使う問題

易しめなら解けます...。

遅延評価セグメント木を使う問題

私が持っているライブラリで「「何とかなる問題」」なら「「ある程度」」解けます。

来月に頑張りたいこと

フロー全般

これは継続して勉強していきます。特に、アルゴリズムの正当性の証明と、最小費用流における負の閉路の対処、フローに帰着させることができる問題において使える考察パターンについてきちんと押さえたいですね。

セグメント木と遅延セグメント木の非再帰での書き方と、抽象化

特に抽象化はきちんと勉強したいです。セグ木に殴られる人から、セグ木で殴る人になりたいです。

全方位木DPの抽象化

どこかの記事によるとこれも抽象化できるらしい...？なのでやります。

SCCや2-SAT、FFTにおいて使える考察パターンを身につける

まだあまり問題を解くことができていないので、問題を良く解いて、良い考察パターンを身につけていきたいですね。

ダブリング

最近、ABCでよく話題になっているため、流石にやります。

行列におけるrankを使う問題

現時点では自分にとって得体の知れない問題なので、解けるようになっておきたいです。

グラフ問題についての情報収集

グラフにやられっぱなしなので、本当に舐め回すようにさまざまな情報やテクニック、考え方を集めたいです。

EDPC

まだA～Eしかやってなくてごめんなさい...。

包除原理を用いた数え上げ

流石にやります。

その他

ライブラリ整備とかいろいろ。

あとがき

並べてみると、頑張るべきことがかなり多いですね。さらには大学も再開して、その上、開発の勉強も頑張りたいため、上手いこと回せるかかなり心配です。まあ、無理をせずコツコツ焦らずにやっていきたいと思います。

最後に一言...冒頭の私、今の私とは別人でびっくりしました。

ABC178-F Contrastの別解

まえがき

regiです。今回はABC178-F Contrastの別解、つまりは私がコンテスト中にどういう解法を用いたかを紹介します。この解法の正当性は時間が取れたら書き足します。

その解法

本問のサンプル1と、説明するのに都合の良い自前のサンプル2つの、計3つのサンプルを例に紹介します。

まずはサンプル1です。

これですね。最初に、A[i]=B[i]を満たす箇所において、A[i]とB[i]に色を塗ります。ここで、数字によって塗る色を変えておきます。そうすると以下のようになります。

この場合はどこもA[i]=B[i]を満たすので、全て何かしらの色で塗られました。

次に、色が塗られているかつ、その色が異なるB[i],B[j]のペアを適当に選び、スワップしていきます。

このとき、必ずA[i]≠B[i], A[j]≠B[j]となるため、A[i],A[j],B[i],B[j]の色を消します。

このスワップを、A[i]やB[i]を塗るために用いられている色の種類数が1種類以下になるまで行います。今は3種類あるので、まだスワップを続けます。なお、種類数が2種類以上である限り、必ずスワップを行うことができるので、どのようなA,Bにおいても、この操作で色の種類数を必ず1種類以下にすることができます。

スワップを行い続けると以下のようになります。

無事に色の1種類以下になったので、ここで操作を終了します。なお、今回のサンプルのように、この操作終了時に色の種類数が0種類になった場合は、この時点で題意を満たすBを得ることができたということなので、これで終了です。

次に以下のようなサンプルを考えます。

これも、塗ります。そうすると以下のようになります。

次に、A[i]やB[i]を塗るために用いられている色の種類数が1種類以下になるまでスワップする操作を行います。そうすると以下のようになります。

色の種類数が1種類以下になりましたが、今回のサンプルでは1種類残りました。

次に、色が塗られているb[i]と、a[j]≠b[i]かつb[j]≠b[i]を満たすjにおけるb[j]を適当に選び、スワップしていきます。

このとき、必ずA[i]≠B[i], A[j]≠B[j]となるため、A[i],スワップ前のB[i]の色を消します。

このスワップは、行うことができなくなるまで繰り返し行います。そうすると以下のようになります。

今回の場合、色の種類数が0種類になったことでスワップを行うことができなくなったため、得られたBは題意を満たします。

最後に以下のようなサンプルを考えます。

 色塗り。

最初のスワップ操作

色の種類数が1種類以下になりました。

次のスワップ操作。

今回の場合、まだ色の塗られているA[i],B[i]が存在しているにも関わらず、スワップを行うことができなくなったため、題意を満たすBは得られません。

チャートにするとこのような流れです。

実際にコンテスト中に(可読性は期待しないでください)この解法を用いてACを取った私のコードです。↓↓

https://atcoder.jp/contests/abc178/submissions/16712437

あとがき

ある程度書けたらとりあえず公開するのと、きちんと書くまで公開しないの、どちらの方が良いのでしょうか。とてもどうでもよいことだが、好きな問題を語るだけの自己満足記事、書きたさある。

AtCoderで青コーダーに...なれた...

regiです。まずTwitterでは迷惑になるのでここで叫ばせてください。

ああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああやったーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーうわうわうわうわうわうわうわうわうわうわうわうわうわほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほ

失礼しました。この記事では色変記事で必要不可欠そうなもの(解いた問題数や学んだアルゴリズム・データ構造等)を書き、その後で水コーダーから青コーダーになるまでのおおまかな軌跡(大体ふざけてるので注意してください)や、これからのこと(真面目)を書きました。精進法などは前回の色変記事にまとめたので、それを見たい方はこちらをクリック。

regichan.hatenablog.com

 水コーダーの頃に解いた問題数

まずは水コーダーなりたての頃と青コーダーなりたての頃とでのAtCoderのAC数を比較してみましょう。

水コーダーなりたての頃　↓

青コーダーなりたての頃　↓

こう見てみるといっぱいやりましたね。(otherはJOI埋めをやってたら増えました)

水コーダーの頃に学んだアルゴリズムとデータ構造

 水コーダーの頃は以下のようなものを学びました。ここでは、学んだ=仕組みを理解して自分でライブラリを作ったと定義しています。(そうしないとACLの扱いに困るため)

• 2^61を用いたローリングハッシュ
• 複素数を用いたFFT
• NTTを用いたFFT
• modint
• エラトステネスの篩(は？)
• LCS
• 遅延評価セグメント木
• 拡張ユークリッドの互除法
• 原始根を求めるアルゴリズム
• BIT(フェニック木)
• 重心分解

 ちょっと一つだけ「え、この時期に...？」というものが混じっていますがあまりお気になさらずに。

これはあまり関係ない事ですが、ちゃんとしたライブラリを書くため、また、強い人のコードを理解するために独習を買いました。気合い入ってる、偉い。

あと、独習買ったら今後役立つことあるかなあ、なんちゃってとも思った。(ただ、ACLでしばしば用いられる高速化はこの本ではあまり載っていなかったので泣いています。ACLのコードむずすぎ案件)

水コーダーから青コーダーになるまで

ここからは昔話のお時間です。私は水コーダーになった後も精進をし続けました。青コーダーになるために。そのためには、私はどうしてもボトルネックになっているなあ...と感じていた早解きを習得する必要がありました。これは水コーダーになる前からもやっていたことですが、今まで解いた中で橙diffや赤diff、金diffでない問題はほぼ全て、問題を見てからACするまでの時間を測って解いたと思います。Twitterにも解いた問題を貼るときは決まってその時間も添えていました。以下のように。

 見栄っ張りなのでかなりうまくいったものも貼る！！！

提出 #16562667 - AtCoder Regular Contest 050 https://t.co/NokQqClSYF
(diff 2328) 17分
解法の正当性を完全に示してから一発でバグがないコード書いて一発でAC、気持ちいい

— regi (@Re_code_A) 2020年9月7日

 また、この問題かなり面白かったのでおすすめです。少し脱線しましたが、このような精進を重ねたことで、着々と早解きできるようになりました。(最終的に、ABC178でお気に入り内の青コーダーの方の誰よりも早くA～Eを通せるようにまでなったので結構嬉しかったです←)

ただ、青コーダーの神様はそう簡単に私を青コーダーにはしてくれなかったんです...。

災難１. 些細なうろ覚えでM-SOLUTIONSプロコンオープン2020にて入青を逃す

このコンテストでの私の提出一覧です。

コンテスト前のレーティングが1549だったため、もしFがコンテスト中に通っていれば黄パフォが出て入青でしたが、WAが出て敗北。(MLEってそんな出ないけど、いざ出たら笑っちゃうのありがち)　それからメモリをやりくりしてもサンプルと出力が合わず、椅子を温めるtouristとなっていたわけです。このサンプルと出力が合わなかったわけ、今でも笑ってしまいます。私はstd::setのイテレータ操作をうろ覚えのままにしたために、そのイテレータ操作がうまくできなかっただけでした。問題のコードがこちら。(これだとイテレータ操作できません)

この後ちゃんと前置に直したらAC出ました、競プロは面白いですね。C++言語ちゃんをもっと戯れてあげるべきだったと思っています...。

災難２. 寸　　止　　め　　笑

文字通りです。以下の画像がそれ。

コンテスト終了10分前、AtCoder垢10,000個くらい作って全垢でABC参加したら相対的にパフォ上がるかなあと思いましたが、良い子なのでそんなことしませんでした。

災難３. やはりAGCは苦手だ

レーティング1597になってからの次のコンテスト、それはAGCでした。私はAGCかなり苦手で、そんな状況をどうにかしようと思い、AGCまでの1週間とてつもなく頑張ったわけです。毎日黄diffや橙diff、赤diffに立ち向かって考察し抜く力をその1週間で付けようとしました。PCの前に座っているときはもちろん、食事をしているときも風呂に入っているときも照明を消して布団に入った後も、しつこく考えていました。ねちねちねちねちと。その結果、暖色diffの自力ACは結構増え、考察力はかなり付いたと実感していました。しかし、AGCはそこまで甘くなかったわけで...実際に出た問題はロリハやらFFTやら、私が使ったことのなかったようなアルゴリズムを必要とする問題が多かったため、解けた問題数は「「 0 」」でした。私自身がやってきたことは、このAGCでは完全に無駄だったというわけです。ここだけの話、NoSubはギリギリまで考えていましたが、もし通れば青ということを考えてしまうと心臓が高鳴り、冷や汗も出てくる出てくる。こうなるともはや自分では冷静な判断を下せなくなり、とうとう投げてしまいました。非ロリハの劇遅コード。それは数秒でTLEを吐き、その瞬間、1ヶ月も続いた地獄に落とされました。カイジもこんな感じだったんですかね？(は？)

それからどうやって立ち直ったのか

そのAGCで、1597あったレーティングは1541になりました！！！！！

青パフォを2回も取ってくれた過去の私の努力を水の泡にしました。そう思ったら流石にかなりメンタルをやられてしまいました。その頃は多くの期末レポートにも追われていて踏んだり蹴ったりでした。私はしばらく競プロのことを考えたくなかったし、期末レポートを始末しないといけなかったので、1週間失踪しました。その間はもう期末レポートとにらめっこする日々。おかしくなりそうだったので、お菓子やアイスを買い溜めするようになりました。人間、やはり美食を求めるのは最大のメンタル回復手段の一つ、異論は...一応認める。そう、さまざまなコンビニやスーパーを転々として、私自身の知らなかったお菓子を探す旅に出ていました。あ、別に私は美食殿のギルドメンバーではないです。本当に素敵な子達と出会えましたよ、これは普通に今後も趣味にしていきたいと思う。その中でも特に愛らしかった子...それはmeijiのチョコミントアイスパフェ...。実は今までチョコミントはこの人生であまり食べたことが無かったが、本当に運命の出会いだった。ミントがしつこくない上にチョコがミントを殺していない...それに食べやすい量であった。何より見た目が可愛い、全人類ググってその姿を目に焼き付けろ。それだけではなく私はチョコミントの虜になってしまい、今ではアイスの主流フレーバーの中では2番目に好きですね。(ちなみに1番は抹茶で、あれは抹茶が強すぎるんだよ仕方ない...チョコミントは悪くない...)　そんなわけで、今まで買ったことのなかった会社のチョコミントアイスも結構買いました。アオイちゃんの気持ちが分かった気がしますね。もしもチョコミントに詳しい方いらしたらオススメのチョコミントアイス教えてくださいお願いします。

ここで皆さん忘れているとは思いますが、これは食レポ記事ではなく色変記事です。何が言いたかったかというと、やはりメンタルを壊してしまったらすぐ逃げて他のことに打ち込むというのは最強でした。蜂の巣状態になっていたメンタルはこれでおおよそ回復しました。

災難４. 無精進って怖いよ

 メンタル回復！良かったあ！で終わると思った？何か忘れてない？私は1週間精進をしていないということに。

「ABCって...あると出たくなっちゃいますよね...。」

そういって私はコーナーケースにハマって1541あったレーティングを1505にまで減らしました！！！！！

完全に競プロの勘が鈍っていましたとしか言えません。その回ではDPの問題もありましたが、DPは得意寄りのはずなのにコンテスト中に解法を思いつくことができませんでした。後日やったら普通に一瞬で解法分かりました、はい。無精進って怖いよ。競プロは1日休んだら3日分下手になると思った方が良い気がしました。当然メンタルまたダメになってしまった。あ、でも期末レポート終わった分、AGC事件と比べたらまだ傷は浅く、なんとか致命傷で済んだかなという感じでした。

それからどうやって立ち直ったのか②

いつも通り、まだ知らないお菓子やアイスを探す旅に出かけていましたが、この時期に私はなぜかHUGっと!プリキュアを観始めました。理由はよく分かりませんが、人間はメンタルが壊れると幼児退行してしまうのかもしれません。しかしまあこのアニメ、小さい女の子が観るアニメとしてはえげつないことしてたり、なかなか話が重めでびっくりしました。ルールー・アムールというキャラに感情移入しすぎてしまってとても泣いてしまいました。(どうでもいいけど、声優が田村ゆかりさんでびっくりしました。10年以上前の作品である「ひぐらしのなく頃に」の古手梨花のイメージが強かったため。また、ルールー・アムールについてはネタバレが怖いのでこれ以上の言及は避けます)　また後半では、悪役だった人たちがプリキュアたちと楽しくワイワイしているので、そこに萌えを感じました。その中でもチャラリートはキャラとして結構好きです。思い切り余談ですが、この作品ではプリキュア史上初めての男の子のプリキュア(キュアゴリラ除く)が誕生したことでも有名らしいですね。当時はTwitterでもトレンドになってて何事？と思ったのを今でも覚えていて、実際そのシーンをこの目で観たときは感動しました。

ここで皆さん忘れているとは思いますが、これはアニメのレビュー記事ではなく色変記事です。何が言いたかったかというと、この作品では溢れるほどの元気と勇気をもらいました。多くのキャラから自分を貫く大切さ、夢を追いかける素晴らしさを教えられたことで、私もなんだかんだ言って青コーダーになりたい！という熱意、信念を取り戻すことができました。今では、前に進めずにいた自分を勝利の女神がこの作品を勧めてくれた、だから観始めることになったのかなとさえ思えてしまいます。メンタルが壊れているときは、この作品だけでなく、そのような大切なものを教えてくれるような作品を観るということで、大きくメンタル回復することができるでしょう。

災難５. 数分差でABC177にて入青を逃す

正直これは比較的そこまで災難ではないですが、以下がこのコンテストでの私の提出一覧です。

 コンテスト前のレーティングが1505だったため、もしFがコンテスト中に通っていれば2200以上のパフォが出て入青だったのだが......。(Eの実行時間見るな見るな見るな見るな見るな、後日正しい解法学んでそれで通したので許してください。。。)　それにしても2分差で2200以上のパフォ逃すって...一体どれだけ不運(というよりかは実力不足なだけだが)に見舞われないといけないんでしょうか。とはいうもの、Eまでの早解きでレーティングは1505から1546になり、黄パフォを取れば即入青という状況にやっと戻れたわけです。

これは全く関係無いことですが、実はABC177-Fは普通の遅延評価機能が無いセグメント木でも十分高速に解くことができます。実際私もそのように通しました。需要があるのであれば、その解法を紹介する記事を書くか検討しますがどうでしょうか？コメントやリプ等よろしくお願いします。

有終の美

長かった地獄のような日々も、2020年9月13日、その日に終わりを迎えました。それはABC178が開催された日。そのコンテストでの出来事について書きます。

そのコンテストでは、まずA～Eの早解きにかなり成功しました。A～Dはともかく、Eは見てすぐに解法が分かり、その問題を見てから解法の正当性の証明、実装完了、ACまでの流れを5分で終わらせることができたのが大きかったです。それは、数々の精進の中で自分なりに確立していった考察パターンをうまく引き出せたからだと感じました。しかし、Fが壁でした...それは貪欲じみた問題だったからです。私は競プロを始めてから今までずっと、貪欲が大の苦手でした。なぜかというと証明が難しいからです。私は「基本的」には解法の正当性を示す、あるいは証明してからコードを提出するというスタンスで競プロを続けてきました。(グラフ問題も証明が難しいので苦手です)　順位表を見たとき、このFを通さないと間違いなくこのコンテストではまた青コーダーになれないということが明らかでした。とはいえ貪欲を目にした以上、もう私の目の輝きはほぼほぼ消えていたと思います。しかし、やはりどうしても諦めたくなかった、その栄光を時間いっぱいまで追いかけて追いかけて掴みたかった、そういう思いが込み上げてきました。私は最後の最後まで諦めませんでした。今まで貪欲ではどういう手法がありがちだったかを必死に思い出して考えてみました。そしたら思いついてしまった、そのFで使える手法を...そしてある程度の正当性を示すことができましたが、まだ完全に示し切ることはできませんでした...。そのときはとりあえず無我夢中でコードを書き殴り、それを提出した結果...。

......通った───────────────────────────────────。

「AC」という輝かしい表示を見た瞬間、泣いてしまいました。その後はコンテスト終わるまで、ずっとTwitterでてんやわんやしていました。それで、しばらくしてFの解法の正当性をきちんと示すことができてしまい、またてんやわんやしました。まさかあれだけ苦手だった貪欲の問題を通して、なおかつ解法を示して、もっと言えばそこまで得意ではないセットにて全問の解法の正当性を示し、それで全完してゴールをすることができたと考えたら、今までで一番実力を出し切ることができたし、本当にちゃんと精進してきて良かったと思えました。この上ない、最高の青コーダーのなり方だったと強く思っています。

ちなみにFでstd::setのイテレータ操作をしたのですが、一発で書けたため、それもなかなかに嬉しかったです。私はコンテスト終了10分前からは宴がてら、例のmeijiのチョコミントアイスパフェを食べ始めました。しかし残念なことに、その頃からそのmeijiのチョコミントアイスパフェは行きつけの店から消えていました...このとき食べていたそれが最後だったのです。もしかすると、このアイスは私が立ち直れるようにするために私を虜にしたが、その役割を終えたために私の前から姿を消してしまったのではないか...というようなメルヘンチックなことさえふと考えてしまうほど、今の気持ちはとても晴れやかだった...。でも、やはりそのアイスを失ったことは辛いので、またそのアイスが並んでいる店を探したいと思っています...。

そしてコンテストは終了しました。そして私のレーティングは...？ドン！

はい、この日から私も青コーダーです！！！！！！！入青ツイートにリプ,いいねくださった多くの方々ありがとうございました...！青コーダーになることは競プロを本気でやり始めた頃の夢だったので、最高の気分です。

これからのこと

競プロを本気でやり始めた頃に掲げた夢は叶えることができました。しかし、競プロをやるにつれ、私にはまたひとつ大きな夢ができました。それは黄コーダーになることです。もちろん、今まで以上の難解な問題やアルゴリズム、データ構造と向き合うことになるでしょうし、AGCが苦手などと言っていられる場合ではなくなってきてしまうのでしょうが、今はやれるだけやりたいと思っています。応援よろしくお願いします...！ある方も言っていましたが、やはりみんなで黄コーダーになりたいですね。(当時は緑コーダーだった私含むさまざまな人が今では全員青コーダーになりました。本当に皆成長しました。そう考えると目頭が熱くなってきます。)

また、これを機にWeb開発等にも本格的に挑戦していきたいと思っています。「おいおい、黄コーダーも狙うんだろ？大丈夫？」と思った方々、安心してください、私も両立できるか分かりません！！しかし、これは青コーダーになったらやろうと前々から決めていたことなので、時間がかかろうとも並行して頑張っていきたいと思っています！開発に強い方々、私が困っているときはいろいろ質問するかもしれませんが、そのときはよろしくお願いします...（；；）

あとがき

とてもどうでもいいが、あらゆる言葉の意味をうろ覚えしているため、辞書が無いと記事書けないがち。早くこの記事を読んで欲しいので、推敲する前に流しておきます。急いで書いている部分もあるので、意味分からない文章や構成もあるかもしれません、ごめんなさい。また、気分でエピソード追加するかもしれません。そのときはそのときのお楽しみです。

私自身でも見返してて本当に意味の分からない記事ができてしまったのですが、ここまで読んでくださった方々、本当にありがとうございました！