OSSなマンガ作成支援ツールの素案（1年半ぶり8回目）３

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

「OSSなマンガ作成支援ツールの素案（1年半ぶり8回目）２」をトゥギャりました。 togetter.com/li/1294507

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

さあフレームワークは何を使おうか。もうオレオレフレームワークのバグ取りは懲り懲り。MITライセンスになったリアクトかな。それとも野放図なVueかな。問題は結局、数年で賞味期限が切れてレガシーになってしまうということ。でもどうせ次はVRで3dだよなぁと言うのもある。

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

まず、タイトル一覧が有って、タイトルを追加、修正、削除が出来る。 次に、部品の海（ツイート集）からネタをすくい上げリストを作成する。 それから、不足分をツイートし、リストに追加する。 使用されたツイートは何処で使われたか参照が紐づき、部品庫で確認が出来る。 また改変ツイートも出来る

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

改変ツイートができることが重要で、それができさえすればよい。原則追記のみで物理削除は考慮しない。これを満足行くぐらいに３回返して仕上げる。一回目は関係の有りそうなツイート、二回目はプロットへ絞り込み、３回目でセリフ込みのシナリオ。次の段でページ割を実施する。そしてネームへ。完璧！

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

そうかTrelloですね・・・欲しかったものは・・・微妙に違うけど。 twitter.com/io_xxxx/status…

伊於🌸5/2：ワンオペ解雇(1)発売 @io_xxxx

頭で考えてはいたけれど話がうまく固まらずに唸っていた冬コミ新刊、Trello使ったら爆速で進んで3時間半くらいでプロット終わった…どうやらもともとアナログで付箋に入れたい要素をばーっと書き出して→並べて→付け加えたり削ったりしてた自分と相性がよかったらしい…… pic.twitter.com/ImkuvZTjcx

2018-12-04 16:58:01

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

Trelloがそうじゃん！て言うのが有るんだけど、ちょっと違うかな。 ・部品庫が必要、どんなエピソードでもそこにある。 ・１個のカードはあちこちのリストに使われる。 ・リストは最後に解けて、ページに化ける。 ・１個のカードに別のカードの要素を参照として付けられる。Wikiのように。

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

そして何より、第三者によるサービス停止のチョークポイントをできるだけ回避する。最悪インターネットがなくたって作動するシステムを目指す。違法情報という、観測するまではそれが違法であるどうか分からないというシュデリンガーの猫味のある状況が有るため、安心を買うにもこれは必須要件。

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

でも結局シグナリングが面倒。一応手段何でもOKなのが救いだけれど

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

ちょっとまずER図描いてみようかね。ユーザー認証はまだてつかづだけど

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

部品のデータ構造はどうしようか。要件はタイトル、本文、時間、参照が有れば良くて、IDはSHA512ぐらいでいいか。シードはSNS名とアカウントID、投稿IDというか時間。まさか同じミリ秒に投稿が決まるとかあるんだろうか。暗号化してアカウント制御を入れたいものだが。

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

この部品を作品というくくりで、3STEPのリストに参照が入ると。そうか返信も管理しないとチェーンにできない。リスト参照と返信先参照が必要。

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

うーん更新参照と追加参照で分けるべきだな。リストは個別に配列を管理をしてて内容はlinkedlistやな。任意のステップに分解できるとして、とにかく関係ありそうなのをピックアップ、整列と追加、動作主体or発言者参照付与とページ割の三層構造なんだと思う。ソートと更新内容がそれぞれ違う的な。

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

上流の変更内容は下流にそのまま反映される。なので、リスト間に親子構造が存在する。

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

上流に反映された部品はダウングレーになる。よってまだ上流に反映されていない部品が浮かび上がってくる。こうタスク看板ツールではタスクの処理に注目するから看板が移動するのが重要なんだけど、物語を部品を集めて紡ぎ上げるのは前との暫定的な位置が分かったほうがいい。

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

当然、物語として表に出てくる情報と作者が紡ぎ上げる上で納得すべきだが表に出しては台無しに成る情報がある。これを実現しようとするとコメント機能と成る。しかし、部品にコメントを直接付けては管理が煩雑になる。これは組み合わせの意味を綴るものなのでやはり別の部品として存在するべき。

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

紐づく先はリストとコメント先の部品の複合キーになる。したがってどちらかが消えてなくなると１段目のリストに格納される。もちろん部品庫にも入る。部品庫は溢れかえるけどそれでいい。フリーワードと時間のキーで検索は出来るようにしたいな。リストの順番はリストがもってて、リストには部品参照が

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

部品参照はSHA512バイナリ？jsでバイナリ比較は簡単なんだっけ？実際の人間が読む文章は部品の方にはいっている。部品はあんまりデータ量が多くてもしょうがないので、文章は１４０文字でいいんじゃないだろうか。

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

テーブル構造を考えたぞなもし。 多分作品は常にオンメモで、部品の数が１Mレコードオーダーなので、表示している領域だけ見る感じかな？それとも一旦、中間テーブル噛まして使ってるリストの参照をするしか無いのかな。正直indexeddb速いと言われているけどそこまでなくね？と思うのですよ。 pic.twitter.com/VnYqwEjwo8

拡大

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

これで実現できるのは ・上書き型追記（過去はそのまま残る） ・拾ってきた部品が何処に使われているのか分かる ・ページ割は部品の中の文字列位置、リスト内でページ位置計算 ・部品の特定文字列にリストの参照をつける、発言者等の設定は外に持てる ・コメントはリストと合わさって部品から成立

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

部品から寄せ集めて設定リストを作ってそれを別の部品の参照に据えられると。一次読込は自動化できるけど再帰ループがちょっと怖い。ループ検知するしか無いね。 あとネームとは別にアイコン画像テーブルを作ってアイコン管理出来るといいね。凝り過ぎかもしれないから後回しなんだけど。