見出し画像

高専祭の入場管理システムをつくってた話と振り返り(2022年高専祭web班)

ばやし

これは鈴鹿高専アドベントカレンダー2022の17日目の記事です。

概要

　鈴鹿高専の高専祭でコロナウィルスの感染拡大防止のために入場管理システムを作成したので、半年間を反省しながら振り返っていこうと思います。HP側もも面白い話が結構あるんですけど自分の担当箇所じゃないので、その話は担当した友達に任せます。

振り返り

4月〜５月

　おもしろそうや〜ん的なノリで高専祭実行委員のweb班に入る。ちらほら入場管理をする必要がある的な話が出てきてそれをweb班がやる流れになる。
このときは来場者向けにLINE botとか作ってステージイベントとかの投票とかやりやすくしたらいいんじゃね的な話が出てた。結局やらんかったけど。

　今考えたらweb班に自分がノリで入らんかったら実働できる人数が二人だったので相当やばかった気がする。

6月〜7月

　入場管理システムの構想を練り始める。最初は学校から個人情報を頂いて入場管理をしようとしたが、学校から提供される変わりに提示された個人情報の取り扱い規約（例としては、情報が入ったパソコンを校内ネットワーク以外につなげてはいけないとか）が厳しすぎてシステム構築が迷走する。招待する人の情報入力フォームを自作するとかの話も出たけど認証周りがめんどくさいとかで結局なしになるとかいろいろ構想をねった時期な気がする。

夏休み

　入場管理システムにされる要求の定義がweb班におりてこず、構想も建てられなかったので夏休みスタート〜９月中旬までは何もしてなかった。もっと焦るべきだった。9月20日にやっと要件が決まったので作りはじめた。すでに不穏である。

下の写真が最初のシステム構想。でも最終的にGCP上でCloudRun+CloudSQL+CloudBuildを簡単に整えたシステムになった。

最初の簡単な構想図

　ちなみに夏休み期間はHP側が期限に追われててつらそうだった。その間自分ははSteamで安くなってたMHW:IBしてたりスプラ3やってた。おもしろかったです。

夏休み終わり〜高専祭一週間前くらい

　この期間が一番つらかった。学校行く余裕なかったので2週間くらいの間は出席日数に余裕がある授業は行かずに寮でプログラム書いてた。生き地獄やったでホンマ。だって俺、入場管理しか作らんと思ってたもん。高専祭のHP上で表示されるステージイベントのスケジュールとかバザーの情報を管理するAPIサーバーも並行して書くとか知らんかったもん。
あと実際に運用するサービスという関係上、本番でエラーが落ちるようなことがあってはいけないので結構念入りに作る必要があったのもしんどかった。

　結局すべてのつらかった要因は開発期間で、夏休み終わりから高専祭までだいたい4週間くらいしかなく、1週間が研修旅行で北海道行って潰れたので、実質3週間で作り切る必要があった。北海道の魚とラーメンはうまかったです。

ざっと数えてみたらこの期間中に6500行くらいコード書いてたらしい。

高専祭一週間前～高専祭当日まで

　高専祭一週間前にシステムは一通り作り終わってあとは楽な作業や！とか思ってたらメール送信で躓いた。
　まず1000人以上に送る必要があり、手作業で送っていたら日が暮れるのでプログラムを組んで送信した。そこまでは良かったのだが、まず使ってるメーラーによって表示が変わる不具合があり、入場の際に使うQRコードの画像がメールにはられてないことがあったので頑張って直した。
　これでGmailとicloudの標準メールアプリで動作確認できたし送れるやろ！とかおもって送ったらdocomoやsoftbankのキャリアメールでQRコードの画像が表示されない不具合があって前日の夜に直した。

　結局なんやかんやあって、人によっては3回とか4回送られてきた人もいるだろうからその人達には申し訳ないです。

　ただ元からformに入力したメールアドレスが違うとか、そういう感じのこっち側に責任がない人は知らん。50人くらい手作業で対処した気がする。結構めんどくさいねんでアレ。

高専祭当日

　高専祭までは激動の4週間だった。頻繁に要件が変わり、データベースの構造も変更を繰り返して最終的にversion 15になり、北海道で食べた寿司がめちゃくちゃ美味く、徹夜した状態で参加した高専祭一週間前の体育祭の終わりに急に非常勤講師も入れるようにしてほしいと某先生に言われたことでぶちギレそうになるなど、今思い返せば色々あった。

結果を言うと特にエラーもなく普通に成功した。わーいやったー
メール届いてるかわからない問題のせいでめちゃくちゃ当日不安やったけど案外しっかり届いてたっぽい。

(当日の写真を貼りたかったけど学外の人も写っているのでやめておきます）

さいごに

来年は入場者の管理とかしなくてもいいようになってほしい。

そして開発期間中にねぎらってくれた方たちには感謝してもしきれない。
本当にありがとう。







おまけ

いまから技術的な反省がはじまる。結構色々ある。

DB構造編

　まずDBテーブルが最終的に10個できた。その結果、それの全部に一通りのCRUD+αを実装したのでAPIエンドポイントが合計で60弱くらいできた。加えて、テストコードとe2eテストも書いたから書いたコードが6500行くらいあってもおかしくはない。
　原因として、そもそもフォームで取った情報（中学生に対しては年齢を聞いたり、学生の招待客には友人か保護者か聞いたりなど）がすべて違かったので、それをDBにいれるために、学生/学生の招待客/中学生/スポンサー/OBでDBを完全に分離する必要があったのでそれが足を引っ張った。

　結果的に想定していたスーパータイプとサブタイプのような分け方ができなかったのがきつい。

RESTAPI編

　そもそも上のようなDB構造になった時点でREST APIは辞めるべきだったと思う。おかげでAPIエンドポイント乱立したし。

メール編

まず、

まず使ってるメーラーによって表示が変わる不具合があり、QRコードの画像がメールにはられてないことがあったので頑張って直した。

このエラーに関しては、プログラムによって書かれたメールの形式がmultipart/alternative（内容の同じテキストメールとHTMLメールのように、形式は違っても内容は同じものを示す）だったため、それに気づくのが遅れた。本当はmultipart/mixed形式で送る必要があった。

つぎに、

これでGmailとicloudの標準メールアプリで動作確認できたし送れるやろ！とかおもって送ったらdocomoやsoftbankのキャリアメールでQRコードの画像が表示されない不具合があって前日の夜に直した。

これは自分が書いたプログラムのQRコード生成→メール添付までの間に問題があった。

原因として、いちいちファイルに保存することを嫌ったためにプログラム中でバッファーからそのまま生成した画像のデータ配列をメールに貼り付けていた。当たり前のことなのだがファイルとして保存されていないため、メール上ではただの画像の形をした謎のデータ配列があるだけである。しかし、iOS標準のメールアプリもGMailのメールアプリも優秀だったので、データ配列をアプリ側で画像と認識し、画像に変換して表示していた。そのせいでキャリアメールにはQRコードが表示されない原因を発見するのが遅れた。
（今思えば、iOSのメールアプリでQRコードの画像をタップしたときにファイル名が image0 という拡張子がついていない状態だったのを見たときに気づくべきだった。）
結局直したのが前日の23時前だった覚えがある。普通に4週間が無駄になる気がして辛かった。

広報

鈴鹿高専高専祭web班は2023年度も共に働く仲間を募集しています。興味があったらぜひぜひ。

この記事が気に入ったらサポートをしてみませんか？