[AIB 7]Section 3プロジェクトレビュー

今日の第3部プロジェクトのフィードバックはやっと終わりました.驚いたことに、すでに3ヶ月ほどのスタートキャンプが過ぎていました.こんなに早く3ヶ月が過ぎたのに...?作り心地がする

Section 3 Projectのテーマは？

私が作ったプロジェクトのテーマは「たぶんこのようなゲームをして、人々がどれだけ関心を持っているかを見てみましょう」です.こんな感じなのでサービスの名前が付けにくいので最終発表時に私が発表するテーマもそうですそして発表ビデオを撮って、みんなサービスにいい名前をつけてくれたので、もうちょっと頭を動かして、ちゃんとした名前をつけてあげるべきだと思い、少し後悔しました.良い名前が付けられていなかったので、発表動画を作成する際も下記のようにしました.

プロジェクトの説明

まず、プロジェクトの意味はパイプライン全体を体験し、できるだけ簡単にすることです.簡単に作って、パイプライン全体を体験したいです.もちろん部分的には一度経験したこともありますが、一から十までエンコードしたときに体験したほうがいいと思います.まだあります.この部分では課題も挑戦試合も3点を獲得しているので、種目も3点を獲得したいという欲求があります.届くかどうかはわかりませんが.😅 受け取ったら自慢しに来てね.

データのインポート

1つ目は、APIを使用してデータを受信することです.RAWG APIを使用しており、一見データの入手が容易で満足しており、認証鍵の配布も早かったのでこのAPIを選びました.問題は、カテゴリデータが多すぎても...!たくさんあります.また,ジャンルやタグデータ部分で重複文を用いて0番目または1番目のデータをもたらすのは,「Action」または「Singleplayer」が出現したためである.

これを克服するためにrandintを用い,ランダムに題材とラベルをもたらしたが,データの範疇は幾何級数的に増加し,最終的にラベルの長さは400を超えた.そしてラベル部分には「Steam」というラベルが付いていますこれはゲームの紹介に役に立たないラベルです.
なぜゲームの紹介に役立たないと思うのか、暖房はダウンロードやゲームを手伝う場所です.テーマはまず「ゲームを作る前」段階、「アイデア」段階です.しかし、暖房はすでに発売されているゲームを売っている場所で、私が作ったモデルの勉強には役に立たないと思います.また、あるゲームを紹介したときに「このゲームはスチームチームで人気がある」と言ったらどんなゲームですか?答えが戻ってくると思った.ゲームに全く説明力のないラベルだと思っていたので、自分の考えでif文で導入したラベルにsスチームが含まれていたら、再びランダムに数字を抽出してラベルを導入したのですが、思ったほどうまくいきませんでした.
プロジェクトビデオを提出して考えてみましたが、いっそラベルをリストとしてランダムに抽出し、ラベルがs蒸しであればリストから削除してランダムに抽出すると、ラベル部分でs蒸しが著しく減少するのではないでしょうか.そう思います.これからも時間があれば、チャレンジしてみることにします.

データ・ロード

私はまずAPIで持ってきたデータをパンダでデータプリプロセッシングしてMongoDBに入れます.MongoDBを選択したのは、後でDashboardにサービスを利用しているユーザーが入力したデータを表示するためです.SQLiteでデータを入力すると、ユーザーが入力したデータがリフレッシュによってダッシュボードの内容が変更されません.

データプリプロセッシングとモデル学習

データの前処理は分類データを主とする.まずタイプ部分Top 9が選択され、9種類と残りのタイプに設定され、タグ部分も同じ設定に設定されています.

また、待望の前処理TAG...どう見てもおしまいだと思っていた.実はそれもSteam Achivementsタグが少なくなれば信用できるのでしょうか?もともと三千ぐらいあったのですが、データを持って帰って、上記のifゲートでフィルタリングして、二千四百ぐらいに減らしました.ここからモデルの性能はおしまい…もう少し時間をかけたかったのですが、すでにAPI探索&選定が始まっていて、データを持ち帰り続けているので、時間が足りず、このように行いました.
そしてR 2 scoreを撮って絶望に陥りました.

これを見終わったら、データを持って帰って、前処理をやり直して、コードを考えなければなりません.と思います.そこで、これまで行ってきたコードをすべて修正し、category encoderを探し始めます.
実は、私が知っているのはonehotとtargetだけなので、私は三七二十一地にかかわらず試してみましたが、targetに符号化したときR 2 scoreが一番よくて、最後にtargetに決めました.
しかしながら、ターゲットエンコーダは、符号化時に、同じ数値を有する2つの異なるデータを同じ数値で表すという欠点がある.幸いなことに、同じ数値のデータがないので、このように書きましたが、ターゲットエンコーダを使うときは注意しなければなりません.


何度もデータを再インポートし、前処理を再実行し、APIがブロックされ、データをインポートできなくなったらどうするか心配です.だから現実と妥協することにした.時間も足りないし、また持ってきたときに詰まると、大きな後ろめたい気持ちになり、0.1から0.32に上がり、洗脳しながらモデルの調整をしながら、幸せだと言います.

Flask & heroku

Flaskでは、これは小さなエラーで、ほとんど記憶に残っていないエラーで、Herokuに配備されたときに問題が発生しました.

! [remote rejected] main -> main (pre-receive hook declined)

私は間違った情報を見て、最初はこれしか見ていませんでしたが、本当にこれが何なのか分かりませんでした.私は約2時間かけて真剣にグーグルゲームをしました.でもダメだったので、その時は夜12時過ぎだったので諦めましょう、あ、ここまで、明日にしましょう!でもいつも思い出して眠れないだから3時くらいに寝ようと思ったら、眠れなくてノートパソコンを再開しました.そして私はまたゆっくりと間違った情報を読んで、これを見ました.

Failed to find attribute 'app' in 'flask_app'.

web: guricorn --workers=1 'flask_app:create_app()'

元はフラスコアプリの中のアプリpyとtemplatesフォルダしかないので、Procfileを書くときも「flask app:create app()」ではなく、flask app:app:appに設定していましたが、googlingをしているとappが認識できないというコメントがいくつかありました.なのでアプリに設定して試してみたのでアプリで試してみましたが認識できず、結果コードはinit.pyとmain views.Pyに分かれました.幸いなことに、git pushを認識することに成功し、ついに発表された.

Metabase (Dashboard)

Metabaseは最初からMongoDBが当たり前だと思っていましたが、SQL文でデータを探索したいので残念です.もちろん、NoSQLですが、SQL文が通じるわけがありません!^^
だからGoogleでMongoDBで使っているクエリーを書こうと思っていたのですが、不思議なことに私が使っているクエリーはいつもだめです.いつも間違いばかりして、私を怒らせた.だから简単に行こう!!Metabaseが提供する簡単なクエリーを使用してデータブラウズを行います.😉

後期全体

もっとクオリティを出したいのですが、瓶の中の小さな瓶は私が想像していたより多く、私の時間を無駄にして、Herokuとモデリングで苦労しました...最終的には高品質のページは作れなかったが、今後は必ず改善すると約束した.短期間で成果が出たプロジェクトなので、第1部と第2部のどちらも残念でしたが、特に今回のプロジェクトは非常に残念でした.
しかし、パイプライン全体を経験したことに拍手.約束してから...必ず補充します!もちろんやります.