jphacks / f_2002_1 Goto Github PK

View Code? Open in Web Editor NEW

0.0 4.0 1.0 25.4 MB

「おしゃべじたぶる」のサーバサイドに関するリポジトリです。

License: MIT License

Makefile 0.29% Dockerfile 0.25% Go 89.42% TypeScript 2.31% JavaScript 0.78% C++ 5.45% Python 1.51%

f_2002_1's Introduction

おしゃべじたぶる（サーバーサイド）

iOSアプリのソースコードはこちらのリポジトリjphacks/F_2002をご参照ください。

宣伝動画

製品概要

農業 x Tech

背景(製品開発のきっかけ、課題等）

弊チームではアイデアソンを通じて「アグリテック」分野に挑戦してみたいということになりました。理由としては

コロナ化で家庭菜園のブームがあるため、ニーズが増えている
他の案だと既にデジタル化したものをデジタル化することになるが、家庭菜園のテックは新しいデジタルであり、クロステックになる
メンバーの1人の実家が種苗店のため、農業に関するリソースと知見がある
メンバーの技能それぞれを生かし、IoTやアプリなど、複合的な技術で制作ができる

というものが挙げられました。

実際に調査やヒアリングをしていく中で、需要があることを確認しました。そこで伺った課題、続かない理由としては

水やりの適切な量、タイミングがわからない、忘れてしまう。
植物の知識がないので、良い日当たりや病気などがわからず枯らしてしまう
飽きてしまい続かないが挙げられ、これらはIoTとチャット機能で解決できると判断しました。

また、水耕栽培を行うやさい物語のような、IoT家庭栽培の競合は少数確かに存在していましたが、水耕に限定されていることと、どれも無機質で「おしゃべりができる」ことによって植物を身近に感じるサービスはありませんでした。

しかし、無機質を好むような本当に合理的な人であれば育てず野菜を購入する場合が多いのではないでしょうか。私たち「おしゃべじたぶる」は機能的であるのみならず、本来無駄であるはずの雑談を通して野菜を身近に感じてもらう、それが家庭菜園の醍醐味であり、継続に繋がると考えました。

製品説明（具体的な製品の説明）

「おしゃべじたぶる」は野菜とおしゃべりしながら、家庭菜園を楽しめるスマホアプリです。
栽培キットの購入から野菜として収穫するまで、必要な全ての工程をアプリがサポートします。
栽培中はチャット画面から野菜とおしゃべりできるだけでなく、水やりや日光に当てるといったアドバイスもしてくれるため、事前知識のない方でも安心です。
可愛いキャラクターとUIデザインにより、子供と一緒に育てる保護者や若い女性におすすめです。

アプリ挙動のデモ動画

特長

1　キャラクター

野菜ごとに親近感を持つ、仲良くなるために必要なキャラ付けを行い、セリフ回しに特徴が出るようにしました。キャラクターはどれもオリジナルです。暖かみがあるカラーリングで制作しました。

2　栽培キットの購入

栽培に必要なセットが盛り込まれたキットを簡単に購入できます。

3　チャット

難解な言葉を使わず、仲良くなることをメインに雑談やアラートなどを行います。カメラを使って、葉っぱなどの写真を撮影すると病気について診断し、適切な助言をします。

4　IoT

気温や水分量をセンサーで計測し、データを蓄積します。十分な育成環境から規定値を下回ったり、上回ったりした場合、チャットからアラートを呼びかけます。

解決出来ること

家庭菜園に関する知識や経験が身につく
家庭菜園に興味はあるが続けられない人のモチベーションを維持できる

今後の展望

このアプリで実際に育成しきれるか実験する
栽培キット配送サービスとの連携
病気・栄養不足といった診断機能の充実
野菜の種類を増やし、育成の選択肢を増やす
チャット機能への文言追加

注力したこと（こだわり等）

デザインチームはデザインがずれることを懸念して、アイデアが決まった段階でサービスの認識をすり合わせ、カラーやフォント、サイズなどのデザイントーンを統一し、作業に落とし込みました。UIUX、デザインスタイルはヒアリングを元に、刺さるものを考案し制作した。
iOSチームはデザインチームからの要件を可能な限り満たせるように実装しました。
サーバーチームはOpenAPI を利用して仕様を共有し、Clean Architecture でテストしやすい実装をしました。また、モブプログラミングも採用しました。さらに、GitHub Actions を利用して、テスト、デプロイを自動化しました。
また、開発全体ではDiscordを用いて各チームと素早く情報共有できるようにしました。

さらに詳しい情報は発表資料をご覧ください。

開発技術

全体構成図

活用した技術

デザイン・動画制作

アイデアソン: Miro
デザインスタイルガイドとUIデザイン: Figma
Adobe Illustrator（キャラクター、グラフィックの作成）
Adobe Photoshop（素材加工）
Adobe Premire Pro（動画編集・加工）
Adobe After Efect（モーショングラフィックの作成）

iOS

xcode 12.1/swift

Server

go v1.15.2
- echo/v4
- gorm
- realize
TypeScript
- NestJS
APIドキュメント: OpenAPI v3.0.0
モックサーバー: Postman
データベース: MySQL v8.0
コンテナオーケストレータ: Docker Compose v3
mBaaS 認証・認可基盤： Firebase Authentication
mBaaS DB基盤： Firebase Realtime Database
パブリッククラウド: AWS EC2
CI/CD： GitHub Actions

デバイス

ハッカソンで開発した独自機能・技術

チャット部分の実装においてライブラリでカバーできないカメラを利用した投稿機能,投稿ボタンと外部のpickerライブラリの連携を独自に実装した
GitHub Actions を利用して自動でテスト、デプロイできるようにした
OpenAPI を利用してAPI の仕様の共有を行った
Clean Architecture をもとに、テストしやすいディレクトリ構成で実装した

製品に取り入れた研究内容（データ・ソフトウェアなど）（※アカデミック部門の場合のみ提出必須）

なし

事前開発プロダクト

なし

f_2002_1's People

Contributors

Watchers

Forkers

ikemoti

f_2002_1's Issues

db周りのテスト方法

sqlmockというライブラリを使ってDBのモックを立てる？
モック部分はSQLハードコーディングっぽいが
参考

API と DB の雛形を実装する

次のドキュメントに従ってClean Architecture で実装する

Architecture

Clean Architecture
#2

APIのリクエストとレスポンスの構造体を定義するディレクトリをどこにするか

dbの定義を/entity/database
requestの定義を/entity/request
responseの定義を/entity/response

にする？

ディレクトリ構造を考える

./go配下はクリーンアーキテクチャを参考に構成

.
├── Makefile
├── README.md
├── api
│   └── openapi.yaml
├── database
│   ├── data
│   └── my.cnf
├── docker-compose.yml
├── docs
│   └── openapi_viewer
└── go
    ├── Dockerfile
    ├── entity
    │   └── model
    ├── go.mod
    ├── go.sum
    ├── infrastracture
    ├── interface
    │   ├── controller
    │   └── database
    ├── main.go
    └── usecase

APIのモックサーバーを建てる

postmanとopenapiを使って構築
webhookによりmainブランチのapi/openapi.yamlが更新されると自動的にpostman側も更新されるように設定

センサーデータを受け取るpostのエンドポイントを作成

#59 をもとにつくる

植物のチャットの応答仕様を決める

正規表現で抜き取るのか、特定のワードを指定するかなど

Firebaseの認証情報でユーザーの検証をするフローを確認

ユーザー登録時

ユーザー登録時にfirebase authenticationにも登録し、uidをデータベースに登録する

ログイン＆リクエスト時

クライアントでログインを行う
クライアントでログイン情報からIDトークンを取得する（cf）
クライアントからサーバーへのリクエスト時はヘッダーにAuthorizationキーを付け、IDトークンを付与する（cf）
サーバー側でFirebase SDKを用いてIDトークンからuidを取得する
uidでユーザーを特定する

新しく追加したテーブルに関する部分のormを書く

基本#60 に関するものについて書くことになるはず

DB構成を考える

ドキュメントはこちら

Firebase の環境構築開始

Firebase Functions のプロジェクト構築
Firebase へデプロイして正常に動作するかを確認
CI / CD 環境を構築する必要あり
Lint, テスト、デプロイがCI/ CD が自動で動作するか
デプロイしたものが正常に動作

iotの認証

仕様を決めてwikiに書く
コーディングする
https://github.com/jphacks/F_2002_1/wiki/IoT%E3%81%A8%E3%81%AE%E9%80%A3%E6%90%BA#iot%E3%81%AE%E8%AA%8D%E8%A8%BC

admin 設定を実装

デプロイ環境を作る

開発環境を作る

docker-composeを使ってdbサーバーとapiサーバーを立てる
makefileも作成
goのrealizeにより、コンテナ起動中でもgoを再コンパイル&echoサーバーを再起動してくれるように設定

Makefile

up:
	docker-compose up
down:
	docker-compose down
build:
	docker-compose build

iotからpostできることの確認

/plants/{plant_id}のレスポンスをfigmaのUIに対応した形で変更したい

修正対象

UIデザインの次の画面で表示される内容
- descriptionなどの設定を修正する

センサーデータをapiサーバーに送る形式の定義

決定事項をwikiに書く
https://github.com/jphacks/F_2002_1/wiki/IoT%E3%81%A8%E3%81%AE%E9%80%A3%E6%90%BA#iot%E3%81%8B%E3%82%89%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%81%AE%E9%80%81%E4%BF%A1%E5%BD%A2%E5%BC%8F

Firebase の仕様についての Wiki をまとめる

概要

Firebase のWiki について一通りの仕様を次の観点でまとめる

使用するフレームワーク
コマンドの一覧
ディレクトリの一覧
LISENCE

担当者

Okakyo

期日

2020/11/3

赤色、緑色、何もなしの3状態でホーム画面の植物側のメッセージの表示の仕方を変える

サーバー側での対応案

植物側のメッセージに緊急フラグを入れる
ホーム画面のチャットアイコンと植物のメッセージについて

赤色？：植物側の緊急フラグの入ったメッセージの後にユーザーが返信していない状態。ホーム画面のメッセージには緊急フラグを入ったメッセージを出す。
緑色？：赤色ではないが、新着メッセージがある状態。ホーム画面のメッセージには最新のメッセージを出す。
何もなし：赤色でも緑色でもない状態。ホーム画面のメッセージには、ホーム画面用のAPIに含まれる特定のメッセージを出す。

緊急判定について

緊急フラグが立っており未対応のメッセージのIDが積まれたスタックをサーバー側で用意する
スタックにはサーバー側で植物のメッセージをDBに入れるタイミングで、緊急フラグのあるもののときに積んでいく
スタックの要素数が0であればルームは正常状態、1以上であれば緊急状態
スタックを削除する用のエンドポイントを用意し、クライアントに叩いてもらう
特定のメッセージに対して対応ができるのであればIDを指定して1個ずつ削除、無理そうなら既読or返信するタイミングでスタックを空にする

フォーマットを考える
チャットのフラグのロジックを考えてwikiに書く
https://github.com/jphacks/F_2002_1/wiki/IoT%E3%81%A8%E3%81%AE%E9%80%A3%E6%90%BA#%E3%83%81%E3%83%A3%E3%83%83%E3%83%88%E9%80%81%E4%BF%A1%E3%83%95%E3%83%A9%E3%82%B0%E3%81%AE%E3%83%AD%E3%82%B8%E3%83%83%E3%82%AF
コーディングする

DBの構造対定義とクエリ実行処理の実装

やること

domain/entity/*.go にDBのテーブルをマッピングするための構造体を定義する
database/*.go にクエリ実行処理を実装する