筋トレログ管理アプリ_作成過程
_ikarigataやりたいこと
- 勉強のためになにかしらWebアプリを自作したい
- 学習や制作の過程を簡易的にログとして記録していきたい
_ikarigataテーマ選び
これまで何度か個人開発に挫折した経験から、『モチベーションの維持』がもっとも重要だというのは痛感していて、そのために必要なことはおそらく以下の3つだと考えた。
- 2,3ヶ月程度の期間で作りきれるものにする（長いと飽きる&作っている間に技術がアップデートされて不安が増す）
- 自分の興味がある題材にする（なけなしの余暇時間を興味がないことに割き続けるのは難しい）
- ユーザーにとっての価値が想像できるものにする（使われるイメージが持てないと要件定義・外部設計がそもそも難しい）
上記の観点から、ふだん自分が何となくで入れた無料のアプリを惰性で使い続けている「筋トレのログ管理アプリ」に目をつけた。
使っていて「もう少しここはこうなったらいいな」という細かい不満はあるのできちんと作れば少なくとも自分は喜んで使うだろうし、基本機能としてどんな機能が必要かも分かっている。
かつドメイン知識についても既に把握できていて、そこまで複雑ではないことも分かっている。
ありきたりなテーマではあるが、今の自分にとってはフィットするように思えたので今回はこれをテーマとしてみる。
_ikarigata技術選定
・フレームワーク依存を少なくしたい
・新しく学ぶ技術の量を絞るため、どこかには自分が既にある程度知っている技術を採用したい
・スタイリングは楽にしたい
・「状態管理ライブラリ」というのを使ったことがないので、その是非を探るためにも触っておきたい
なんとなく上記の理由から選定した。
-
フロント→vite+react,tailwind,zustand（触ったことはあるがしっかり使ったことがないreactを使いたい、create-react-appは非推奨となったのでそれを除いて最もシンプルそうなviteで）
-
バックエンド→springboot（ある程度業務で使用している既知の技術）
_ikarigata技術選定（ORM・クエリビルダー）
いままでは「SQL書いたほうが早いでしょ」くらいの軽い気持ちでORMに手を出せていなかったが、もろもろAIに任せてコードも書いていくなら余計SQLも型安全に実行したい+不正なSQLを紛れ込ませないための仕組みがあった方が良い、と考え、JooQというjavaライブラリを採用することにした。
_ikarigata5/21追記
余計な学習コストを減らすため、いったんJooQの採用は後回し。
_ikarigataboltに投げてみる
UIイメージを掴むため、まずはbolt.newに依頼してサンプルを作らせてみる
以下の気付きを得る。
・タブは下にあったほうがいい
・頻繁に行う入力パターンでタップやスクロールの手数が必要最小限になると嬉しい
・トレーニング種目の情報を追加・編集したいことはそんなにない
_ikarigataドメイン知識を整理①
最初はboltに作らせたものをベースにバックエンドを作ろうとしたが、途中で「それって絶対UIにバックエンドが依存するな」と気付き、まずはドメイン知識を整理することに。
以下をclaudeに投げた。
本アプリの設計上重要となるドメイン知識について以下に記載します
不明点等あれば指摘してください
---
- トレーニング種目は複数ある
- あるトレーニング種目では、1つ以上の身体の部位の筋肉を鍛えることが出来る。これをそのトレーニング種目の対象部位と言う
- トレーニング種目の対象部位にはメインの対象部位とそれ以外の対象部位がある
- 対象部位は、およそ身体のどのあたりの部位かによってグルーピングできる
例えば、三角筋前部・三角筋中部・三角筋後部はすべて『肩』の種目
- ユーザーは様々な日にトレーニングを実施する
- 1回のトレーニング実施では様々なトレーニング種目を実施する
- ある種目のトレーニング実施では、複数セットを実行する
- ある種目のトレーニングでは、一種類のトレーニング種目だけを行う
- 1つのセットは重量(kg)とレップ数(挙上回数)からなる
- 重量とレップ数を積算した値をボリュームという
- あるセットのボリュームの合計値をそのセットのボリュームとする
- すべてのセットのボリュームの合計値をそのトレーニング種目実施時のトータルボリュームとする
- 筋肥大においてはこのトータルボリュームを増やすことが重要とされている
- そのためトレーニングのログを管理するうえではこのボリュームの推移も重要な指標となる
ドメイン知識を整理②
claudeと壁打ちして整理した結果、以下を得る。
_ikarigataDB構造
整理したドメインの内容をもとにDB構造を以下のような形にした。
_ikarigataapi仕様を作る
DBやドメインの整理ができたので、それに合わせてapi仕様をclaudeにつくってもらった。
_ikarigataバックエンドを作る
claudeのプロジェクト機能でドメイン内容やDB構造、api仕様書を共有したうえでバックエンドを実装してもらう。
_ikarigataフロントエンドを作る
同様にフロントもclaudeに作ってもらう
_ikarigata動かしてみる
フロントとバックエンドそれぞれを立ち上げてアプリとして動きを見てみる。
→トレーニングの追加時点で早速sqlの文法エラーになるが原因分からず…（5/21現在）
_ikarigataFigmaを学ぶ
claudeに作ってもらったUIがそこまで好みではなかったので細かくカスタマイズしたい、となった。
いじるにしてもいったん自分の中で目指すUIを固めてからコード修正に入りたいな、となりFigmaでプロトタイプを作ってみることに。
いったん手始めにyoutubeで入門者向けの動画を数本見た。以下のような学びを得た。
- Figma自体は覚えることはそこまで多くはなさそう
- 最初から全部の機能を使いこなす必要はない
- 基本はフレームやテキストを置いていくだけ
- オートレイアウトとコンポーネントを積極的に使うと変更しやすいデザインになる
- プロトタイプ機能を使うと画面遷移付きのイメージが共有しやすい（→自分が今回作るべきはこれ）
_ikarigataFigmaでプロトタイプを作ってみる①
だいたいの使い方を学んだので、自分なりに作りたい形のイメージを作ってみた。
まだまだ途中だが、実際に手を動かしながら作ってみることで『自分はどういうUIを欲しているか』がより具体的になった気もする。