趣味で開発したWebアプリケーションの私的まとめ ~その3~
これまでに趣味で3つほどWebアプリケーションを開発しました。その当時を振り返りながら、まとめていきます。
開発したWebアプリケーション
-
クリエイターサポートツール(zennの記事)
SUZURI APIを利用し、商品情報を取得、商品画像からSNS用のPR画像を生成できるアプリケーション - BECCHU(zennの記事)
あらかじめ登録されたデザインを選択し、色を自由にカスタマイズしてTシャツを作成できるWebアプリケーション - BUMESHI!!
美味しいものを共有する飲食店レビューサイト
今回はBUMESHI!!について、まとめます。
BUMESHI!!
ソースコード
開発動機
飲食店を探す際に、ネットで検索を行うと、飲食店へのネガティブなレビューを見かけます。しかし、実際にお店にいくと、美味しいし、接客もサービスも良いじゃん!!!!っていう経験をしています。これってなぜ起きるのか...と自分なりに考えて以下のようにまとめました。
- そもそも、良い飲食店の基準が人によって違う
にぎやかなお店を良いとするか、静かに食べれるお店を良いとするかなど - お店への嫌がらせとして低評価なレビューをする
以上を解決するために、おすすめの飲食店を友人間で共有する飲食店レビューサイトを作ろうと考えはじめました。
公開範囲として、友人など絞ろうと思いましたが、APIの関係で公開することになりました。
そしてFlutterで開発をはじめたのですが、一部機能がWEBでは非対応であったためRuby on Rails で作りなおしました。
目的・目標
『気の合う友人や家族間でおいしい飲食店を共有するアプリ』
開発動機から、この目標になりました。
アプリケーションの命名
もともと、作成したアプリケーションの公開範囲として、高校時代の部活のメンバーを想定していたため、部活動のメンバーといくご飯から部飯で「BUMESHI!!」となりました。末尾の!!はフォークやスプーン、箸に見えるかなという理由で付けました。
デザイン
色は飲食店が関連するサイトであるため、食欲減退色などの青色は避けました。料理などの画像が表示された際、一番料理をおいしく見せるためにはどの色がいいか検討していました。緑色は葉物や野菜をイメージさせ、苦みなどを感じそうなので却下。最終的に、オレンジか赤になりましたが、Flutter版BUMESHI!!との違いをだすため、赤にしました。
各要素はできる限り、角を丸くして優しく、親しみやすい雰囲気になるようにしました。
言語やインフラの選定など
- 言語
- Ruby
気になっている会社のインターン応募条件にRuby on Railsの開発経験とかいてあったので、Ruby on Railsで開発しました。 - html, scss
- Ruby
- フレームワーク
- Ruby on Rails
言語のところで記述した通りです。 - Tailwind
聞いたことはあるが使ったことがなかった(PostCSSの互換性に伴い導入時に苦戦しました)
- Ruby on Rails
- データベース
- MySql(開発環境)
AWSのCloud9がMySQLが標準で使えるため - PostgreSQL(本番環境)
herokuを使用するためと、uuidを使いたいためPostgreSQLを利用しました。
- MySql(開発環境)
- インフラ
- heroku
Ruby on Railsが動作するサーバーを持っていなかったため、Ruby on Railsが動作するherokuを検討しました。インターン応募までに公開する必要があったため導入のしやすさからherokuに決定しました。 - AWS S3
飲食店の画像、レビューに添付された画像の保存に使用。AWS Cloud9を開発環境として利用したため、請求をひとつにまとめておきたかった。OGPにも使用しました。
- heroku
- APIなど
- ぐるなび API
お店の情報を取得するために使用しました。ドキュメントのなかに、アプリケーション開発者が管理するデータベースならばAPIで取得したデータを保存してよいと明示されていたためを利用(2021年月16日にAPIの提供終了😭)。
飲食店向けのものだとホットペーパーAPIがありますがそのような内容が明示されていなかったた利用しませんでした。
- ぐるなび API
- 認証
- Google OAuth
友人が全員がGoogleアカウントを持っており、ユーザー登録が楽にできる。
- Google OAuth
- 開発環境
- Cloud9
友人と別アプリケーションを開発する際にCloud9を使う予定だったため、慣れるためcloud9で開発をおこないました。
## 使い方
美味しいお店を共有する
- 上部のメニューのお店を登録から、登録したいお店の名前や住所を入力する
- お店の候補が出てくるので、登録したいお店を選択する。(候補にない場合は手入力で登録するを押す)
- フォームに入力して登録を押す
コメントをする
- コメントを投稿するボタンを押す
- フォームに入力して、投稿するボタンを押す
お店の登録フォーム
お店の検索結果
お店の検索画面が表示されます。ぐるなびAPIを利用して検索し、飲食店が表示されます。
ここから登録するボタンをおすと、必須項目の一部を自動的に入力してくれます。
上記のようなお店の登録フォームを実装しました。支払い手段、駐車場は友人に欲しいといわれたので追加しました。
できる限り、入力する手間が省けるようにしました。
開発で難しかったこと
データベース関連
初めて友人に見せたときにはユーザーIDとパスワードを入力し、新規登録する方法でしたが、ユーザー登録の簡略化を行うためGoogleOAuthを利用することにしました。それに伴い、データベースの修正を行う必要があり、大変でした。
多対多のテーブルを定義する際に、中間テーブルの作成が必要ありますが、中間テーブル自体を初めて知ったので、学びながら実装していきました。
開発環境と本番環境の差異
開発環境で動くのに、本番環境だと動かない!!ということが多発しました。herokuのログをみて修正をしていきました。修正後、動いた時には達成感がありました。
開発していた楽しかったところ
OGPを設定する
OGPを設定しました。Twitterでシェアすると登録された画像も表示されるようにしました。
初めてやったので楽しかった。美味しそうな画像がTwitterに表示されるのはリンクだけよりも視覚的に訴えることができるのでよさそうでした。
投稿して情報を増やしていく
今までは完成した形のWEBアプリケーションだったのですが、今回はレビューの投稿機能があるため、テストの時に実際に投稿してサイトを充実させていくのがたのしかったです。
このとき学べたこと
-
データベースには中間テーブルというものがある
データベースの設計時は中間テーブルなどを気にしなかったが、実装していくうえで、多対多の時は中間テーブルが必要なことを初めて知りました。 -
ログをみて修正
コンソールに表示されるエラーコードや文言からコードを修正してくのはC++等ではやったが、クラウドサービスのコンソールからのログをみて、修正していくのは初めてでした。
今後
- ぐるなびAPIが提供終了になったので、変更する
- レビュー数に応じて、お店がランクアップする
ユーザーがレビューをすると、レビューの内容に関係なくお店のスコアが溜まり、お店がランクアップするシステムを考えています。従来だったら、平均評価を表示しますが、お店のランクアップというシステムにすることでネガティブなレビューをすくなくすることができるのではないかと考えています。
最後に
アプリケーションを作るごとに新しいものを取り入れるということをしていたので、できることが徐々に増えていくのがよかったです。
クリエイターサポートツールを作成下の時には、画像投稿する機能はセキュリティ面から実装しなかったのですが、最終的に画像を投稿できるようなシステムを作成できたのは成長を感じれたので良かったです。クリエイターサポートツールの開発が2020年7月だったので、そこから半年でここまでできるようになりました。今後はフロントエンドに挑戦していきたいと思います!!
Discussion