ラボアプリを開発しよう2日目
ラボ GW アドベントカレンダーの2日目（4/28）です。4/28日の33時に書いてますが、4/28です。いいね？
1日目の続きです。ラボアプリの要件についてForteさんと相談した内容をまとめます。
ラボ固有の事情
前提としてラボ固有の事情を設営します。ラボは、専用の事務所とかその手の物件ではなくて、事務所利用可能な普通のアパートです。そのため、いくつか制約が生じます。
・ 不特定多数を呼ぶことはできない（勉強会の開催はグレーライン）
・ connpassなどで住所を晒すことができない
・ 民泊になるようなことはできない
・ 音を立てすぎると、下に住んでいる大家さんに迷惑になる（特に夜）
そのため、ラボに参加出来る人、ラボメンをある程度内輪に限定せざるを得ません。
そこで錬金術ラボへのお誘いに書いている条件が
・継続的にアウトプットしている人
Blog、LT登壇、執筆(同人誌、商業誌、ほか)
・ラボメンの知り合い、ツテ
というものになっているのです。継続的にアウトプットをしている人はある程度名前が知られているということで「おいた」に対する抑止力になるからです。理由は説明しなくてもわかるよね？
ラボメンの知り合い、ツテは、ラボメンがその人を信用できる人だとして、紹介するのです。
それを踏まえてまずコミュニティについて手を入れていきます。
Discordへの移行
1日目にも書いた通りコミュニティが2ヵ所のSlackにまたがっています。間借りしているというべき状況なのでどこかに独立した一カ所に移行したいというモチベーションがあります。
次に、Slackは割と使いづらい部分も多く、サーバーごとにアカウントを作らないといけないことと、1万件のログ問題があります。そこで、Discordです。
今後、何かしらのオンラインコミュニティを立ち上げるならSlackよりはDiscordをお奨めでしょう。Slackは会社をオンライン化するためのサービスであるため、OSSとかユーザー活動のようなコミュニティには少しミスマッチなところがあります。
さて、Discordですが、ラボの「漏らしてはいけない情報」の類いが日常会話に登場する可能性があるため、不特定多数を招くわけにはいかないところがあると、僕は考えていたのですが、Forteさんがここらへん案を出してくれました。
Discordではあるサーバーにおいて役職を定義できます。ラボメンや、ラボに一度来たことがある人、それ以外という3つのロールを用意できればセンシティブな内容に関しては専用のチャンネルで喋るような事ができます。
Discordに入った時点で @everyone という役職になります。ここで特定のチャンネルのみを閲覧可能にします。
・ ゲスト向け雑談
・ 告知
・ なんでも質問コーナー
ひとまずこの3つを用意しました。
ここらへんの設定は Discordの権限設定について説明してみる を参考にしました。
明日（4/29）の開発デイであれこれここらへんも進めていき、いずれ普通に招待可能にしたいと思います。
選定
主導者の個人的わがままにより、TypeScript+React (Hooks)+PWAとFirebaseというスタックを採用します。
アプリの利用用途を整理する
ひとまずForteさんと相談して出てきた話としては
・ ウェブブラウザでアクセスできる
・ PWAアプリとして使える
・ ウェブ上では一意のURIで、各種テキストや物理アイテムの情報にアクセスできる
・ 情報を書いたり読めるようにする
・ issueをたて、追記し、解決できるようにする
・ ラボにいる人を把握できるようにする
・ ラボの利用予約システム
・ 物理アイテム管理と、テプラでQRやラベル印刷
・ 同人誌の在庫管理
ここでいう情報はテキストや画像になります。
「ゴミ出しはいついつで、どういう手順で出す」
「郵便受けの開け方」
「トイレの水洗レバーの回し方のコツ」
などなどです。これらはTIPSとしてアプリのローディング画面に表示できるようにもしたいなーと思っています。
issueは、「消耗品が切れてるよ！」とか「ゴミたまってる！」とか「掃除機欲しいよね」とか何かしらの議題・提案など、解決が必要な物です。もちろん、解決せずに棄却するということもあり得ます。作成・状態変更・コメント・検索などが出来ればいいでしょう。
データの種類としていえば、issueは情報の一種ということになります。
ラボにいる人を把握できるようにするは、チェックインの機能を用意してラボに誰かがいるというのをメンバー内で共有できるようにして、ラボの活用度を上げるためのものです。
「今日行けばモブプロできそうだなー」とかを知りやすくするためのものです。
「今ラボにいるけど、何時までいる予定。スマブラすっぞ」「ボドゲーやろうぜボドゲー」みたいなコメント込みで状態の共有ができれば良いです。
チェックインする時に、チェックインするかどうかの選択は可能とします。忘れ物取りに来ただけなのにいちいちチェックインしても誰もうれしくないためです。
ラボの利用予約システムは、「何日何時〜何時はPodcastを生やすお兄さんがPodcastの収録に使う」「何日何時〜何時はラボ飯（ラボメンや知り合いなどを集めて食べたり飲んだりカードゲームしたりする会合）をやる」などを登録するシステムです。
Podcastの収録は静かにしていないといけないので、他の予定とバッティングするのは望ましくありません。
これに関しては実は既に仕組みはあるので、それと連携だけできればかまいません。
物理アイテム管理と、テプラでQRやラベル印刷というのは、ラボにある機材や本などを管理するためのものです。
物理アイテムは所有者がいてラボに貸し出ししているもの、所有者の存在しないものなどがあります。
持つべきデータとしては、名前、所有者の有無、利用可能かどうか、コメント（注意事項など）などです。
QRやラベル印刷は、それら物理アイテムに名前とURLを印字します。
同人誌の在庫管理はラボ固有といえばそうかもしれません。ラボには大量の段ボールの箱があります。実際のところは物理アイテム管理の一部と言えます。
中の冊数など、数字情報が追加されるとありがたいものです。場合によっては、Google SpreadSheetなどと連動できれば使い勝手が良いものになるでしょう。
用途として、今日（4/28）話し合った内容としてはこんなところです。他にも色々出てくるかもしれません。
何が必要か？
雑に、何が必要か？というと、どれも
・ uniqueなID
・ IDを元にuniqueなURI
・ データ（テキスト・画像）
・ メタ情報
です。実際のところKVS向きなデータなので、Firebaseなら、FirestoreかRealtime Databaseにぶち込めば大丈夫でしょう。画像をFirebase Storageに入れるかどうかは考えどころかもしれません。
データ要件と雑な仕様
・ユーザー
・物理アイテム
・blob
・metadata
・histories
・チェックインステータス
というテーブルを雑に考えています。
ラボアプリの性質上、膨大なデータが入ることはあり得ないため、データを消さずに全部ぶち込んでも全く問題ありません。そこで、テキストや画像はblobという単位で取り扱うことにしようと考えました。
例外は、万が一にも入ってはいけないデータの類いが入った時削除する可能性がありますが、それはレアケースと考えられるので、Firebase Consoleから削除してもいいですし、頻度が上がれば専用の削除ツールを用意する事になるかもしれません。
ユーザーは、FirebaseのユーザーIDを元に、ラボ固有の情報をもちます。鍵を持っているか？月額支払い金額、DiscordのIDなどです。あとラボポイントみたいなものを用意すると面白そうだなと思っています。
blobはデータのハッシュ値（SHA-256かな）をIDとした、書き換え不能なデータです。IDは表に出ることはなく、メタデータからのみ参照されます。
metadataは、メタデータ自体のID、種別（情報、issueなど）、blobのID、作成・更新日付を持ちます。
issueの状態管理やコメントツリーなどをどう表現するかはまだ考えていませんが、メタデータの種別ごとに追加情報を持たせるという形に落ち着くかもしれません。
物理アイテムは、アイテムIDと、所有者ID or なし、利用可能フラグ、名前、コメントなどです。ただmetadataの種別の1つでいいような気もしています。（ただ、blobを必要としていないという点をどうするか）
historiesは操作履歴です。metadataを操作する時に追記します。日付、metadataのID、その時のblobのID、コメントなどを持ちます。
データを消さない仕組みにするため、データを修復したりが簡単にできます。そのため、それぞれのメタデータごとに操作履歴を残し、参照することで、それぞれの時点のデータに戻したりできます。
チェックインステータスは、今居るか？は揮発性のデータで、性質上Firestore よりは RealtimeDatabase の方が向いています。
雑ですが、大体このようなデータがあれば大丈夫かな？というところです。
まとめ
要件を考えると、大体テキスト・画像の追加・編集・削除などを実現できれば良くて、量もたかが知れてるので全部のデータを保存しつつ、追加・編集・削除は、メタデータの操作で表現可能だなーというところです。
拡張性はメタデータを軸に考えれば良さそうだなーというところです。マイグレーションしたとしてもさほどコストが掛かるわけでもないので、これ以上凝った仕組みを考えるのは無駄ですが、メタデータのデータ内容や物理アイテムをどうするかについてはもう少し検討すべきでしょう。
あとはDiscord連動など、他APIとの連動が必要だなー位ですし、まずはGW中にできる範囲をやって、あとの拡張はあとで考えればいいでしょう。
4/28日の34時ですが、GWアドベントカレンダー二日目（4/28）でした。
明日（4/29）は、ラボメン何人かがラボに集まってモブプロ・モブ開発を行います。
この記事が気に入ったらサポートをしてみませんか？