UTE-1 参加記

participation logcompetitive programming

作成日 / 最終更新日

Table of Contents

Loading...

この度、 ウルシステムズ株式会社さん (新しいタブで開く) 主催の UTE-1 (新しいタブで開く) に参加させていただきました!
参加記です。

参加まで

私が代表をしている プログラミングサークル Maximum (新しいタブで開く) に、ウルシステムズさんから招待が来ました。

初めまして。 ウルシステムズ株式会社と申します。突然のご連絡失礼いたします。
この度弊社主催で学生さんを対象とした技術コンテスト「UTE-1(ULTRA TAMAGO ENGINEER No.1:ウテワン)」を開催させていただきます。
つきましては、Maximum の方々にもぜひご参加を検討いただきたく、ご連絡しました。
(以下略)

そして Maximum では 2022 年度後期から「Web 研」を立ち上げました。
これは参加するしかないでしょ!ということで参加しました。

(実は AtCoder の生放送「あーだこーだー」で触れられていたようなのですが、ながら聞きしてました (← 競プロ er とは思えない発言))

当日まで

メンバー募集

まず上のメッセージをサークル内に共有します。
それだけだとさすがに (広告用のチャンネルを見てる人は少ないのか) 集まらないので、声をかけていきます。

最終的には以下のメンバーで参加しました。

(sorachi 視点の記事: https://zenn.dev/monica/articles/117a84653f69a7 (新しいタブで開く))

練習

後期期末試験が終わってから、毎晩練習をしていました。
ISUCON の過去問をメインに行いました。
https://github.com/a01sa01to/isucon-practice-001 (新しいタブで開く)

前日は ISUCON-11 の予選問題を並走して解きました。
準備万端です。

本番

開会式を終え、いざスタート!
まず私と sorachi はコードを眺めながら修正していく係、kasa と through は仕様書を読んでバグを見つける係です。

リポジトリも公開され、まずコードを落としてきて読みます。
前もって作っておいた Issue template を Push します。

作ったIssue Template
作ったIssue Template

ここで問題点が。 Dev Container が動かない!! こまった 😥
いくら Retry しても直る気配がないので、とりあえず Docker Compose で動かします。

Docker Compose でとにかく時間がかかる (10 分くらい) ようなので、とりあえずデプロイしておきたいな~と思い、デプロイのドキュメントを読んでみると、GCP の k8s を使うようです。
しかし GCP からの招待通知が全然来ないので Slack を見てみます。
ほかの人も同様の状況で、スレッドが立っていたので見てみます。

ポータルサイトで登録いただいた gmail のメールアドレスで、プロジェクトに ○○ さんの権限は付与されています。例えば、ブラウザのシークレットモードで ○○ さんのプロジェクト(こちら)へアクセスし、登録いただいたメールアドレスでログインして試してみてもらえますでしょうか。

ということはまあ全員権限付与されてそうだなぁ。
とりあえず Slack 内に共有されていたリンクを踏みます。
まあチーム名が違うのでアクセスはできないので、クエリパラメータを変更します。
アクセスできた~~!! Google さん、通知来てくれてもいいのに...

ということで回せる状況になったので、初期ベンチを回します。257 です。
まあ全チームこの値になっていたので、想定していましたが。
すでに 1 時間が経過してしまいました。

Issue を見ます。7 件くらいあります。いい感じ。
Self-Assign して、修正していきます。

ここで sorachi がログインのエラーを直してくれたので、動くことを確認して、ベンチを回してみます。
12:30 で 2,253 です。5 位になりました。
うっひょ~~~~~~! なかなかいいスコアです。

5位!
5位!

ベンチをまわしてみると、ログにどこで落ちたかが出てくることに気づき、ここを重点的に直す方向にシフトします。
バグ摘発班の kasa と through も、修正に回ります。
とりあえず Issue を立てます。

さて、その後もいろいろ試してみます。
とにかくベンチを回しまくり、エラーを直していきます。

自分の担当では、 Got a packet bigger than 'max_allowed_packet' bytes と出てくるのが直りません。
とりあえず、仕様書とルールを見ます。
「ん、これ、設定変更するの許されてるっぽい??」
ということで my.cnf を確認します。
最小値に設定されてるっぽいので、デフォルト値にします。

さすがにこれで Got a packet bigger than 'max_allowed_packet' bytes は直るだろ~と思い、ベンチを回します。
まだ直っていません。が、減っているように見えます。

もう一度デフォルトを見ます。16MB っぽいです。
64MB にしてデプロイしてみます。
直らず。。。
とりあえず後回しにします。


ここでもぐもぐタイムに入ります。


さて、もぐもぐタイムが終わったところで、一人でやってると思考ロックされちゃうので sorachi と担当を交代します。

register で問題がありそうです。
400 が返ってきてほしいのに、200 が返ってきてるみたい。
ぱっと見た感じ、いい感じなのでコーナーケースを疑います。
とりあえず、ログを見ます。
うーん。。。

とにかく椅子を温める時間です。

ログを見てみます。
なんか [email protected] とかいうとにかく長いメールアドレスで試行しているように見えます。
Wikipedia を見てみると、local-parts (@ の前の部分) は 64 文字までらしいです。
仕様書では RFC5322 と書いてあります。でも RFC5321 の話。

試しに「local-parts が 65 文字以上の場合はエラーを返す」を実装してみると、通りました。3,023 点です。

コラ~! (伏線回収)
このせいで 6 時間半の競技時間のうち 3 時間 も無駄になってしまいました~!
さすがの Asa も Clar を投げて行ってしまいました~!

競技内容にかかわることなので答えられないとのこと。
コラ~~~!!!
(※ネタです。丁寧に対応してくださった事務局の方、ありがとうございました)

さっきの Got a packet bigger than 'max_allowed_packet' bytes を直そうと試みますが、うまくいかず、終了。。。

結果

22位
22位

参加チームが 32 チームで、22 位でした。
まあこういった大会をしたことがなかったので、まあそれなりにいい結果だと思います。
やっぱり上位勢、やばい。

少なくとも自分一人だけではこの結果は出せなかったと思います。
チームメイトに感謝。

実は本番前に SQL やら Go やらのパフォーマンスチューニングをメインで練習していたんですが、想定以上に直すべきバグが多く、その段階にたどりつけずに終わってしまいました。。
でも、バグ直しもパフォーマンスチューニングもそれなりに勉強になりました。
今後機会があれば、いろいろな大会に出てみたいと思います。

まとめ
「「一つのことに囚われすぎてはいけない!!!!!」」