本当は開発を始めたところから記録をつけたかったのですが、書いている時間がとれませんでした。
というわけで、きのこたけのこ戦争、もとい「SNS」の開発記その１は、振り返りをメインとします。
バトルロワイヤル要素のあるSNSをつくってみっか
世界崩壊少女の開発も妻のサイト制作もひと段落して、次は何をつくろっかなと思いながらなんとなーくログイン処理というものを作ってみたのが始まりです。その頃、スマホからFTPに接続する認証方式をSFTP接続にする為にアプリの乗り換え先を探していて、その時の接続処理で手こずったので、１日中ログイン処理について考えていたってのもあるかもしれません。明確な制作意図があったわけでもなく、ほんとにふわっとした気持ちから始まりました。
自分がSNSをつくるならこんな感じがいいなっていう構想はずっと以前から頭の中にありました。自分が気に入らないユーザーをどんどん追い出せるバトロワみたいな仕様があると面白いですね。
訓練校でWEBコーディングを学んで、世界崩壊少女の開発を通してAIコーディングにも慣れてきたのもあって、認証処理の仕組みはなんとなくわかりました。
この時はただのテストで、IDとパスワードはtxt管理でした。サインアップページやメール認証なんかもまだまだありません。
ある程度かたちがみえてから正式な仕様を考え始めて、最初は運動会みたいに赤組白組に分かれているSNSを考えました。サインアップ時に好きな組を選んで、タイムラインは自分の組のポストしか見れない感じ。で、ゲーム的な対戦要素のあるSNS。
その仕様をどうやって実現しようか考えながら全体のレイアウトを考えている時に、アイコンの仮画像として使っていたのが、だいぶ前に妻が描いたきのこの絵でした。
きのこといえば、たけのこですね。
じゃあ戦争するしかありません。戦争はローマ字にするとSENSO。ちょうどSNSという字が隠れていますし。
こうしてバトロワ→運動会→きのこたけのこ戦争という方向性の転換があり、現在のきのこたけのこSNSを開発することになったわけです
これが５月２０日〜２２日あたりの話です。
データベースってなんやねん
きのこたけのこSNSにするならユーザーは王国民だよね。じゃあ買い物できるショップがある、SNS内通貨がある、お金を稼ぐ為のワーク（ミニゲーム）がある、GDP要素もあればよりリアルになる、じゃあ投資の要素として文明の提案、実現とか……などなど、必要な要素を整理して、ChatGPTに全体像を伝えつつ処理の追加をはじめたところ、すぐにデータベース管理にするべきだと提案されました。
最初はどういう意味かわかりませんでした。世界崩壊少女のサイトでみなさんから投稿していただいたデータはdb.chatというファイルに収めています。txtファイルと違ってクリックで開いてみることはできません。SNSのポストの管理もそういう性質のファイルがいいだろう、という単純な発想で、「SNSのポストの管理もこのDBとかいうファイルと同じ仕様にして！」って感じでChatGPTに指示をしていたんですが…………、はい、エンジニアの方はもうおわかりですね
この頃の私は、MySQLやSQLiteというデータベース管理のことをよくわかっていなかったのです。世界崩壊少女でdb.chatというファイルをつかっていたのも、当時の開発中、ChatGPTに提案されるがままやっただけでよくわかっていないままでした。
DB？ MySQL？ SQLite？ ChatGPTの回答に出てきた単語を１つずつ調べていくうちに、自分が知らない間にSQLiteのファイルで管理していたことをようやく理解しました。
データベースはtxtと違いテーブルの概念を持ち、トランザクション制御（複数の同時書き込み）にも対応できます。複数のユーザーの操作からなる無数の処理に対処するにはデータベースじゃないと捌けません。
そして、WordPressもインストール時にMySQLを使っていたことに気づきます。（Lolipopだと使います）。「あぁ！ そういえばwordpressもMySQLでなんかやってたわ！」ということでデータベースの役割や使い所を学び直し、自分のSNSでも使うべき理由が理解できました。
実際にやってみると……データベース管理は面白い！
こういうのだいちゅき！
テーブル構造を考えるだけでご飯三杯はけますね。
アプリファクトリーってなんやねん
きのこたけのこSNSは世界崩壊少女と同様、Flask環境で構築しています。なのであらゆる送信（アクセス）に対してバックエンドではPythonのルート処理が走り回るわけです。
が、投稿処理、ショップ、ワーク、インベスト、セッティングなど、あらかた処理の実装ができたところで、ChatGPTが「今こそアプリファクトリーにしましょう！」と、またよくわからないことを言ってきました。
アプリファクトリーとは、保守性や拡張性に優れた Flask の開発手法で、中〜大規模のアプリケーション開発でよく採用されます。
通常の構成では「アプリが最初に起動し、ルート処理が呼び出され、即座に処理へ進む」という流れです。サンプルコードなんかだとそういう長れですね。
一方、アプリファクトリー構成では、まず def create_app() 関数が呼ばれ、その中でアプリを作成・初期化し、ルート呼び出しや設定を登録したうえでアプリを返します。つまり、「関数 → アプリ起動 → ルート呼び出し → リクエスト処理 → レスポンス」という流れになります。
私もまだ完全に理解してませんが、ノンファクトリーだと即ルート処理で、最後のリターンまでの間しか手が出せません。一方ファクトリーならルート呼び出しの前後にさまざまな処理を加えられる、と思っておきましょう。
これがまぁ、最初の難関でした。言われた通りにコードを差し替えてもうまくいかないので、まずアプリファクトリーの最小構成サイトを別につくり、仕組みを理解して、それからChatGPTの提案コードを元に環境のファクトリ化をしていきました。
気がついたらできてた、という感じなので具体的なな作業の流れを説明できないが残念ですが、とにもかくにもこういうのは最初の段階でやっておいたほうがいいと思いました。
ひたすらコツコツ
アプリファクトリー化が終わった後は、大きな緩急もなく、ひたすらコツコツ処理を付け足していったという感じです。
処理を追加するぞ→必要なテーブルあるか？→なければ追加→参照はあっているか？→テスト→最初に戻る……
この頃になると、ChatGPTへの指示さえ的確であればエラーが出てもだいたい、ルートか変数かテーブルの参照が間違っているだけのことがほとんどで、「それだけ自分は単純なものを作っているんだな」というモチベの上がらないムードの中で開発を続けました。
６月２４日に障害者就職説明会があったので、その時にポートフォリオとして見せられるようにと、とにかくオープンβテストが開始できる状態まで仕上げることが最優先でした。登校中も訓練校の休み時間も下校中もスマホ開いてChatGPT→質問→コード修正を続け、帰宅後も飯とトイレと風呂以外はひたすらコーディング。このわからないのにわからないと思ってる暇がないまま進めている感じ、悪くないです。
現在と今後のこと
現在はオープンβテストをしながら細かいところを修正しているフェイズです。
最近だと、
- ポストカードの日時がUTCだったのでJTCにした。
- AP回復処理を修正
- 王国ステータス処理の修正
と、テスト開始前の時点で見つけられなかった不具合を修正しました。
今後もしばらくはオープンβテストを中心に更新作業をしていきます。
あと開発開始からテスト開始までの関連ポストを棘にまとめたので、気になる人はこちらもお読みください。
コメント