# JPHacks2022 本戦 タスク整理と戦略検討

## 概要

ひとまず本戦出場おめでとうございます。 **祝！！**
ということで残り2週間強の開発期間が湧き出しました。予選より長いですが、それでも長くはないです。
ここで何をやるべきなのか、何をすれば効率的にプロダクトがそれっぽくなるのかを検討して効率的に実装を進めたい。
引き続きよろしくお願いいたします。

## 全体方針

- 単なるエディタからプラットフォーム・エコシステムへの発展
- バージョン管理機能の本実装
- ユーザー間コミュニティ機能の実装
- UI・操作系のブラッシュアップ
- もう少しの「スパイス」の実装

## 現実装での問題点・改善点

### 編集画面

- デザインのブラッシュアップ
- 何が押ささってるのかわからん
> これに関しては押したらノードの色を変更するのがいいかなぁと思います。あとボタン自体をでかく表示したり
- 編集モード切替ボタンももうちょい改善したい
- ノード接続時の手順が以外とわかりにくい

1. メタデータ
- タイトル
- タグ
- 作者
- ライセンス(?)
2. 食材
- 種類
- 量
- N人前
> フローチャートのノードと連携できるようになるか?
3. フローチャート
- プレビュー
- 登録 / 編集フォーム（伸びる分には何か追加）
4. 補足説明エディタ(優先度後)
5. 保存ボタン

- 編集画面ワイヤーフレーム

- 食材追加UIをちゃんと実装する
- 表示場所を最適化してもっと大きく
- 原材料名だけでなく量も登録
- 何人前？( <= 構造化データにするために必要！！ )
- せっかくなので数値類を自動計算したい！
- これフローチャート定義側もコンピュータ可読なフォーマットrequiredやな

- 食材をレシピデータ側に反映する
- マークダウンの table 要素で定義するのがよさそうかも
- この辺のフォーマット策定が必要
- データ構造絡みは後述しよう
- つまり markdown => html => (表示) がいる
- frontendでmarkdownをパースする義務？

- ファイルIO
- 本運用で必要なのかどうかは議論の余地あり
- あって困るものではない？
- 本運用するならちゃんとUIつくる

- 説明文関係
- 編集用UIの実装
-　やっぱりmarkdown形式？
- 表示システムの実装
- (frontend)結局markdownレンダリングに帰結
- (backend)画像投稿したい？ static-resourceをどうする？ s3?

- エッジの調整
- エッジに説明テキスト張る機能がない
- エッジにクリックイベント張れないのでどうしよう
- ノードで編集？(要検討)

- フローチャートのCSS
- 作業内容に合わせて色変えるとか...

## 新規画面開発

### 表示画面

- 編集画面から編集機能を抜いてUIを最適化したようなもの
- +αでボタンなどが生えるかも
- これは全体設計しだい
- 流用面が多いと思われ、実装負荷はそんなに高くない

### ホーム画面

- プロダクトのトップページ。
- いくつかレシピをTL形式で出してもいいかも
- レシピの検索窓口
- バックとのすり合わせが必要

### ユーザーマイページ

- 単に今まで投稿したレシピ一覧が出ればいい
- あと通知関係(PRなど)
- お気に入りのレシピとかはどうですか？
- 多分既存のレシピを簡単にアレンジっていうのは結構でかいアピールポイントな気がするので、これからアレンジする予定の他人のレシピをブックマークしておけるみたいな

## backend接続関係

- まずアプリケーション全体要件を決める
- それで、API定義を詰める
- 本番環境では必ずbackend連携します！(ごめんなさい)
- 多分本検討で追加要件ガンガン出るので

## リソース関係

- award dayのデモはまぁまぁ規模がでかい
- 展示ブースもある(?)
- さらに機能追加もする
- ので、レシピ関係のリソースが欲しい
- さらなるレシピ
- 若干難しくて複雑なのもあるとプロダクトの価値を出せそう
- アレンジの例
- 加筆修正の例(?)
- 工程モジュールの例

## バージョン管理

### ユースケース

名前に反して「分散型」である必要性はそんなにない

- 編集履歴の可視化 (commit , commit履歴)
- 既存レシピへの編集提案 (branch , Pull Request)
- 既存レシピの改変 (fork)
- fork元の追跡可能性を担保する

共通の基底機能として「差分表示」
- 独自拡張mermaid記法の生差分を出すのはやめたい
- 「グラフィカルな」差分表示ができればベスト
- 要検討

### 実装案

1. githubに依存する
2. gitに依存する
3. 独自設計する

### github依存

- 多分実装楽
- エンジニアのユーザーには高評価かも
- ただ投稿者の普通のgithub repoとしてレシピが生えるのがあれ
- 非エンジニアにはgithubのアカウント作成を強いるかも

### git依存

- 実現可能性含めてあんまり見通し立ってない
- libgit2でアプリケーションに組み込むことができそう
- backendにgitを入れてバージョン管理する
- repoは実際のファイル・ディレクトリでなければならない

### 独自設計

- 当然実装負荷はある
- ただ今回のレシピというユースケースに特化した設計を出せるのはつよい
- 本当にできるん？

## 工程PM(仮称案:cgpm とか ckget)

- 内部実装的にはレシピ登録とあんまかわらん
- 単にレシピではなく工程として管理するだけ

- バージョン管理はしない、バージョン番号は持つ( >= 0.11)
- 何か一意のIDを持っておく

## データ構造::拡張記法

いくらかmermaid記法の拡張が必要そう

### ドキュメント要素

これは直接はmermaid記法とは関係しない

- メタデータ(title , author ...)
- 原材料記載ブロック
- 詳細追加説明ブロック

### 拡張要素

- 原材料への参照
- 工程PMへの参照
- フローチャートの見た目にかかわる定義

## 追加要素

- なんかもう一押し欲しい気はする
- 特に料理する側にインセンティブをもう少し
- 料理しない人に向けたもう一押し
- やりやすい！系の機能
- 使う食材からサジェストする？
- 家にある食材を突っ込んだら一致するレシピを返してくれるとか？（このプロダクトでやることか？って感じですけど）
- こっちから能動でサジェストする機能は結構良さそう
- 今回の機械可読なレシピという特性が生きるものがほしい
- 報酬系の機能
- 作ったレビューとか投稿してコントリビューション？

githubに依存する形にしたい
mdをgithubだけでいじって cookingitを経由しなかった場合がありそう
firebaseのログイン時に GitHubAPIをたたくためのtoken も一緒にとれそう

## API仕様
### ユーザーの名前返すやつ

GET http://localhost:8000/get_user_name HTTP/1.1
content-type: application/json
x_github: gho_〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇

{
    
}

Example response
{
  "github_login_name": "kake-r"
}

### ユーザーのレシピリポジトリ返すやつ

GET http://localhost:8000/get_recipe_repo_list HTTP/1.1
content-type: application/json
x_github: gho_〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇

{
    
}

Example response
{
  "recipe_repo_list": [
    "CookinGit-recipe-test1",
    "CookinGit-recipe-test2"
  ]
}

### 新規でMDを投稿するやつ

POST http://localhost:8000/post_new_recipe_repo HTTP/1.1
content-type: application/json
x_github: x_github: gho_〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇

{
    "recipename": "CookinGit-recipe-test3",
    "mddata": "bXkgbmV3IGZpbGUgY29udGVudHM="
}

Example response
# 作成成功
{
  "status_code": 201
}

### MD を更新するやつ

POST http://localhost:8000/post_update_recipe_repo HTTP/1.1
content-type: application/json
x_github: gho_〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇〇

{
    "owner": "kake-r",
    "recipename": "CookinGit-recipe-test3",
    "mddata": "bXkgbmV3IGZpbGUgY29udGVudHM="
}

{
  "status_code": 200
}

### MD の中身を取ってくるやつ

だめっぽいな