前書き
研究室に置いてあった去年のカレンダーとその後ろに付いてあった「外出」「テレワーク」などのステータスボードを発見した僕。そのボードを活用していたが、「テレワークと決めても遠隔で操作できないと意味ないのでは?」と思い始め、Web上で操作できるステータスボードの作成を決意する。これが、この物語の始まりである。
使用技術選定
ステータスボードに使用するハードウェア
ESP32(却下)
WiFi接続マイコンのド定番であるESP32。最初はこれを採用し、手作り感満載のステータスボードを作ろうとしたが、思いもよらぬ壁をぶつかる。なんと、大学のWiFi認証は単なるパスワード認証ではないため、普通にESP32だけでは接続が困難であることが発覚したのだ。
そのため、電子工作オタクである僕もこの案は諦めることにした。
Amazon Fire 7(採用)
そうなると次はやはり安物のAndroidタブレットを検討することとなる。WiFi認証も問題なく突破できる上、最近はコスパの良いモデルもたくさん登場している。しかし、ずっとつけっぱなしにしておくので、ある程度検証されたものを使いたいと思った。
その時思いついたのがAmazonのタブレットPCである。いつのタイムセールでとんでもなく安値で叩き売りされるあのタブレットである。しかし、決意した時はセール期間ではなく、やや高値。画面表示器にしては出しづらい価格帯であった。
そのため、メルカリで古めのFire 7を購入し、ステータスボードを作ることに。
サーバ
要件
最低でもこれくらいの機能は実装したかった。
- リアルタイムで画面表示を切り替える
- 複数の状態を設定できる
当たり前の機能だが、「リアルタイム」でとなると多少実装が面倒なことになる。候補に上がったのはWebsocketとFirebaseである。
自前Websocketサーバ(却下)
そこまで実装が苦ではないし、リアルタイム性も充足できるため、要件は満たしている。しかし、このようなものを動かそうとすると当然維持コストがかかるわけで、ステータスボードのためにサーバに課金したくはなかったため、ボツとなる。
Firebase(採用)
大規模になると高くなりがちなFirebaseであるが、個人が使う分には無料枠でも十分すぎるくらいである。維持コストがほとんどかからない上に、データベース(Realtimeの方もFirestoreの方も)のAPIによるリアルタイム更新もできる。多少クセのある書き方が気に入らないところではあるが、サーバに課金したくなかったので今回はFirebaseを採用した。
Webフロントエンド
なんでもよかったが、当時慣れていたNuxtとVuetifyを採用することにした。動けばなんでもよかったのと、Webフロントエンは自分の主戦場でもないのでここは楽したい。
実装
ボード
言語はKotlinで、今回初めてJetpack Composeを使用することにしてみた。しかし、SwiftUIと似て似つかないものであって、「ほとんど同じものだろ」と安易に思っていたが少し実装中に戸惑ってしまう。思想的には似ているが、コンポーネントの名前や設計がやや異なるので、割と困惑したのである。
画面構成はログイン画面、ボード画面、設定画面の三パターンある。
サーバ
Firebase Databaseを状態保存及び配信用のストレージにし、認証はGoogle認証にしようとしたが、FireタブはGAppsがデフォルトで入っていない(当たり前ではあるが)。そのため、認証はGithubのOAuth認証にした。パスワード認証にしなかった理由は、単にボード側の実装が面倒だからである。データ構造は、
- users(コレクション)
- user_id(ドキュメント)
- deivce_ids(コレクション)
- device_id(ドキュメント)
- name: 名前
- status: 任意の数字
- device_id(ドキュメント)
- deivce_ids(コレクション)
- user_id(ドキュメント)
のような構造になっている。なお、認証にはFirebase Authenticationを使用しているため、user_id
はFirebase AuthenticationのUID
となる。
Webフロントエンド
NuxtとVuetifyを採用し、割と適当なページ構成にした。ステータスボードの操作画面にコストをかけたくなかったので、バグ多めだが実用上問題ない程度の適当な実装にした。
状態変更:「状態」に割り当てられた数字を入れると画面の変更ができる
終わりに
感想
大したものではないが結構役に立っている。僕は「外出」「テレワーク」「帰宅」「在席」「移動中」のステータスを設定できるようにしている。研究室の他学生もこれでステータス把握できていいらしい。