masafumi330

# プロジェクト概要 音楽を作る人と、動画を作る人を繋げる新規プロダクトの開発 動画作成者は、サービス内に登録された楽曲に対して、 - お気に入り - 交渉 をすることができる。交渉の際には、動画制作者:音楽制作者双方の収益の料率を決め、交渉を行う。 双方合意が取れたら、動画制作者は楽曲を使用し、YouTubeで動画を公開、収益を得ることができる。 収益が発生した場合、収益は交渉にて定められた料率で、動画制作者:音楽制作者双方に分配される。 # チーム情報 PM: 1名 チームリーダー兼BE: 1名 BE: 1名 FE: 1名 BEとして参画。 # お気に入り登録・解除API実装 【概要】 動画作成者が気に入った曲があれば、お気に入りボタンを押して、自分のお気に入りとして登録することができる。 また解除もできる。 【どのような機能の開発・実装か】 - Go(echo)でAPIを実装 - 既にお気に入り済みであればdelete_flg=1でUpdate、まだお気に入りしていなければ新規Insertを行う。 【課題・問題点】 お気に入りできる/できない楽曲に、楽曲の状態の制限があった。 【打ち手・使用した技術】 - 仕様を洗い出して、どのような状態であればお気に入り登録/解除可能か調査。Notionにまとめて、PM、FEと仕様のすり合わせを行った。 - 状態をレスポンスとしてFEに返してFE側で表示を制御するため、APIのレスポンスに追加のプロパティを差し込む。 - 別途プロパティを追加で返すことで、APIの拡張性・保守性を保ったまま機能実現が可能になった。 # マイライブラリの楽曲一覧取得API実装 【概要】 お気に入り楽曲、および交渉中、交渉完了済みの楽曲一覧を、「マイライブラリ」ページで確認できる。 【どのような機能の開発・実装か】 - ユーザーは、「お気に入り」「交渉中」「交渉済み」のタブを移動して、各楽曲の一覧を表示・確認できる。 - 1APIをGo(echo)で実装し、上記のどのステータスの楽曲一覧を取得するかは、クエリパラメータにて指定し、DBでのSELECTを行う。 【課題・問題点】 - DDDの文脈で、クエリがusecase特有なため、ドメインの知識がインフラ層に溢れてしまう。 【打ち手・使用した技術】 - CQRSを用いて、検索取得用のクエリを別途用意した。 - 保守性および可読性が向上し、CQRSを用いた前例を作ることができた。

# プロジェクト概要 アーティストが楽曲リリース前にSpotify上でPre-saveを宣伝。リスナーはPre-saveすることで、リリース日にSpotifyのマイライブラリに自動追加され、アーティストはストリーミングアルゴリズムに優位に働き、多くのリスナーにアプローチ可能。 # チーム情報 PM: 1名 BE兼FE: 1名 BE兼FEとして参画。 # Pre-Save機能の開発 【概要】 アーティストが楽曲リリース前にリスナーに向けてPre-saveを宣伝。リスナーがPre-saveすると、リリース日に自動で楽曲がマイライブラリに追加される仕組み。 【どのような機能の開発・実装か】 - GoでAPIを開発し、SpotifyAPIを組み込んでPre-save機能を実装。 - ユーザーがPre-Saveボタンを押した場合、SpotifyアカウントのOAuth認証画面へ遷移。認証した後、該当アカウントのSpotifyマイライブラリへ、該当曲を追加するリクエストをSpotify APIを用いてリクエスト。 - OAuth認証のため、Spotify APIの拡張申請を担当し、Redirect URLとcallback時のエンドポイントを設定。 【課題・工夫した点】 - Pre-Save完了後、ユーザーは元の画面に戻ってくるため、Pre-Saveが正しく完了した、または失敗したことが分かるよう、完了orエラーポップアップを表示し、ユーザーフレンドリーになるよう対応した。 - 「当サービス -> Spotify OAuth認証画面 -> callback -> 当サービス」という流れで画面遷移が行われるが、当サービスに帰ってきた時点で「どの楽曲をPre-Saveしたか？」という情報が失われてしまう。 その対策として、Spotify OAuth認証リクエストを行う際、Cookieに、楽曲IDのハッシュ値をセットする。その後、当サービスに戻ってきた時、Cookieから楽曲IDのハッシュ値を取り出すことで、「どの楽曲がPre-Saveされたか」をDBに記録することができた。 - Spotify OAuth拡張申請に関しては、申請フローにて、どのような設問と回答を行ったか、その情報をチームの資産とするため、対応後ドキュメントを作成・共有した。 - 2023/5月にローンチし、2023/12月現在で、**約16,000件**のPre-Saveが本機能を用いて行われた。

# プロジェクト概要 顧客からレポートデータがGoogleDriveの所定の位置にcsv形式で毎月保存される。 営業担当は、そのレポートデータをTableauで毎月確認するため、Tableauへの自動連携を行う。 Tableauでの操作は営業担当が行うので、開発としてはTableauが直接参照する元データとなるAWS Athenaへデータを同期する部分までを開発する。 # チーム情報 BE: 1名 # どのような機能の開発・実装か - GoogleDriveの所定のフォルダ下に、規定のファイル名で月毎にレポートファイル（スプレッドシート）が保存される。 - 毎月１日、cronスクリプト(Go)で定期実行。 - Googleスプレッドシートから取得したデータは、csv形式でAWS S3に保存する。 - S3に保存済みのファイルから取得済みの月を確保しておく。 - GoogleDriveAPIを用いて、GoogleDriveの該当フォルダ下を再帰的に走査しながら、未取得の月のレポートファイルを特定。 - Google Sheets APIを用いて、該当ファイルのデータを取得し、csvファイルとして書き出す。 - 書き出したcsvファイルをS3に保存。 - AWS Athenaに元テーブルを作成。データ参照は、上記で保存したS3 keyを指定する。 # 課題・工夫した点 - レポートファイルは月あたり１ファイルだが、途中でレポートファイルが更新される可能性があるため、「更新があった」ことを検知し、S3に保存しているファイルも最新に更新する必要があった。 - 「S3ファイルの最終更新日時（A）」:「GoogleDriveファイルの更新日時（B）」を比較し、（A）<（B）となった場合は、更新があったとみなし、再度S3をアップロードし直すロジックとした。

# プロジェクト概要 当社プロダクトのインパクト計測のため、Twitter上の該当キーワードを含むツイート件数を日毎に取得。 v1.1->v2への変更対応を行う。 計測した値はTableau上で分析を行う。 # チーム情報 BE: 1名 # どのような機能の開発・実装か - TwitterAPIv2 「GET /2/tweets/counts/recent」 を用いて、直近７日間の該当キーワードのツイート総数を、日毎に取得する。 例) 2023-12-01,tunecorejapan,1234 2023-12-01,tunecore.jp/artist,57 2023-12-02,tunecorejapan,100 2023-12-02,tunecore.jp/artist,97 - 取得したデータはcsvとしてAWS S3に保存。-> Athenaの該当のテーブルへ紐付け。 - cronスクリプト(Go)として、毎日0:00に定期実行を行う。 # 課題・工夫した点 - `GET /2/tweets/counts/recent` のリクエスト上限が、 5回/15min (Basicプラン) なので、リクエスト上限に達したら自動的に所定の時間Sleepするように対応。 - エラーレスポンスの中に、ステータスコードと次のリクエスト可能時間までの時間が含まれているため、これらを解析して、自動Sleepを行う。