具体的に作ったもの
ログイン対応できたら、現在私がHostingしているサイトのURLを掲載します！
動作例
レスポンシブ対応させました！
全画面動作（PC）
全画面操作（スマホなど）
技術スタック
Clean Architecture対応！
Domain -> Usecase -> Adaptor -> Interface -> DI
以上の流れに対応したClean Architectureを用いて設計しました！
ですから、機能追加などの影響範囲を最低限に抑えながら、安定した挙動を支えています！
最も力を入れた箇所です！
Flutter
基本動作は、すべてFlutterWebを用いて作成しています。
そのため、SPA形式となっておりPWAに対応しています。
コンパルは、WASM方式ではなく、従来の方式で行なっています（パッケージなどの不具合のため）。
video_player
動画の表示には、video_playerを利用しています。
この採用理由は、web版での対応実績が豊富だったこと、networkUrlを用いた再生に対応していたこと、
バッファリングなどの自動管理の機能があったこと、などがメインです！
Riverpod + GetIt
GetItを用いたシンプルなシングルトン管理及び、初期化処理を実現しました。
Riverpodを用いた安定した、状態管理を実現しました。
また、Family ProviderやRiverpod Generatorを用いた型安全な状態管理を実現しました！
使い分けとしては、シングルトンが求められる基盤技術のインスタンス管理、基盤技術を直接利用するインターフェースのDIのために、GetItを利用。
それより上位層での状態管理や、DIにはRiverpodを利用。
GetItとRiverpodの組み合わせ方はAppFlowyのコードを参考にしました！
AppFlowyのGitHubはこちら
Freezed
Freezedを用いた、型安全なエンティティ管理を行いました。
また、JsonAnnotationなどを持ちいて、Jsonへの相互変換を実現しました。
GoRouter + go_router_builder
画面の遷移処理には、Navigator 2.0を反映したGoRouterを活用。
また、それらのルーティング情報の構成にはGoRouterBuilderを利用し、
遷移画面が多い本アプリにおいて、型安全な画面遷移を実現しました。
auto_route などはルート情報生成がないため、採用を見送りました
import_sorter
デプロイファイルのリファクタリングのために利用しました。
Cloud Storage for Firebase
オブジェクトストレージを利用することで、スケーラブルな動画投稿を支えます。
実際に、どこからでもアクセス可能かつ、無料枠豊富、従量課金性であるため、非常にマッチしていました。
セキュリティルールは書きませんが、認証済みアクセス以外は弾くようにしています。
CORS設定に注意！
Firebase Auth + Firebase AppCheck
Storageへの以上アクセスを防ぐために、AppCheckによるreCAPTCHAv3に対応させています。
Firebase Hosting
このアプリのホスティングはFirebase Hostingを用いています。
今後独自ドメインに対応させる予定です。
このアプリの注目ポイント
字幕の連動表示を可能にしている点
動画の再生秒数に合わせ、表示したい字幕や、表示したいサムネイルを自動調整できます！
また、表示部分にはAIを利用していないため、一度の字幕生成で、AIのトークンを消費することなく、
永続的に字幕機能を利用できます。
独自の動画投稿プラットフォームを、Firebaseに登録するのみで、セルフホスティングできること。
これが最も大きい点だと考えています。
サークルや、部活動などで動画を共有したいが、Youtubeなどにアップロードするのでは、機能的に不満だという、場合において活躍することがあると考えています。
なんでこんなめんどくさいことをしないといけなくなったか
遡りますと...
動画提出の課題が出た
ですが、自分には、動画をこだわる力はありませんでした...
動画投稿とか編集ってやったことなかったから...
動画は作れないけど投稿手段なら作れるんじゃないか！？
今回の課題は、動画の完成度もさることながら、動画にIT技術を組み合わせることが大歓迎だという話を聞いていました！
なら、組み合わせるIT技術として動画投稿プラットフォームの作成を加えよう！
と思い立ったわけです（成績はちゃんと確保しておきたかった）！
今回の課題・制約
今回の課題・制約は、次の3つを定めました。
- 期間内で絶対に完成させること（動画も、動画投稿プラットフォームも）
- 動画投稿プラットフォームはWebの形態にして、採点担当の方がアクセス負担を減らすこと
- クラウド対応型のプラットフォームにすること
解決手段
自分のしたいことと、やらなければならないことが混じった課題・制約に対する手段としては、次の3つを定めました。
- 自分がすでに比較的知っている技術を使う
- VibeCodingを前提とする
- デザイン以上に、課題提出の場面で確実に動かす
という手段を取ることにしました。
困った点
字幕データの生成がめんどくさすぎる
タイムコードと合わせてデータを生成しないと、動画上の動きに同期しないのがあまりにも大変。
動画編集ソフトの字幕データをからコンバートできるようにするとか、AIとの同期手段とかを考慮する必要があると考えてます。
採点者に向けたアプリなので、ログイン機能などをつけられない
早くみてくれたら、その機能を追加してデプロイしたいです。
Cloud StorageへCORS設定をしないといけない
Webアプリの作成初心者すぎて、CORS設定のことを完全に忘れていました。
Firebase HostingがFQDNを発行してくれてよかったです。
HTTPS対応も自動で行なってくれたので、非常に楽でした〜！
Clean Architecture ファイル分割数多すぎ
細かな関心分離が気ものアーキテクチャですが、そのためにファイル分割をしていたため、最終的に自動生成ファイルを含めて、アホみたいな量になりました...
あと、IDEの悪いところなのかもしれませんが、フォルダーのソート順がめちゃくちゃわかりにくい。
Clean Architectureって1方向のアーキテクチャなので、フォルダごとに矢印が向いてます。
つまり、順番が決まってると思ってるのですが...
IDEは、そんなこと考慮せずにアルファベット順で並べ替えるので、コーディング中に行ったり来たりして大変でした。
状態管理が大変だった
大変だった代わりに、Provider最強っていう、Flutterの思想に辿り着けたのでOKです！
（ConsumerWidget最強！ref.refreshとかref.invalidate最強です）
結論
とにかく時間がない中での設計、実装でしたが、AIとのVideCodingの成果もあってか、なんとか、完成まで持っていくことができました。
特に、デザイン面でのAIの尽力は凄まじかったです。
設計や使用技術の選定、コア部分の動作決定に関しては、一日の長があるかなと感じる場面もありましたが、よく使われるようなデザインの当てはめといった作業は、もう勝てそうにもありません。
優秀な部下ができたような感じで幸せでした。
あと、最近名前を変えて登場したAntigravity CLIかなり優秀です。
この子を使うために、Googleが開発したFlutterとClean Architectureを開発アーキテクチャに選定したのですが、本当に優秀ですね。
これまでのAIは、Riverpodなどのコードが古い（StateNotifierなどをベタ書きしていて、Generatorなどを使おうとしてくれない）という問題がありましたが、完全に新しい書き方を習得しているような感じでした。
さらに、文法エラーや、構造的なエラーなどが非常に少なく、コーディングを進めることができました（flutter analzer優秀）。
影響範囲を少なくしながら/planningモードを用いて、ハーネスを敷いてやると、かなりの精度でAIはコードを書けるのだとつくづく実感しました！！