Closed10

個人開発01：ノウハウやメモなど

NekoAllergyNekoAllergy

stripeのwebhookはURLの指定があるので、先にweb側をデプロイする必要あり。
アジャイル的にも、いったん世に公開してそこから修正を加える方が理にかなっている。
ドメイン取得、cloud runデプロイ（簡易版）、独自ドメインマッピング、までを初日にできればGood

NekoAllergyNekoAllergy

cloudflareで取得したドメインをcloud runに直接ドメインマッピングしようとしたら繋がらなかった。
claudeに解決してもらったので、その証跡を残す↓

  問題の根本原因：

  1. DNSチャレンジの失敗 - CloudflareプロキシがGoogle Cloud RunのACME証明書発行プロセスを遮断
  2. SSL設定の不整合 - オリジンサーバーに証明書がない状態でCloudflare「Full」モード使用
  3. wwwサブドメインの未設定 - ルートドメインのみマッピング、wwwサブドメイン未対応

  成功した解決策：

  1. 一時的なSSL「Flexible」化 → DNSチャレンジを通す
  2. プロキシ一時無効化 → 直接的なDNS検証を可能に
  3. ドメインマッピング再作成 → 証明書発行プロセスのリセット
  4. wwwサブドメイン追加 → 完全なドメイン対応
  5. 適切なSSL「Full」復元 → セキュリティ確保

  重要な学び：

  - Cloud Run + Cloudflare では「Full」SSLモードが必須
  - 初回設定時はプロキシ無効 → 証明書発行 → プロキシ有効の順序が重要
  - DNSチャレンジとCloudflareプロキシは相性が悪い

特に、「初回設定時はプロキシ無効 → 証明書発行 → プロキシ有効」を今後守るべし。

NekoAllergyNekoAllergy

開発する順序を間違えていて、無駄や手戻りや発生している。よくない。

たとえばユーザ管理やデータ管理については、まずはCRUDするAPIを確立して操作できるようにする。
毎回UIから操作していたら手間だし、問題が発生した際、UI側のバグなのか、API側のバグなのかの切り分けができない。

安全な管理者権限APIを先に作っておくべき。

NekoAllergyNekoAllergy

「最初から外部DBに繋がずに、ローカルで完結できるように」という考えてやったのが今になって仇となってる。。

最初は外部の要素をなるべく入れずに、ローカルで完結させたかったから、firestore使わずに、ローカルのjsonファイルで擬似DB作ってた。
最初はそれで良かったが、いざfirestoreに移行した後も、なんだかんだその痕跡が残っていて、claude codeがそれをちゃんと（？）読んでしまって、変な実装になってしまっている、、　（firestoreとローカルjsonDBのハイブリット的な）

ちゃんと消したつもりだったけど、どうやら残っていたようで、今更になってバグが出てきた。

教訓：
最初からfirestore使えばいい。

別に50,000回/日くらいは無料だし、使い過ぎたところで絶対その枠は超えないし、、

NekoAllergyNekoAllergy

細かいTODO

  • セッション短い？
  • passwordのvalidation強化
  • 登録日：createdAtに修正
  • ソート機能
  • スマホの横並び表示時にChip非表示
  • メール認証
  • ユーザIDのuser-開始、習慣IDのhabit-開始　を統一
  • habitsを管理者権限APIでCRUD可能に
  • フッタのサービスセクションにマイページを追加
  • app-settingsはfirestoreでなくローカル変数に修正
  • ログイン/ログアウト/プランアップグレード/プランダウングレード時のスネークUI表示
  • launch.shエラー時に挙動変化
  • compose.ymlのenvironment必要？
NekoAllergyNekoAllergy

UI

  • tailwindcss/material icon　に統一
  • 通知はtoastに統一することを最初から明示的に伝えておく（開発時のデバッグもしやすい）
  • header/footerはnextjsのlayout使用
NekoAllergyNekoAllergy

おわった

  • passwordのvalidation強化
  • 登録日：createdAtに修正
  • メール認証
  • ユーザIDのuser-開始、習慣IDのhabit-開始　を統一
  • habitsを管理者権限APIでCRUD可能に
  • フッタのサービスセクションにマイページを追加
  • ログイン/ログアウト/プランアップグレード/プランダウングレード時のスネークUI表示
  • launch.shエラー時に挙動変化
  • compose.ymlのenvironment削除

これから実装

  • app-settingsはfirestoreでなくローカル変数に修正
  • セッション短い？修正
  • ソート機能
  • スマホの横並び表示時にChip非表示
NekoAllergyNekoAllergy

進め方とか気付き

claude codeバカになってる？

  • そんな気がする
  • 少し難しいタスクを与えると1発ではうまくいかながち。3ラリーくらいでパスする印象。
  • Proプラン（sonnet）だからしょうがないのかも。
  • でも前はもっと汲み取ってくれていた気がする。

開発初期のデータ管理

  • 開発初期からDBに繋ぐのはバグ発生時に切り分けが面倒&シンプルに進めたかった
  • ユーザデータや習慣データは最初はローカルにjsonファイルを置いて、そこを読み書きする方式
  • ある程度コアな機能ができた段階で、　firestore連携にした
  • 結論：後が面倒だからやらない方が良かった。
  • いざfirestoreに移行した後も、その痕跡が残っていて、claude codeがそれをちゃんと（？）読んでしまう

git戦略

  • 複数ターミナル起動
  • それぞれでclaude code立ち上げて細かい単位で区切った機能ごとに実装
  • 複数立ち上げてはいるが、同時実行はしない
  • 実装が完了したらgit status/diff/checkout/add/commit/push/pr/mergeしてmainと統合
  • 終わったターミナルは削除
  • 感想：個人開発ならブランチ切って実装とかがあまり効果ないかも。

初めてやってみたこと

  • stripe決済のあれこれ
  • cloudflareからドメイン取得、dns/cdn機能使用
  • 独自ドメインをcloud runにマッピング

次回改善点&効率化できる項目

  • stripe / firebase auth / firestore / claudeflare 周りは今回で理解が深まったし、今回作ったコードの環境変数を変えるだけで流用できるから爆速なはず
  • stripe決済はサンドボックスで正しく機能することを確認してから本番へ移行する
  • 「本番環境に楽に移行できるように」の考えが強すぎて、途中からnpm run devを使わずに、npm run build / startを使っていた。その分ビルド時間が無駄だった。npm run devでコア技術を実装して、終盤からnpm run build/startの運用にする
  • firebaseとの通信部分など、APIが不揃いな状態でUI実装や各種詳細処理の実装を進めてしまったから、無駄や手戻りが生まれてしまった。機能実装の前に、ユーザやデータのCRUDができるAPIや管理者だけが実行できる強APIを充実させておく。
  • 重要度が低い機能ばかり実装して、後から必須機能の追加などをする謎ムーブかました。もっと初期でMVPを確立し、その時点でcloud runにデプロイしておき、その後に詳細機能の実装をアジャイルに進める
    今回は日本語で設計したが、次回は英語にしてみたい
このスクラップは25日前にクローズされました