ザックリ運用開始後に追加したことについて、まとめ

GW中にqiitaの記事にする予定なので、その前に少しコッチにザックリ記載

(+でPythonの勉強もする予定)

 

色々整っていなかったクライント側多め

 

フロントエンド

①.react-storybook導入

github.com

これは、作ったコンポーネントを表示するガイドを作成。

ちょうど、小さいコンポーネントリファクタリングしようと思っていたので、

かなり役立ってる

 

ちなみに、.stampのstorybookも公開しているので、下記でリファクタリング状況は分かります

https://wheatandcat.github.io/dotstamp_client

 

②.flow導入

jsでも型が使えるようになるライブラリ

しかも、一部のみ適用もできるので、稼働中でも入れてけるのが凄く助かる

github.com

 

③.React 15.5対応

気づけば、これが悪夢の始まりだった・・・これ以降、欲がでてライブラリを全部最新化→動かねえええええええのコンボ(当たり前)。土日潰れたなぁ。。。。

 

内容的には、「PropTypes」と「createClass」が別packageになる

facebook.github.io

 

まぁ、対応自体はバッチ流すだけで対応できるので、ビビらなくてOKです

qiita.com

④.webpack v2移行

書き方が微妙に変わったくらいですかね。

地味に現行バージョンで動いているgithubのソースが見つからなくて意外と手間取った

あと、この辺でwebpack.configは環境毎に作るほうがスタンダートだと気づいて

「webpack.config.local.babel.js」と「webpack.config.dev.babel.js」と「webpack.config.prod.babel.js」に分割

webpack.js.org

⑤.react-router v4移行

ちなみに個人プロジェクトだから移行したけど、企業向けだと他のライブラリが移行しきれていないので注意(react-router-reduxとか。。。

github.com

大きいのは「Link」と「history」が別パッケージになったのと、

URLパラメータの取り方が変わったことですかね。

あとハッシュが非推奨になったので、そこも改修

⑥. react-hot-loader導入

ソース変更でリロード無しに反映。ぶっちゃけ一番試行錯誤したかも(でも、実は凄くシンプルに導入できるという罠)

 

ソースの修正自体は↓でOK(reduxなら)

github.com

 

あとは、今の構成だとlocalhostの3000から、APIVM環境にアクセスするので

クロスドメインアクセスで怒られるので、webpackのproxyで同じドメインからアクセスできるようにする

https://webpack.github.io/docs/webpack-dev-server.html#proxy

・・・今見ると、めっちゃシンプル・・・

 

⑥.READMEにバッチ追加

取り敢えず、「travis」と「codeclimate」と「gemnasium」入れてみた。

これやってると、まじめにやってる感でていいね

github.com

サーバーサイド

①. 容量削減のためのYoutubeアップロードフロー作成

これ + プラットフォームログインのmockを作ったらqiitaの記事に落とす予定

wheatandcat.hatenablog.com

 

。。。。サーバーサイドは、これしかしてない。

管理画面作るついでに別FW or FW 無し構成もしてみようかな

ぶっちゃけ今のところFWは弊害しか無いし

 

 

と大体こんな感じ。。。フロントエンドは大分改善された予感

サービス内に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:一次情報とか(ゴミ情報)