引っ越す
わりとあっという間だが今の住居の契約更新の時期になった。更新料は東京ルールで1ヶ月とよくわからん諸経費が取られてそれだけで16万になる。なんだか最近の生活はかなり微妙だったので、この際早いが思い切って引っ越すことにした。
失敗点
正直、今住んでるところは楽しいこともあったし当時の状況から考えれば理由は確かにあったのだが、大きく見て失敗だったと思う。
◯前回引っ越した時の記事
失敗点1 高い
今の住居は13万で、当時の収入から考えれば5万も10万も15万も同じだなと思っていたのだけど、経済情勢は変わる。というか、ライフスタイルによって必ず貯金が必要なときと、そうでないときが出てくる。そうなったとき、固定費は大敵となる。 まぁ、とりあえずウハウハになったらまたすぐ引っ越せばいいやと思う。
失敗点2 職住合致
当時と今で考えが明確に変わったのはここで、これは人によると思うけど一日中家で仕事は無理だなと思った。こうやってブログ書いたりしちゃうし。。。 というわけで日中家から出るようにします。
失敗点3 矛盾してた
僕の当初の予定はアクセスが良いオフィスっぽいところを借りて、オフィス状態にしてそこに住むというものだったけど、こもって仕事をする以上アクセスが良い必要は全くないのでは・・・
細かい失敗点
終電が遅い
銀座線はすごく気に入ったのだけど、唯一のネックが終電の遅さ。ヘタすれば大宮に帰るより終電早いんじゃないだろうか。11:50くらいになくなる。
港区は税務署のアクセス等が悪い
港区の鉄道網は需要の割には微妙で、意外と陸の孤島のような所も多い。広尾とか(は渋谷だけど、麻布近辺とか)。 で、税務署が遠い。 渋谷区は渋谷駅、豊島区は池袋駅から歩ける。
JR、というか山手線
やっぱり山手線の利用頻度は高いので山手線沿線に住むべきだった
というわけで、まだ未確定ですが2月から職場を渋谷(シェアオフィスだけど)、自宅を池袋にしようと思ってます。今年は経済も冷え込み、もはやリーマン水準並の不況といっていい状態になる恐れもあると思います。消費増税もやめてほしいですね。冬の時代に備える。これがキーワードです。 (そんなこと言い出したら景気悪くなるじゃんって人は政府に財政出動して消費マインドを刺激するよう言ってください)
Google Cloud Storageのモバイル対応は残念な点 およびAmazon Cognitoはすごいという話
今年も年の瀬、最後は一応技術ブログなのでプログラミングの話題で締めます。
モバイルアプリでユーザが画像や動画を投稿するサービスを作る際、バックエンド側のエンジニアが最も腕の見せどころとなるのはレスポンスの早さです。バックエンドにかぎらず、フロントでもバックグラウンドでアップロードさせるとか、細かいローダーをどのように表示するかで体感速度を向上させるわけです。 Amazonではサイトの表示が10ms(=0.01秒)遅くなると売上が~~という話がよくあります。というわけで多くのサイトは200msとか目標を決めてサーバのレスポンスをなるべく早く返しています。だから遅くて1秒、2秒かかるサイトはあっても10秒以上かかるサイトはあまりありません。(ここで言ってるのはサーバの速さです)
一方でモバイルアプリのアップロードはそれとは違い、15秒撮影した動画をアップロードするのに1秒2秒で済むということはありません。iPhone6で加工してない動画を撮影すると1秒あたり2~3MBになりました。 この数字だと回線状態が悪いと10秒とか20秒、あるいはもっとかかるくらいのサイズなのでアップロード中の離脱が増えてしまいます。
モバイルから直接アップロードする
画像や動画をアップロードする際、自社のサービスのサーバ(以降APIサーバ)に送って保存+リサイズ等行うのが多いみたいですが、この方法だとAPIサーバからさらにストレージサービス(s3やGoogle Cloud Storageなど)への転送時間がかかってしまいます。 もちろんこれを非同期にすることは可能ですが、今度はAPIサーバに動画・画像の転送処理というバッチ的な機能を持たせる必要があります。これは例えばRailsでAPIを書いてる時、APIサーバ群とバッチ(ActiveJobなど)サーバ群の構成を分けたいときにAPIが一部でバッチ的な役割も担う必要があって見通しが悪くなります。
そこで理論上、モバイルアプリが直接ストレージサービスに画像等をアップロードしてから、そのURLをAPIサーバに送り、さらにバッチサーバでリサイズ等処理をするのが無駄のない処理になります。
このことを言ってくれてるのがこちらの記事です。
で、ここからが本題なんですがs3でできるならCloud Storageでも同様にできるだろうと思い資料を探してみました。 ところが、結論から言えばCloud Storageではこれはできません。(間違ってたら教えて下さい)
そもそもCloud StorageのiOSライブラリはいまだにobjc版だったりARC対応してないなどインストールだけでも大変だったんですが、どうやらAPIの権限上の問題でユーザが投稿することを認めていません。
Cloud StorageのAPIについて
APIのキーがいくつかあって混乱します。 まずセキュリティ上、iOS側に渡しても問題のないキーは一番上のiOS APIキーになると思います。(一応DeNAのプラットフォームの友人に聞いて確認しました) そのほか、例えばサーバキーやサービスアカウントのOAuth認証をユーザに渡すとリバースエンジニアリングのリスクがあるわけです。
で、ポイントはiOS APIキーはサービス全体に紐づくデータやユーザデータに対する権限をあまり持っていないということです。iOS APIキーで調べると一番上にはGoogle Mapのサンプルが出てきます。こういうユーザやサービスにあまり直接かかわらないAPIを操作するためのキーだと思われます。
したがってiOS APIキーではCloud Storageに画像をアップロードすることはできません。
もう一つの方法はユーザがアプリ上でGoogleログインして、アプリに対して認可をくれればそこでもらったOAuthトークンでユーザの画像を作ってやることができますがこれは今回のユースケースとは違うので除外します。
試してないのですがサービスアカウントをハードコーディングせず各ユーザに対して動的に付与してやる方式ならうまくできるのかもしれません。
Amazon Cognito
というわけでAmazon Cognitoの出番です。Cognitoは要するに端末ごとにユーザを識別してくれるサービスです。内部的には初回起動時にユニークIDを付与し、keychainに保存しているようです。
で、ここはわりとブラックボックスになっているのでまだ把握できてませんがCognitoを使えばAWS側が端末を識別できているので、こちらが持っているs3に画像をアップロードできます。
試しに使ってみたら非常にカンタンにアップロードできたので、とりあえず今回はこのアップロード限定でs3を使うことにしました。
Cloud Serviceの一本化/併用は考えて行う
私は普段Google Cloud Services一本なんですが、Googleが持ってないものでAWSが先行しているもの、およびその逆が意外とあることを今回痛感しました。例えばEC2 vs Compute Engineなどはさすがに一本化していいと思いますが、各サービスの利点をうまくとりいれつつ、互いが邪魔しあわないようにうまく住み分け/インテグレートしていくチョイスが今後重要になるのではと思います。
クラウドなんちゃら
クラウドファンディング、クラウドソーシング、クラウドテクノロジーとかここ最近になっていっぱい出てきたけど、Crowd(群衆)とCloud(雲)でそれぞれ意味違うからね。
Gemを作って公開する本当のメリット
Gemを作って公開すると、誰かに気に入られると多くの人からスターが付いてPRが来たり、自分の名前が売れる。 それだけで満足感があったり、転職活動に有利なのだけどプログラミング上の本当のメリットは次のようなことだと思う。
def method_missing(method, *args, &block) case method when METHOD_PATTERNS[:callback] filter = $1.to_sym name = $2 if callback = args.shift set_callback name, filter do if respond_to?(callback, true) send(callback) else instance_eval(callback) end end end if block.present? set_callback name, filter, &block end else super(method, *args, &block) end end def respond_to?(method, priv = false) METHOD_PATTERNS.values.any? { |pattern| pattern =~ method } || super(method, priv) end
ちょっと今仕事で保守しないといけないアプリケーションのソースにこういうのがある。 で、これって書いてる時はいいんだけど読むのは辛いし、読めた所で動的ディスパッチが多いので結局周辺情報まで辿っていかないと意味がなくて、デバッグ上のコンテキストとか依存性が大きすぎるんだよね。
というわけで、ここでエラーが起きたとしてこのコードが間違っているのか、はたまた実行環境(インスタンス変数とかの状態)がおかしいのかがわかんない。
で、Rubyってmethod_missingとか使いまくるとどうしてもこういう傾向が強くなってしまうので、こういうライブラリ的なコードは外において切り離し、他の人や他のプロジェクトから使用してもらって実行環境に依拠せず動くかとか、ライブラリにバグがあったときはレポートしてもらうorあわよくばバグフィックスしてもらって、とにかく自分のビジネスコード側にあたりをつけてデバッグできるようにしたほうがずっと楽なんですよ。
というわけで、こういうコード書く時は小さいgemにして公開しておくのがいいと思います。まぁはっきりいってアプリケーションの中に唐突に出てくるこういうコードはクソースですね。まぁ2年前の自分が書いたんだけど。