PlantUMLでER図を書いていて気づいたのだけれど、輪郭のデータ構造ってどれだけ親ノードをたどっていっても根ノードにたどり着けないな。なんてデータ構造だ。
なので、読み込みをした直後に表示するノードは、特別に記録しておかないといけない。
文輪の開発記録
2022/3/26 15:14:00
文輪のTODO
2022/4/17 13:13:00
■残務
利用者登録機能
ログイン機能
ログアウト機能
クラウド保存機能
キー操作でアウトラインの位置を変更
TauriかElectronでアプリ化
スマホ対応（見た目が崩れる）
indexedDBへの保存機能
ドラッグアンドドロップで親を追加
親が増えた時の見た目を整える
ランディングページ作成
複数行をコピペできるようにする
UNDO/REDO
■実装済み
カーソルを上下に移動した際に、カーソルがいい感じのところに移動するようにする
アウトラインを閉じたり開いたりする機能
■テスト済み
検索機能（スクロール追加）
文輪のファイル出力・読み込み機能
■リリース済み
ドラッグアンドドロップでアウトラインのミラーリング
クリックしたアウトラインを表示
親アウトラインの表示
行削除機能
あれ
2022/4/17 12:28:00
サーバーレス構成で考えたけど、サーバーレス構成にしないほうがいい気がしてきた
- AWSにベンダーロックインしてしまう
- 開発環境にもRDSの費用が必要になるので高くつく
- AWS Lambdaが実行されるたびにAWS LambdaとDBの接続が発生するので、コストがかさみそう
- Websocketが使えないので入力するたびにブラウザとサーバがHTTPで接続すると、コストがかさみそう
文輪の論理データモデル v2
2022/3/26 20:15:00
@startuml
entity outline {
ulid
text
created_at_timestamp_ms
edited_at_timestamp_ms
first_outline_relation
}
entity outline_relation {
ulid
parent_outline_ulid
child_outline_ulid
next_outline_relation
}
entity home_outline {
outline_ulid
}
outline }-- outline_relation
outline ||--home_outline
@enduml
あれ
2022/3/26 19:00:00
文輪のデータモデルが単純すぎてこれで大丈夫か不安になってくるな。
まあ単純すぎて不足がある分には追加すればいいから大丈夫か。「複雑かつ問題がある」よりも対処しやすい。
文輪の論理データモデル
2022/3/26 18:58:00
@startuml
entity outline as "outline\nアウトライン" {
ulid
text
created_at_timestamp_ms
edited_at_timestamp_ms
}
entity outline_relation as "relation\n関係" {
ulid
parent_outline_ulid
child_outline_ulid
}
entity home_outline as "home outline\nホームアウトライン" {
outline_ulid
}
outline }-- outline_relation
outline ||--home_outline
@enduml
あれ
2022/3/26 15:57:00
文輪の概念データモデル
2022/3/26 15:02:00
@startuml
entity outline as "outline\nアウトライン" {
}
entity relation as "relation\n関係" {
}
entity home_outline as "home outline\nホームアウトライン" {
}
outline }-- relation
outline ||--home_outline
@enduml
あれ
2022/3/26 14:06:00
文輪のファイル出力・読み込み機能
2022/3/26 14:04:00
OPMLでやろうかなと思ったけど、ほかのアウトライナーから読み込めるようにするのがめんどくさい。OPMLはあくまでエクスポート専用にしたほうが幸せになれる気がする。
sql.jsでDBにして保存…！なぜこのような危ない橋を渡ろうとしているかというと、セキュリティ的に安全にRDBの知見をためる必要性があるためです。
あれ
2022/3/26 0:25:00
サブスクとか買い切りにしようとすると特定商取引法に基づく表示が必要になって、名前と住所をネットにさらさないといけなくなってしまうな。個人がやるにはちょっとプライバシー的に問題がある。
私書箱契約すれば多少はましだろうだけど金をかけるのは嫌だ。
一旦はスポンサーで行ったら良さそうな気がしてきた。
文輪の提供形態
2022/3/25 23:36:00
- クラサバでサブスクで提供
- 一番儲かりそう。というか今っぽい。
- クラサバは開発が大変。
- データ吹き飛んだ時が大変。１，２回データ吹き飛ばして知見が溜まるまではサブスクしないほうがよさそう。
- WorkflowyやDynalistとガチンコ勝負になる。
- クラサバで広告モデルで提供
- デライトの劣化コピーを目指す形になってよろしくない。
- サブスクよりもデータに対する責任をあまりとらなくて良さそう。
- ペルソナとして作家のTak.氏があるので、利用者の注意を広告で煩わせるのはそれに沿ってない。
- ローカルアプリでサブスクで提供
- ビミョー。「商用利用は有料」みたいにして、本当に金払ってくれんの？みたいな疑いがある。
- 結局サブスクの管理機能が必要になるのでサーバー不要とはいかない
- Mac対応でMac買う羽目になるのでどこかでちょっと大きめの投資が必要。
- ローカルアプリで買い切りで提供
- 一番儲からなさそう。というか古臭い。古いから悪いというわけではないということを肝に銘じていただきたい。
- でも一番楽。
- ライセンス管理とかは大変そう。そういうことをしだすと結局サーバーが必要。
- Mac対応でMac買う羽目になるのでどこかでちょっと大きめの投資が必要。
- 寄付で運用
- 論外。寄付で回っているところをWikipedia以外で見たことがない。大体ヒーヒー言ってる。と思ったけど、Rustとかは寄付（というかスポンサー）でやっていってるらしい。
気持ち的には「クラサバでサブスクで提供」に傾いている。
あれ
2022/3/25 22:28:00