読者です 読者をやめる 読者になる 読者になる

サービス内にYouTubeのアップロードの機能を作るまで① 〜ザックリ〜

詳しくは、リポジトリまとめてqiitaに投稿かな?と思っているのでコッチはザックリ

 

github.com

取り敢えず↑には乗せ済み。(なお、リポジトリがでかいからノイズが大きくて参考にならん模様)

 

ってことで、YouTubeアップロードまでに開発した部分

サーバー編の概要

①. Googleのアカウントを用意する

②.Google API ConsoleYouTube Data API」を有効

③.認証情報「OAuth 2.0 クライアント ID」作成

※ここが意外とハマりポイント

・数値のみドメインは「承認済みのリダイレクト URI」に登録できないので、vagrantから立てた場合は、「http://192.168.33.10.xip.io:8080/」みたいにする。

※「.xip.io」は、IPをドメインに変換してくれるドメインサービスなのでローカルでもアクセスできる

 

④.対象GoogleアカウントでYouTubeのマイチャンネルを作成

⑤.15分以上の動画投稿をできる用に、アカウント認証

15 分を超える動画のアップロード - YouTube ヘルプ

 

〜ここまでで、準備完了〜

・以降、サーバー開発

 

⑥.以下の流れでアクセス出来るように構築

  1. Googleアカウント認証する
  2. 認証後のcallbackについてくるパラメータを確保する
  3. 動画アップロードのAPIに上記のパラメータを使い認証して実行

動画アップロードのサンプルは、公式であるので、ここから(バッチ処理ですが動くソースが一番参考になる)

google-api-go-client/youtube.go at master · google/google-api-go-client · GitHub

 

⑦.↑のアップロードにレスポンスにvideo_idが返却されるので、それをDBに格納して投稿と紐付ける

 

番外編. Googleアカウント認証のアクセストークンは期限が30分みたいなので、認証は毎回やらせる感じにしています。

 

これで完成。

ハードル高すぎですね。

さらに、実装時は↑の他にも動画のエンコード、フォーマット形式でアップロードできないとかハマりまくった。(あと、フロントのデザインも・・・)

 

唯一の救いはYouTubeのアップロードAPIのレスポンが結講早いことですかね。おかげ、API直書きでレスポンス返してもタイムアウトしないで済む。

 

時間ができたらwebからアップロードの仕組みだけ切り出したレポジトリ作ってqiitaの記事にする予定。

流石に、このムズさは誰かかが、動くソースを公開していないとキツイっすな

 

 

 

.stampの開発予定いろいろ

技術的な話をqiitaにまとめ中。

 

今後、作る予定のものをメモ書きしておきます。

直近の開発する内容は↓に記載しているので、ここで挙げている内容はもっと後の話です

wheatandcat.hatenablog.com

 

 

ってことで、開発予定

※開発者視点の項目のみです。

 

①.自動デプロイ

理想はhookスクリプとに引っ掛けてデプロイリポジトリのmasterにpushしたら本番反映する感じ

 

あと、マイグレーションも引っ掛ける感じで実行

②.プラットフォームログイン

運営開始地点で入れる予定だったんだけど、「google oauth」が、うまく行かなかったからスルーしちゃったやつ

一応予定では、googletwitterFacebook、gitはやっておきたい

③.JWTの認証処理

当面は会員は自分だけの想定なのでスルーしてました。その内考えます

④.管理画面作る

構想は、決まってないけど作る

まぁ、私が投稿できれば目的は達成できているから、今はいらないけど

⑤.サーバー監視

個人開発規模なら要らない気もするけど、一応考えておこう

Mackerelとか使うのかな

muninでも大丈夫だけど、芋臭いイメージがあるから使いたくない

⑥.サーバーのテストをカバレッジ100%を目指すための構造

これは、いろいろ考えなくてはいけないかも。

ライブラリはgo mockで潰す感じかな?

github.com

コントローラーは、httpでアクセスするとカバレッジ取れないんだよね。

測定をスルーするか、方法があるのか検討しなきゃかな・・・

 

いろいろ模索する予定

⑦.クライアントのみ実行

webpack-dev-serverは、導入したっきり放置してた。

たぶんport:3000の受け口をjsonにして、返却すればある程度できる。

これが出来るとクライアント開発もvagrant無しで出来るから、

たぶん手持ちのmac airでも開発できる予感。

 

あとこれができると「react-hot-loder」も動くかな?

github.com

「Blisk」を使うって手も合ったけど、有料化したっぽいのでスルー

⑧.吹き出しにtwitter引用

そんなに難しくない。

でも、自分がほとんどtwitter使ってないから需要があるかは不明

⑨.SSR(サーバーサイドレンダリング)

これは、実装しようと思えばできそうだけど

まだ手を出す時期じゃないような予感(?)様子見中

Facebookが実装したら本気出す

⑩. 投稿時、一個前の操作に戻す or 進める

過去のstateを保持して戻すだけなので、たぶんできる。

自分の投稿でミスが頻発したら作る

⑪.アイコンのシェア機能

真面目に考えると1ユーザが投稿するために

一々アイコン画像をアプロードするのは、

容量的にも操作的にもNGなので、テンプレ化して

それを使わせるのが理想

まぁ、当分はいらないと思うけど

⑫.不要ファイル削除バッチ

これは、わりかし優先度高い。

対象は画像とサウンドファイル。

どちらも、DBから要らないファイルは取得できるので、

そこからローラー作戦で削除。

 

サウンドの一時ファイルは、作ってから半日以上で削除とかで、いいような気がする。

⑬.speedcurve

jsのレンダリングを計測するツール

サービス的には優先度低いけど

仕事に活かす観点で言うと、経験的には役に立ちそう

⑭.Jet Profiler

mysqlチューニングツール

これも同上

⑮.ユーザー画面

ユーザーアイコンをリンクにして、投稿一覧出す

⑯.クライアントでの画像リサイズ

あった方が良いレベルだけど検討

これができるライブラリはあったはず

⑰.読み上げパッケージを考える

ライセンスがオープンなのでopen-jtalkを使用していますが、

今後の実験投稿を考えると、掛け合いとか、複数キャラとかも

視野にいれていきたいね

ライセンス関係は話が難しいので、あまり他のソフトまで見ていませんが・・・

 

dockerに閉じ込めれば、softalkや結月ゆかりもlinuxで使えそうな気もしますね。

もちろん、ライセンスの問題があるので、webでは使えませんが

----------------------

 

と、大体こんな感じ。

構成を考えるのは楽しいです。夢が広がる

 

 

 

 

 

 

 

 

.stampの今後の更新内容1

.stamp

 

取り敢えず、

サーバーを立ち上げて公開まで行けたので、

現状は満足です。

 

ってことで次のステップに進むための更新予定ですが、

 

まずは、

音声読み上げしているファイルを動画ファイルに置き換えてYoutubeに自動アップロード」を目指そうかなと思います。

 

今の仕組みだと、一記事で10Mbのmp3ファイルができます。

サーバーの容量は30GBです。

当分は、私が投稿するだけの媒体なので、大丈夫ですが。

完成したmp3をyoutubeにあげて、そこのリンクを貼るようにすれば、こちらはテキストのみを管理すればいいので、容量を確保できるって戦法ですね!

 

まだちゃんと読んでないので、本当にできるかは、分かりませんが

↓から、できそうかなと思ってます。

動画のアップロード  |  YouTube Data API (v3)  |  Google Developers

 

なので、当面は以下の2点を開発する予定です

linuxでmp3を動画ファイルに変換する方法の模索

linuxyoutubeに動画をアップロードする方法の模索

 

ちなみに、このwebサービスの最終の目標地点は、

記事を書くと、同時に「ゆっくり解説動画」ができるって感じです

dic.nicovideo.jp

 

現状は、それが実現できる土台だけを作ってる感じですが、

気長に開発していこうと思います。

 

.stamp公開記念に、エンジニアブログでもはじめてみる

.stampを公開したので、ブログでも初めてみる

一人で開発していたら、いつの間にかまぁまぁのクオリティになったので公開しました。

 

.stamp

 

内容:

・映画とかアニメとかの記事をかける

・なんか良くわからないが作った記事を音声読み上げしてくれる

 

大まかには、そんな感じのサービスです。

時間的な制約もあったので、まだまだ作り途中って感じです。

今後の開発予定については、別記事にしようかと・・・

 

あと、オープンソースです。githubで公開してます

github.com

ただ、今までgitlabしか使ってなかったので、イマイチ使い方が分かってないです。

今のところ一人でしか開発してないから、masterブランチしかないけど、今後はforkしてmergeする感じかな?結講手探りでやってます。

 

あと、私はフリーランスのエンジニアです。

オープンソースでの公開は、「個人的な欲求解消」と「仕事貰う時の判断材料」って感じですかね。

 

このブログの記事は、主にエンジニア or  技術 or 開発物の内輪ネタ的なものになる予定です。

 

これを気にTwitterとかも初めてみようかと思います。(使い方は、よく分かってませんが・・・)

なので、情報分配的には、こんな感じになるかと

  • .stamp:映画とか漫画とかゲームとかの紹介
  • ブログ:開発中の話とか、技術の詰まった話とか
  • qiita:まとまった技術系の記事は、こっちに書く
  • Twitter:一次情報とか(ゴミ情報)