OKリーグのライブスコア観戦システムを作ったということ。でも想定外が多すぎる。

サムネは運営宿で頂いた夕食。
非常に美味しかったです。

悔しかったので…

この記事を覚えているだろうか。

https://note.mu/akarisan_o/n/n4d0677062ca9

1年前、クラブカップミドルで演出用のシステムを開発したときに動かなかったことを報告したものだ。

その時はサラッとしていた感じではあったが、内心結構悔しかった。
あんだけ力入れて作ったのに動かなかった理由が「チーム名にタブスペースが入っていた」というクソクソなものだったからだ。

それから1年後、全日本ロング大会でその悔しさをぶつけた。

C-Scoreを改良

OK-Infoさんが主催している「OKリーグ」で全日本ミドル・ロングが対象大会となり、またそれに伴い特別ルールが採用された。

NishiPROから、1年前に開発をしてそのまま放置していた「C-Score」を改良して、OKリーグ用のスコア集計システムを作れないかと打診を受け、ソースコードを洗い出した。

これがまた酷いもので、SQLインジェクション対策は全くしていない＆動作に全く関係のない部分がある等、ガバガバであった。
(ぶっちゃけ大したデータはないのでセキュリティ面は後回しにしていた)

とりあえず初めにSQLインジェクション対策をした。

参加した全チームを対象にするとのことだったので、いろいろとコードを削れた。
ただC-Scoreの仕様が邪魔をして、同着処理と複数所属への対応の2つは二律背反で、同時に動作させることは出来なかった。

ロング競技なので、同タイムであることは稀である(特に入賞圏内には影響がないはずだ)と考え、同着処理は目を瞑ることにした。

ひとまず完成し、テストデータでの動作確認はしたがそれ以外はぶっつけ本番。

大会が始まり、最初の所属ありの選手が帰ってきた時にすぐサイトを確認したら、
見事に動いてくれていた。

感動の一言だった。

ただ想定外が多すぎた

台風の影響でミドルは中止、ロングも直前まで判断を迫られており、交通もダメ。

参加者が大幅に減ったことで、スコアルールが想定したものより格段に違うものとなった。

仕様の関係で、DBにはエントリーリスト時点でのスコアルールを採用していたが、大会翌日に算出したものでは大幅にスコアルールの変更があった。
(クラスの出走人数に応じて、対象得点者数・得点が変わるというものだった)

入賞チームに変わりはなかったが、順位はゴロゴロと入れ替わった。

ここは改善が必要だと感じた。

また参加点もシステム上では計数しなかった。入賞チームであれば、最大値の8人以上の参加が見込まれると判断したからだ。
予想通り、ここはあまり影響しなかった。

改善したいところ

①参加点の計数は出来たはず。次やる時は計数もシステムに含めたい。

②所属表記の揺れが結構あった。ここは主催者側に稼働前までにデータの修正を求めたい。

③今回のようにスコアルールが出走者数に応じて変更できるように、DBと加点関数を修正したい。出走者数に応じて動的な変更がない場合は、変更条件を1000人以上の出走とかにすれば問題ないはずだ。
ただ仕様上、フィニッシュした選手のみしか計数出来ないため、改善が難しいところでもある。

④同時にデータが送信されると送信エラーが起きることがあるので、サーバ側で受信間隔を制限したい。これは実現可能。

⑤差分データだけ送信できるようにしたい。データ通信量も少なくできる。ただMulka2側に不具合があったりすると、そもそも動かなくなるので、今のところは全データ送信が望ましい。

一言

完璧を実現することの難しさを知った。