でるよー。応援してね～！
Maximumから4名がチーム「Maximum」で出場します！ ぜひ応援よろしくお願いします！ #uteone
この度、 ウルシステムズ株式会社さん 主催の 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 します。
ここで問題点が。 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 位になりました。
うっひょ～～～～～～！ なかなかいいスコアです。
ベンチをまわしてみると、ログにどこで落ちたかが出てくることに気づき、ここを重点的に直す方向にシフトします。
バグ摘発班の 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 を直そうと試みますが、うまくいかず、終了。。。
結果
参加チームが 32 チームで、22 位でした。
まあこういった大会をしたことがなかったので、まあそれなりにいい結果だと思います。
やっぱり上位勢、やばい。
少なくとも自分一人だけではこの結果は出せなかったと思います。
チームメイトに感謝。
実は本番前に SQL やら Go やらのパフォーマンスチューニングをメインで練習していたんですが、想定以上に直すべきバグが多く、その段階にたどりつけずに終わってしまいました。。
でも、バグ直しもパフォーマンスチューニングもそれなりに勉強になりました。
今後機会があれば、いろいろな大会に出てみたいと思います。
まとめ
「「一つのことに囚われすぎてはいけない！！！！！」」