この記事について
イベント「ミニアプリweek」でアプリを作ったので、基本情報、発生したエラー等をまとめました。
アプリの概要
-
アプリ名：観察日記
-
内容：ユーザーがたいせつに育てているものを記録していくためのサービス。
現在、開発途中。アルバムとして画像や日記を残したり、これからやることを書き記せるメモ機能等を実装予定。
なぜこのアプリを作ったのか
自分が植物を育てているので、その生長を記録したいと考え、作成した。
現在の主な機能
- ユーザー管理
新規アカウント登録、アカウント削除、ログイン、ログアウト - 投稿管理
投稿（タイトル、内容）
投稿の一覧表示、新規作成、編集、削除
使用技術
- バックエンド：Ruby 3.3.6 , Ruby on Rails 7.2
- データベース：PostgreSQL / Neon
- 開発環境：Docker
- インフラ・デプロイ：Render
- バージョン管理：Git / GitHub
- その他ライブラリ・ツール：Tailwind CSS
使用技術の選定理由
使用した技術は、基本的には学習中の言語、ツールである。学習した知識・技術の定着を図るため、日頃の学習で使用しているものを選定した。
また、Docker、Git等の技術は実務でも使用することが多いと認識しており、そういった実用性の面も考慮した。
主要なエラー
1. 環境構築〜デプロイ： Nodeのバージョン変更
(1) 概要
Nodeのバージョンについて、長期サポート版「v24.15.0(Latest LTS: Krypton)」に変更しようとしたが、デプロイ時にエラーが出た（一部ファイルの変更漏れのため）。
(2) 対応
実装時はやむなく、RUNTEQの参考ページに記載されていたバージョンv20.20.2に戻した。
イベント後、v24.15.0に更新した。
(3) 後日更新時の変更箇所
-
1．Dockerfile
- バージョンを24.15.0に変更
-
2．Dockerfile.dev
- 余分な"&&"を削除（構文エラーがあった）
- Node.jsのシェルスクリプトの重複箇所を削除
- Node.jsのシェルスクリプトのバージョンをv24に変更
-
3．package.json
- バージョンを">=24.0.0"に変更
-
4．test/fixtures/users.yml
- テストユーザーの登録情報がNULLにならないよう、登録情報を明記
-
5．RenderのEnvironment Variables
- 「NODE_VERSION 24.15.0」を設定（現在、Renderのデフォルトが24.14.1なので）
2. 実装中： 422 (Unprocessable Content)エラー
(1) 概要
ローカルにて新規登録したユーザーで、デプロイ後のブラウザからログインしようとした。
(2) 原因
開発環境（localhost:3000）と本番環境（Render）では物理的に異なるデータベースを使用しているので、登録情報等は共有されない。
→ (1)を試みると、登録されていない情報でログインしようとしたので、422エラーになった。
(3) 詳しく
config/database.ymlの中身で指定されている。
development:
database: myapp_development
production:
database: myapp_production
(4) 補足
各データベースに保存されているデータの確認方法は以下のとおり。
● ローカル
docker compose exec web rails c → User.all／User.count 等
● デプロイ後：以下の２通り。
- Neon上のダッシュボード → Tables
- Neon上のダッシュボード → SQL EditorでSQL文を打つ。普通のSELECT文でOK。
条件指定も可能だし、COUNT(*)でユーザー数の確認もできる。
3. 公開直前： 誰の記事でも編集できるようになっていた
(1) 概要
個人ブログのような機能になっているはずが、他のユーザー全員の記事を閲覧＆編集・削除できる仕様になっていた。
(2) 対応
投稿（posts）のコントローラのindex、edit、update、destroyアクションで「current_user.」と条件を指定する。
→ 自分の投稿だけを表示、編集できるようにした。
@posts(または@post) = current_user.posts.order(created_at: :desc)
(3) 補足
Gemfileの「gem 'sorcery'」中で定義されているから使える。
自分で定義してもいいが、gemを使う方が楽だし実務的、と認識している。
フィードバックから気づいたこと
1. UptimeRobotが機能していない
(1) 概要
アプリが見えてなさそうな感じがしたので、調べてみると、UptimeRobotのアプリのURLを間違えて設定していたことが発覚した。
(2) 前提、知っておくべきだったこと
Renderの無料プランは、15分でサーバーがスリープ（※）する。
※ サーバーのスリープ中はサーバーが動いていないので、リクエストの応答に時間がかかる。
（待ち続ければ応答される。ただし、すごく待つ）
(3) UptimeRobotの仕組み
任意のWebページのURLを登録しておけば、無料プランの場合は５分おきにUptimeRobotがアクセスしてくれる（監視機能）。
→ なんらかの理由でアクセスできなくなるとdownと表示され、メールで通知される（通知機能）。
→ この通知機能により、アプリ管理者は素早く障害に対応できる。UptimeRobotが勝手にトラブルを解決してくれるわけではない。
(4) 対応
URLの設定を修正すると、up状態になり、見えるようになった。サーバーでエラーが発生した場合等は、相応に対処する必要がある。
2. 改善案や考え方等 【メモ】
- 新規登録時のエラー文言
…この辺は見てなかった。ありがたく訂正する。ja.ymlで定義する？ - 画像の投稿
…実装予定。ひとまずActive Storageを使ってみる。 - カテゴリを設定できる（育てているものの種類等）
…使いやすそう。複数のものを記録する前提なので必要だと思う。
投稿時から分けておくより、タグの一種として実装するのがいい？ - ピックアップ機能（部分によって）
…いろいろとソートできそうで、面白そう。これもタグの一種にするといいのかも。 - 記録できるものを増やす（天気等）
…栽培管理的にもだが、メンタル面で「自発的に空を見上げる」のっていいと思う。
アイコンを選ぶ形だとスマート？ 作業メモの実装と一緒にできそう。 - アラート機能
…結構切実に欲しい。
アプリ内通知の実装方法から考えるが、デスクトップ、スマホにも通知したい。 - 豆知識が出る
…初心者向けイメージなので、これは自分も欲しい。2~3文だと気負わずに読めていい。
ソース元の選定だけ気をつけて、ヘルプと一緒に載せる？
ローディング時にランダムで出すのもいい？ - 他のユーザーの日記を閲覧する、「いいね」等の交流
…楽しそう。誰かの存在を感じられると嬉しいな、とフィードバックを見て気づいた。
閲覧は「.current_user」の絞り込みをいじれば実装できる？
フィードバックの受け取り方法について
RUNTEQ内のソーシャルポートフォリオで確認。
どんなフィードバックがあったか
「いいね」を含め、熱意にコメントいただけてハッピーだった。
GitHubの方も見てもらえて嬉しかった。いたたまれない気持ちもあり、もっとがんばっていこうと思えた。
フィードバックを受けて対応したこと
以下２点については作業中。
- バリデーションの注意文
- 画像投稿機能
そのほか、技術的に実装できるかどうかを含めて検討する。
苦労したこと・学び
422エラーが印象的だった。いつも開発環境で学習しているので新鮮。
データベースの違いについては実装終盤で気づいたので、結構時間を取られてしまった。
同じエラー名ばかり見ていると飽きるな〜と思った。
今後のアップデート予定
- 作業予定を記入できる、作業メモ機能
- 上述のフィードバックの関連
- デザイン全般
最後に
初めてミニアプリを開発しました。不安や焦りはありましたが、楽しかったです！
普段の学習では意識しない部分に着目でき、よかったなと思いました。
実装したいことはたくさんあるので、のんびりやっていく予定です。
見てくださり、ありがとうございました。
＊ 感想はnoteに書きました。