生物分布観測報告システム考３（続GASとGithubに寄生しよう！）

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

「生物分布観測報告システム考２（GASとGithubに寄生しよう！）」をトゥギャりました。 togetter.com/li/1466567

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

githubをストレージとして使う場合の検索キーワードを一つ思いついた。 github as a service だ。 で、githubのストレージ上限についての公式ページに出会う。 １ファイルは100MBまでだよ。50MB超えると挙動が変わるよ。25MBまでしかWEB経由でコミット出来ないよ。リポジトリの上限は100GBだよ。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

75GBで警告がメッセージで帰ってくるよ。1GBまでが推奨だよ。1GB超えたら警告メールを飛ばすよ。 なるほど、これだったら美味しくないわけだ。 だが、リポジトリは無限に作れる! リポジトリを分ける運用を想定すれば大丈夫! 多分、分散アクセスをするならハッシュで分けるか、それだと数が膨大なので

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

やはり時間軸で分割が正しい。こう、調べたいクエリーが飛んだ時点でクエリーからリポジトリを特定できるようにすると。 でないと、フルスキャンしないといけない。 後はindexのデータ量か。多分indexのリポジトリを分離するんだけど、データリポのインデックスのインデックスを持つ感じでやるしかない

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

GithubのGitというインターフェイスとAPI、そして何より転送量が無料ていう点。 累代管理が出来て、転送量無料。 これが魅力なのだが・・・あんまり迷惑をかけてもいけないので、しおらしく使うことを考えたい。 転送自体、時間も食うしね。 従ってローカルにキャッシングしまくることになる。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

以上を踏まえてリポジトリの構成は ①アプリプログラム本体 ②一次Indexリポジトリ ③２次Index＋データリポジトリ という構成で、①はバージョンアップを頻繁に行えるようにするため、②は③の位置と再瀕アクセス経路を保持するため、③はデータ蓄積なのでそのまま数が増える。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

と言う訳で３個以上のリポジトリが協働する必要がある。 あーしまった。 githubのRawファイルアクセスって当然cors対応してないよね。ぎゃふん。 うーむこの境界線をgithub pagesから越えなければ行けないということを忘れていた。 ここさえ超えれば等価なんだが。うーむ。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

なんかどうせgithubpagesならそこでデータを出せる様にすればそれ同一ドメインでajaxアクセスし放題だよね。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

うーんgithub本体のデータを活用したいが難しい。と思ったらcors許可されてるやん!やったぜ! どっからでもアクセスし放題だよ！ raw.githubusercontent.comはcorsおｋなレスポンスヘッダー返してくれる! お、なんだかオラワクワクしてきだぞ!

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

と言う訳でかんがえるのだが アプリは静的ページなので何もない。indexリポジトリのindexファイルのindexだけを持つ。 indexリポジトリは各種検索結果のindexデータを保持し 各indexデータはデータリポジトリとそのインデックス位置を持つ。 ユーザー管理はインデックスリポジトリが担う。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

いやユーザーデータ専用リポジトリにすべきか? まあ、ユーザーデータはしょっちゅう変わるので。でもindexを作るのもユーザーだよねと。 3レポジトリで２ちゃん風味のbbsを作ってみれば良いんだよな。投稿はログイン必須として。SNS風味にバイオやら検索条件からタイムラインを作れれば良いわけで

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

データリポジトリは単純に テキストファイルがjwtとして存在するだけ 一方のindexデータはパスが書いてあるだけ。 それも改行区切りのBASE64で ただ、画像ファイルだけはバイナリでそのまま置くかな。どうしようかな。BASE64にすると1.33倍に増えちゃうのよね。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

データの書き込みは ①GithubPagesのWebフォームでデータ作成 ②GASに投げる ③GASで一定長以上のデータは破棄、署名の確認 ④GASからGithubAPIでブランチを作成 ⑤GASからGithubAPIで投稿、コミット ⑥GithubActionがメインブランチにマージ ⑦同時にindexデータに登録内容を追記しコミット

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

この時、後日歴史改変ができるように、ブランチは消さない。 ブランチ名はデータのシグネチャ なお、データのシグネチャは一定の法則でファイル名としても機能する。 BASE64urlでSHA512は88文字なので こう1文字単位に8文字+残りまでパス名にする ファイル名はa.json固定 画像は先頭から連番.txt

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

jsonなのもあれだな。jwtでいいや。 データリポジトリには次のindexファイルを格納する ・投稿日順 ・ユーザー別投稿日順 ぐらいか？ いかんな必要なindexが何かまだ把握できていない。 次に進もう indexリポジトリは次を持つ ・タグ一覧 ・タグ別投稿日順 ・ユーザ一覧 ・ユーザ設定 ・ユーザ認証

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

ユーザーだけは必要なんや。 2chのトリップとかじゃあかんのや。 追加追加 データリポジトリ ・観測時間順 indexリポジトリは同時に ・投稿期間別リポジトリ一覧 ・期間別観測時間順 ・タグ別観測時間順 こんなところか？ うーん

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

で、投稿はいくつかに種別が分かれてて ・観測報告 ・Wiki：投稿時間 ・タグ：リレーションのみ ・同定：アンケートみたいなやつ ・実績：加算のみ とか種別を設けて、indexの純度を上げたいわけだが、 問題はLinkedListを構成する際の参照はどうやっても設定する？ 観測情報は触りたくない前提。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

中間テーブル宜しく 参照indexファイルが必要。 indexリポジトリ内に観測情報と同じファイルパスで内容は 参照された観測情報に対し ・どの種類の ・どの報告情報が 参照しているかを種類ごとの配列に入れて jsonとして保管 もちろんGitなのでじゃんじゃんコミット indexリポジトリはブランチは消す

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

コミット時の競合が気になるが パフォーマンスは敢えて無視して GAS上に分野ごとにキューを設けて 直列化してコミットプッシュするしか無い。 GithubActionも1分毎に起動して処理かな。 2000分/月、60x24x31=44640分！ 2.6秒/回しか処理時間がない うーむ。と思ったら公開リポジトリは無制限なのか。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

そのワークフローを起動したリポジトリやプロジェクトでの開発やテスト、リリース、デプロイなどに関連しない処理での利用も禁止 には引っかからんやろう！ プロジェクトでくくっておけば目的通り！ 無制限なら、ユーザーイベント駆動でやったほうが実質起動回数は減らせそうやな。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

しかしやな。 90byteのレコードが100万行で90MB、平均10個リンクがついて、900MBで結構危うい気がする。 10万投稿あたりでリポジトリが一個満杯になる感覚かな。 SHA512を使えば512bitなので、事実上青天井。うーんSHA256にしてデータ量節約した方がいいんかな。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

なおGithub Actionはここを見て判断している knowledge.sakura.ad.jp/23478/

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

about.gitlab.com/handbook/ すごいな・・・ たぬきがロゴのGitLabはフルオープンなのか。 誰よりも正解を突き詰めていけば非公開にせずともその突き抜け具合でアイデンティティを維持できると。 note.com/takahiroanno/n… でここに日本語の紹介記事なのだが 検索エンジン作らずにGoogleに任せろとある。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

となると、まあ投稿自体を暗号化するというのはナンセンスの極みだな。 一度公開された情報はネットの海を彷徨う。 で、構造上はデータ量を削減したいのでメタデータを置くということになるか。 ここは安直にyamlかmarkdownやな。後者が虫屋に優しい気がする。 SPAでPWAにも対応と。SEO的に大丈夫やろ

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

表示機序は ①GithubPagesからHTMLを呼ぶ ②jsがAjaxで#以下のハッシュ値をのindexファイルを取得 -ハッシュ値が無い場合はデフォルトindexを取得 ③indexファイル内のURL(データリポジトリ)をAjaxで取得 ④③がメインとなるデータで③のメタデータを別途取得 ⑤以上のチェーンデータでWebページを構成