# フロントエンドOneDay構想

# まひろちゃんへ
あけましておめでとうございます。
本年もどうぞよろしくお願いいたします。

というわけで（？）、まひろちゃんにフロントエンドOneDayを開いてほしいというお願いです。
詳細は以下にあります。最下部記載の「課題」の章について困っているので、まひろちゃんにOneDayを開いてもらい解消したいという狙いです。

# 概要
オリジナルWebシステムを作成するのに、アイディアがあるが実装方法が不明。
まひろ大先生のちからをお借りして、実現へと近づける

# システム構想
読書記録Webサービスを作る。読んだ本を記録していくサービス。
ただ記録していくだけでなく、読んだ本の内容を適宜「想起」できるための工夫を随所に込める予定だが、現在は基本的な機能を搭載した最低限のサービスを想定している。
コンセプトは「読書ガチ勢のための編集的読書ログサービス」

## 機能
とりあえずは直近で必要そうな最低限な機能だけがあれば完成とする。
ただしフレームワークの選定に関連する予感もするので、将来的に構想している追加機能についても記述する。

### 直近で必要そうな最低限な機能編
* 検索ボックスにワードを入れると、候補となる本が書影付きで検索できる。
* 本のタイトル部分一致検索、出版社別、著者別検索も可能とする。
* 特定の本を読んだものとして記録できる
* ログイン/ログアウト機能
* 登録した本の書影一覧ができる
* 本の感想を付随させられる

### 将来的に搭載したい機能編
* モバイルはネイティブアプリ対応したい
* 登録した本を自由に配置をカスタマイズして、自分だけの本棚や図書館を作れるようにしたい
* できればオリジナル本棚・図書館は3Dで立体的にしたい。本棚の板にはメッセージが書き込めるようにしたい
* [読書MAP](https://zunnda.hatenablog.com/entry/2019/11/11/214428)作成機能
* 任意のWebサイトと読書記録のリンクを作成＋可視化ツール

## 競合サービス

* [読書メーター](https://bookmeter.com/)
* [liblar](http://liblar.com/)
* [Booklog](https://booklog.jp/)
* [読書ログ](http://www.dokusho-log.com/)

## 実装基板構想
* 言語：Python3
* Webフレームワーク：Django
* インフラ：AWS(EC2, RDS, VPC, CloudWatch etc)
* アーキテクチャ：Web三層構造

# 課題
バックエンド実装はインフラも含めて大体どのようにすればいいのか想定はつく。
しかしどのようにフロントエンドを実装すればいいのかがまったくわからない。

1. フレームワークはどのようなものを採用したらいいのか(React? Vue.js? Redux? Bootstrap?)
2. 画面設計はどのようにしたらいいのか（何枚作るの？どんなボタンが必要？どんなカラム構成がいいの？）
3. 前節までの前提の場合、どんな技術を使ってどのように実装するのがいいのか
4. テストはどのように実施すればいいのか

## まひろちゃんへのお願い
1. フロントエンドのハンズオンOneDayを開いてほしい
2. 上記課題を解消しつつ、具体的な手の動かし方について解説してほしい。

## 梅澤の問
1. 開発方針の最下部
2. 設計書の最下部
3. 気になることの最下部

## 2020/1/14　菅原追記

### 開発方針
バックエンドをAPIとして呼び出す。
Django REST frameworkを使用？
（APIとしてではなく、DjangoのテンプレートとVueをおりまぜればできるのか不明。
WEB三層構造であることと、バックエンド、フロントエンドの切り分けが困難になりそうなのでそれは避けた方がよさそうかな。）
**▶梅Q**
ベーシックな問でアレなんだが、そもそも「WEB三層構造」であることと、「バックエンドをAPIとして呼び出す構造」であることとって同じこと？違うもの？
**▶菅A**
必ずしもWeb三層構造だからAPIとして呼び出しているわけではない気かがする。
Webサーバーとアプリケーションサーバーをどうつなぐかの一つの方法としてAPIがある。例えばJSPとサーブレットっていうJavaがあるんだけどこれはAPIで連携しているわけではなかったような。。。。

### frontend検討
言語：JavaScript
フレームワーク
JSのフレームワークで良く出てくる３つ
React、Vue、Angular
Ａｎｇｕｌａｒは学習コストが高そうなので回避した方が良さそう。いろいろな違いはあるので以下参考にしてください。個人的には自分で作るものなので自分がやってみたいものでいいのでは。
参考
http://iwasiman.hatenablog.com/entry/2018/04/23/200000#AngularReactVuejs%E3%81%AE%E6%AF%94%E8%BC%83%E8%A1%A8

### UIフレームワーク
Bootstrap、Pure、materialuiなど
選定基準
・ 自分が作成した画面イメージに合う部品、デザインがあるか
・ ファイルサイズの大きさ（大きすぎるとページのみ読み込みに時間がかかる）
・ Frontendのフレームワークによって相性の良さがあるみたいなのでJSのフレームワークにあったもの
参考
https://blog.takeho.com/introduction-of-frontend-web-application-framework/
https://qiita.com/yusuke_ten/items/4103f032dd0c6fbe5607

### 設計書

外部設計書レベルでも書こうと思えばいろいろな設計書がある。
画面設計書という観点に絞るなら以下は作るべき
（ただし、設計書は他者が理解できるよう作るためでもあるため
　どの程度作成するかは要相談）
・画面一覧
　　どんな画面が存在するか
・画面遷移図
　　画面遷移があるのであれば、どういう遷移になるか
・画面レイアウト図
　どのような画面のイメージにするか（ボタンの配置や検索条件、テキストボックスを使用等）、画面概要を記載。（ボタンを押すとどうなるのか等）

生保の画面設計書の場合
　画面レイアウト図に以下の記載もある。
　・CRUD
　・CSVレイアウト（今回は必要なさそうだけど）
　※共通の画面設計書を作成している
　　ボタンの配置や色、文字の大きさ、フォント、対応している画面の解像度（グリッドをどう切るかの参考になる）、アイコン、メッセージの出し方等を記載

**▶梅Q**
* 生保の外部設計書とか画面設計書って横流しできる？あるいは業務外でまひろちゃんが書いてきたやつをサンプルとしてみしてもらったりできる？
* 画面設計方法論ってどういう資料みたりどういう訓練すれば身につく？
**▶菅A**
生保の設計書を横流しはさすがにできないな～
梅君がひばりとかにいる機会があるなら簡単に説明はできる。
もしくは生保の設計書を一部改訂してひな形っぽくするか。

### 気になること
* モバイルはネイティブアプリ対応したい
　という点で今の内から意識しなければならないことが不明
ReactもVueもネイティブアプリのライブライはあるみたいだが
https://qiita.com/haidrant/items/789346c164b193008577
**▶梅Res**
ネイティブアプリとレスポンシブデザインで設計するのどっちがコスト的にグッドなのか、Web戦略的にどう異なるのかもよくわかってないので、実際是が非でもネイティブアプリにしたいわけでもないんだ。画面職人の立場からこれらの違いがどんなものなのかわかったりするかい？（設計コスト、運用上の特性など）
**▶菅原Res**
ネイティブアプリを作ったことがないので何ともいえないけど、
将来的にネイティブアプリにしたいなら、現時点から使う言語とか設計が大きく変わるのでは？
コストとか運用上は正直わからないけど、
レスポンシブデザインであればUIフレームワークとかReactにレスポンシブ対応用のものがあるのでとっかかりやすそう。
https://qiita.com/gwenmerida/items/5eb221023c5d1663e9b9
https://qiita.com/y_kawase/items/8f1b5a303400a09c4923

### 参考資料
* [onedayとか学習用によさそう](https://nmomos.com/tips/2019/07/17/django-vuejs-1/#toc_id_2_1)
* [家計簿アプリ](https://qiita.com/KMim/items/f3975e308d07df4b359f)
* [【Python+Flask】WebAPIを使った簡易書籍管理アプリ【Vue.js、Elasticsearch】 ](https://qiita.com/aocattleya/items/c374e87b42a14a01e77c)
* [Qiitaで検索すると、結構いろいろでてくる](https://qiita.com/search?q=%E6%9B%B8%E7%B1%8D%E7%AE%A1%E7%90%86)

# まひろちゃん授業内容　2020/01/14

## 三層構造と「バックエンドのAPIを呼び出す」の違いについて
両者はほぼ同義。
サーバーフル構成はWEPAPサーバーで処理していたので両者のしごとを区別せず実装することができた。

## ReactとVueのメリットについて。
Reactは仮想DOMと呼ばれるものを採用している。通常クライアントとサーバー間の通信は、全ページの情報を渡しているので全更新をしているのだが、Reactは仮想DOMを使うことで差分となる情報のみをやりとりすることができ描画スピードがとても早い。両方ともWebサーバーの中にいて、クライアントとWebサーバーの間で情報をやりとりしている。
Vue.jsも基本的なしくみはそう。ただ双方向データバインディングが違う。
SPAは定義があやふや。画面遷移しないシステムをSPAと呼ぶ場合もあれば、仮想DOMを使って差分のみをWEBサーバーとクライアントの間でやりとりするものをSPAと呼ぶこともある。

## Webシステムの開発手順について
基本的には以下の手順で行えばいい。

外部設計▶テーブル設計▶CRUD図▶API図▶実装▶テスト▶

#### 外部設計
手で書きましょう。ラフでいいので。
まひろちゃんが指し示してくれた上記の方法にしたがって書けばいい。
ヘッダーフッターあたりも書いておくといいかもね。

#### テーブル設計
画面情報や実現したいシステムを念頭において、必要な情報やデータ属性を全部洗い出しましょう。大体でいい。
その後それらを正規化しましょう。
テーブルの区切り方については経験がものをいう。一般的に更新頻度が高い列項目は切り出して専用テーブルとしておくと描画スピードが上がる。

#### CRUD図
外部設計で作った画面とテーブル設計で作ったテーブルとを結び合わせる表を作成する。一枚の画面につき一枚のCRUD図を作ることになる。
CRUDを図を作る前にデータフローダイアグラムを作るといい。ER図は関係性の表現だが、データフローダイアグラムはデータの時間の流れを表現する。これを表現してからCRUD図を作成すると整理される。
API図は画面からの入力があった場合、どこへどのような仕様（フォーマット）でデータが流れて行くのかを示す。CRUD図に併記してしまうことも考えられる。

ここまでラフに作ったら実装とテストに向かえばいい。