PhpStormと僕

プロは自分が経験したことないことにもオモシロさを感じ、やる前から否定することはしません。プロですから。

プロは常に新しいことにチャレンジし続けます。プロですから。

プロであることは他人も認識しています。プロですから。

プロは自分が何の分野のプロであることを正確に分析し把握しています。プロですから。

プロは定期的に自分がプロであることを再認識し高めていきます。プロですから。

プロは臨機応変であればあるほどプロの度合いが高まります。

常に覚悟があるがプロ。

プロは、相手がプロであることを分かっているときにプロとしての振る舞いを求めます。

プロは他人の評価や高揚感よりも、自分自身がプロとして振る舞えているかどうかを重要視します。

プロは、相手もプロであることを認識し賛辞を惜しみません。

プロは、他人にプロであることを再認識されることに弱いことがあります。

プロっていう単語がゲシュタルト崩壊したのでこのあたりで終わります。

2019-04-03

Firebaseに関するディスカッション形式のMeetup FireTips#1を開催しました

アルは全部Firebaseで開発しているんですが、Firebaseをチームで使っているとチュートリアルやプロダクトの0→10くらいのフェイズのノウハウは結構あるものの、それ以降のプロダクトやチームのスケール期におけるノウハウがあまりなくて、世のエンジニアはどう向き合っているのかな〜って悩むことが多々ありました。そんな折にズボラ旅を作っているHotSpringのぽちさんからお声がけがあってFirebase関連のTips持ち寄りの勉強会をやってみようという運びになりまして。

そんなわけで、企画から少し間は開いてしまったものの、めでたくFireTipsという題名で第一回が開催されたので内容共有のエントリです。

場所

アル社オフィスラウンジスペース(渋谷)

形式

飲み物、食べ物は各自持ち寄り

今回話したこと

Firebase Projectsでdev, test, staging, productionなどの複数環境をどうしている？どう作る、どうデータを同期反映しているか

一旦dev, staging, productionを手作業で環境構築した上で使っている。
アル社の場合はCircleCI上で週次でproduction => devへのマスタデータの更新をやっている。
dev環境が複数人が占有しづらい（ブランチとかで）ので、声かけ運用でdev環境の明け渡しとかをしている。ここが開発のボトルネックになりがち。
Firestore Emulatorは、できることがローカルテストのモック程度なので開発用(dev)の置き換えには現時点ではならない。

Firestoreにスキーマ定義がなくてつらい問題とどう向き合うか？

事象としては例えば画像アップロード系の機能を実装するときに、Android/iOSがそれぞれクライアントで実装すると、カラムがnullableなのかカラムなしなのか空文字入れるのかとか、トランザクションでの処理が各クライアントの実装に依存する、というつらみ
- Write処理をすべてCloud Functionsに寄せればとりあえずは問題の事象は少しは減る(Cloud Functionsのコードを読めばわかる)が、結局処理がBackendに寄ってしまうので著しくスピードが落ちる/Firestore Wayからは外れるしイケてない。
Firestore上のデータを参照したときにカラムやSub Collectionが存在しなかったときに、「そのカラム/Sub Collectionは常に存在しない」「特定の条件化では存在するが、そうでないときもある(その条件もデータからは読み取れない)」というつらみ
現状ベターな解決策なし。求ム情報。

どういう処理をAPI処理(例えばCloud Functions)に寄せて、どういうものはフロントで処理するか

無駄にCloud Functionsの処理を追加したくないし、追加したらさらにお金も掛かるので、極力直にフロントから処理したいというのもある。
トランザクション処理やフロントからは参照されたくないセキュアな処理、複数Collectionに跨がる処理などはCloud Functions側でやりたいが、それ以外は極力フロントでやりたい。
- ただし前述のスキーマ定義がないが故のつらみで、AndroidとiOSで処理が（同じロジックで実装したつもりだが）異なってしまうパターンも多々ある。

Sub Collectionで持つか、Root Collectionで持つか？

データ構造的にはSub Collectionの方がベターな感があるが、現状は「親Documentを特定していない状態ではSub Collectionに対してQuery(whereなど)が使えない」というとても大きな制約がある
HotSpring社ではどこになにがあるのかが分からなくなるのを避けるために、今はRoot Collectionに寄せている
アル社は「(firestore.ruleを踏まえ)横断的に検索する可能性がアル場合はRoot Collectionに、そうでなくデータが階層（ドキュメント）構造になる場合にはSub Collection」にデータを持つようにしている

Firestore Rule の本番反映へのフロー

手作業でdevを更新したらstaging, productionに反映する
- 「メンテナが一人だから成り立っているという側面もあるかも」
firestore.ruleで管理して、本番デプロイのタイミングでデプロイ
- 必要な箇所（iOSやWeb）とデプロイのタイミング（Cloud Functions）が違うのでフローが煩雑でつらい

複数プロジェクトの認証を共有プロジェクトによるFirebase Authentication実現するのはどうか？

良さそう！
共有プロジェクト側のFirebase Authenticationでログインしている状態を、別のプロジェクトのFirestore側でcontext.authが引き継げるかどうか？がポイントになるが、検証してみないと分からない！

Cloud Functionsの自動デプロイ問題

環境変数を .runtimeConfig で管理している場合、事前に環境変数を書き換えてProductionへデプロイ反映しておく必要がある(=人力作業が発生する)
- .runtimeConfigをGitHubに乗っけてしまえばいける。
  - GHEという選択肢
現状ベターな解決策案なし。

話せなかったこと（次回以降のネタになるかも）

Cloud Functionsのデプロイ時のDownTimeについて
AlgoliaのWeb Console上でフィルタをいい感じにデバッグする
Firebase Cloud Functions vs GCP Cloud Functions
Firestoreのnull型って使ってる？
FirestoreでcreatedAt, updatedAtみたいなTimestamp型について
権限管理をFirebase Authenticationのcustom-claimでやったときにどう管理するか
Client Side Join vs 正規化 with Web Application
MySQL と Firestore の使い分け

第二回のお知らせ

こんなニッチだけど割と実践する上では悩むネタをゆるく話し合う場でした。 2回目は5/15あたりに開催します。イベントページはまだ作らないつもりなんですが、もし参加興味ある方はTwitterとかでDMいただければと思います！

2018-06-18

漫画ビレッジを支える技術とオススメのマンガ

1つ前のエントリで書いた漫画ビレッジっていうサービスをリリースして3週間弱経った。

その後もITmediaの記事でインタビューして頂いたり、出版社絡みの方と色々話したりなど諸々各所反響があって最近はちょっとバタバタ気味。（何事においても暇なことが嫌いなので忙しいのは嬉しい）

作り始めた当初は、これ作ることで技術的にも人脈的にも本業に活かせれば良いかなぁ、、くらいのゆるい感じだったので、今の状態はとにかくありがたい限りという感じ。

3週間の間に漫画村UIに寄せてリニューアルしたり、Heroku2台体制で運用しているときにYahoo!砲がきたりと色々あって、なんか色々変化だったり進捗もあったりしていて。

Twitter経由だったり問い合わせだったりで割と技術的な構成がどんな感じなのかを興味頂いている方も多かったので、こんな感じで作ってますよ〜っていうのを色々まとめてみた。補足として前エントリをざっくり見ていただくと理解が早いかと。

個人開発の常でとにかくリソースが限られているので、無駄な工数（開発も運用も）は最小限にしないと全て破綻するので、とにかく巨人の肩の上に立つことを意識していて、自前で作らなくてもいいものはとにかくSaaSを使って解決するようにしている。

今現在使っているフレームワークやサービスは大体こんな感じ。

Nuxt

前エントリではNuxtで Framework7 っていうUIフレームワークを使っている旨を書いたが、色々つらみがあったので捨てた。今はCSS フレームワークとしてBulmaを入れている。

Framework7は簡単にネイティブアプリ風のデザインを作れるんでそれはそれで良いんだけど、ただRouter周りをwrapしてしまっているUIフレームーワークは自分で拡張しようと思ったときにかなり制約があってつらみがあることが多いなぁという学びがあった。

あと大きく変えたのはSSRにしたことくらい。SEO的な要件をいくつか満たしたかったのでSSRにしたが、結果的にこれはSPAのままでも満たせたので結果的にそこまで頑張らなくても感はあったかも。

First Meaningful Paint周りの対応(Avoid the fold)がまだうまくできていなくて（めっちゃ運用のつらみを伴えばできる）、Nuxtでここらへんの知見ある方いたらぜひお話聞かせてください。

Firebase

バックエンドではFirebaseで今は Firestore と Cloud Functions を使っている。

Firestoreはとにかく便利で、ざっくり言うと Database + WebAPI + Mobile Databaseをくっつけたようなもの。Scalabilityも全く意識しなくていい。すごい。しかも料金もFirebase Realtime Databaseよりかなり安い。（それでも、漫画ビレッジにおいてはここ一番コスト面で掛かっている）

まだβではあるものの安定性は特に困ってはいないが、ただ、機能周りがいくつか制約があって

SubCollectionに対してQueryが使えない(SubCollectionの存在意義って･･・)
Webコンソールが絶妙に機能不足な上にカジュアルにTruncate(Drop table)できてしまう
バックアップ周りが全くない

と、運用面でのつらみはそこそこある。

これは完全に自分が悪いんだけど、FirestoreのWebコンソールから操作をしていて、あるレコード(Document)を消そうと思って間違ってメインの商品テーブル(Collection)を全消ししてしまったことがあってめっちゃ血の気が引いた。大惨事になる前に即時復旧ができたのでそのときは良かったけど、心臓にはとてもよくない。

恐らく現時点での実務上の運用においては、FirestoreのWebコンソール画面にはアクセスできないように権限設定しちゃうのが一番安全なんだろうなぁ、、っていう気はしている。

Cloud FunctionsはFaaSなもので、ビレッジではクローラーの実行と、あとDB(Firestore)に新刊追加があった際のトリガーでスコアを変更したり、Algoliaのインデックス登録とかをやっている。とりあえずログ周りはconsole.logしておけばStackdriver Loggingで扱えるのでなにかと便利。

Cloud Functionsは実質ほぼ無料枠で収まる程度で使っているくらい。こっちは現状そこまで不満はないが、cron相当の定期実行が自前ではできなくて、外部からなにかしらトリガーを走らせてやらないと動かないので、そこらへんのつらみがあるくらい。

Heroku

フロントはNuxtで書いているので単純にホスティングだけしたかったので、運用周りで自分が知見があったHerokuを選定した。ローンチ当初は色々模索してPerformanceプランに上げたりオートスケール入れたりしたけど、今は一番安いStandard-1X dynos * 2台($25*2/month)という最小限の構成に落ち着いていて Yahoo!砲が来た時も結果的に最後まで2台構成のまま乗り切った。（これはFastlyの功績が大きい）

Fastly

高機能CDN。Herokuのプラグインとして今はPro(TLS)プランの$130/monthを使っている。基本的な使い方しかしていないが、運用を続ける中で一番このサービスに助けられている。

最初結構設定でハマって（というか反映されなくて）いくつかサポートに問い合わせたりもしたけど中の人が割と手厚いサポートをしてくれる印象。

Algolia

全文検索エンジン as a Service。日本語にも対応している。$59/month。

FirestoreはQueryでの検索周りは弱く、部分一致での検索などはできないので、漫画ビレッジでの検索機能はAlgoliaを使っている。とにかく高速で平均7msくらいでレスポンスが返ってくる。

SynonymもWeb上から簡単に管理できるのがとても楽。まだ運用に置けるBest practicesは模索中だが、例えば「ワンピース」で検索したときに「ONE PIECE」に紐付けるようなことは全部Algolia管理画面で完結してできる。Synonm生成自動化は精度がかなり落ちそうなのでいまのところ手動でやっている。

検索にHITしなかったワード一覧もAlgolia上から管理できるので（もちろんAnalyticsでも取ってはいるけど）、「ユーザの需要はあるが漫画ビレッジではカバー出来ていないマンガ」の傾向も把握できて便利。

Bugsnag

エラー監視 as a Service。$29/month。これは全くこだわりはなくて、3年くらい前からこれ使ってる。

細かなバグまでは対応しきれなかったりするのだけれど、どんなバグがどこでどれくらいの頻度で起きているっていうのは割と見落としがちなので、対応可否を判断するためにも入れておいて損はないかなぁ、、というのが自分の中の位置付け。

Librato

HerokuのプラグインとしてMetrics & Monitorig用として入れている。$19/month。

日中はそこまでがっつりメトリクス見ることはできないので、基本的にはヤバイ閾値でのアラート設定入れといて、これの通知がきたらなにか対応する必要がある、くらいの温度感で入れている。

これ飛んできた時大体ヤバイことになっているのでだいぶ役に立ってる。

オススメのマンガ

今年読んだ中だと 7seeds（全35巻+外伝1巻) とかゴールデンカムイ（現在14巻・今まで読まず嫌いしてたことを反省）とかヒナまつり（現在14巻・LINEマンガ12話まで無料）とか。

現時点で5巻以下のものだとあげくの果てのカノン（全5巻・小学館eコミックで1巻無料）とかブルーピリオド（現在2巻）、左利きのエレン（現在2巻）とかが好きです。

有名所ばっか挙げましたが、そんなん全部読んどるわって人はぜひ色々語り合いましょう。

まとめ

βのサービスだったりを本番で使う判断を下せるのは個人開発の強みだなーとかは痛感してます。（なにか起きたら全て自己責任なので、自分が色々忙しくなるだけで済む）

実際作ってみて、この領域は大きすぎてやはり個人で運営していくには色々と深い領域だなぁ、、、と思ってはいますが、考えうる最善手を最短ルートで通っていくのが得意な性分なので、生温かい目で見守って頂ければ幸いです。

2018-06-01

漫画ビレッジっていうWebサービスを作った

漫画ビレッジっていうサービスを今週リリースした。

ITmediaの記事の記事でも紹介してもらったが、無料のマンガサービスに掲載されているマンガのリンクを集めたサービスという位置づけ。

各所でご紹介頂いたこともあり、公開2日で80万PVくらいのアクセスがあって結構驚いている。

賛否はあって然るべきだが、マンガアプリ運営している出版社の中の人から「ぜひうちのサービスも登録してください」という問い合わせもあったりするので、これは本当に意外で結構驚いたりはしている。

現時点で3,700シリーズくらいデータを貯めているけれど、まだ独自スコア付けが終わっていないものもあるので全シリーズは公開していないが、コンテンツは徐々に拡充していくつもり。

（どうでもいいけど、個人的なこだわりでサービス名で使っているのは「漫画」だが、固有名詞及びサービス名以外の箇所では全てカタカナの「マンガ」で統一している。本エントリ内も以下同様）

きっかけは id:kensuu さんとゴールデンウィーク前に「ブラウザだけでマンガ読めたら最高だよねぇ」「合法漫画村(パワーワード感)」っていう会話をしていて面白そうだなぁと思ったこと。

自分もマンガ好きで普段からKindle(まとめ買い勢)、マンガワン、ピッコマとかはよく使っているのだけれど、とにかくマンガアプリは種類が多すぎて

どのアプリでなんのマンガが何話まで読めるのか分からない
各アプリごとにユーザ登録がめんどくさい（アカウントが大量になってどのアプリでどうログインするのか分からなくなる）
読んでたマンガがどのアプリで読んでいたのか分からなくなって何話まで読んだか分からなくなる
- これは動画をNetflixで見てたかAmazon Primeで見てたかdアニメで見てたか分からなくて何話見ればいいんだっけってなる現象も同じ

みたいなつらさはそこそこ感じていた。

マンガアプリを提供している各社プラットフォーマーからすると当たり前だけど自社のアプリを使って欲しいはずなので、アプリごとの個別最適化は進んでいくものの横断的に見れる仕組みは出てこないだろうなぁと思っていたので、それなら作っちゃえ！と。

最初は1週間くらいで作れるかなーと思ったけど、個人開発の常でテンションが続かずにUI周りハマり始めて結構開発から離れちゃったりしたので、結果的に丸1ヶ月掛かった。

自分はエンジニアなので、以下は漫画ビレッジがどんな技術つかって作ったのかをまとめてみる。

フロント

フロントはNuxt。管理画面系はVue + Bootstrap。

UIフレームワークとしてはアプリUIっぽく作れるFramework7のNuxt wrapperのnuxt7を使っている。

ただ、UIフレームワークに関していえば結果的に選定をミスっていて、

Framework7-Vueに乗っかるとFramework7Domの独自実装の兼ね合いでServer Side Rendering(SSR)ができない
Nuxtの機能のfetchやasyncDataなどが潰されていて恩恵に与れない部分がいくつかある

というつらみがそこそこあって、UI周りは今日中にFramework7を捨てて作り直す予定。

別で作っているサービスでもAdmin機能としてFramework7は使っているが、ここらへんの事情を無視できるサービスであれば使うのは悪くないかなーと個人的に思っている。

バックエンド

バックエンドはすべてFirebaseに乗っかるようにしていて

クローラーだったり細かなバッチ処理類は Cloud Functions、

WebAPI相当とデータベースに該当するものはすべてFirestoreを使っている。

ユーザ登録/認証機能は使っておらず、このサービスにおいては今後も実装する予定はない。（元々の思想に「ログインだるいよね」があるので）

FirestoreはまだβではあるもののRDB脳を捨て去ってからはかなりクセはあるもののとても快適で、APIレイヤーを意識しなくていいのはだいぶ楽ができている。 SubCollection周りの取り回しやQueryにまだまだ難はあるものの利点のほうがでかいので、別サービスでも積極的にFirestoreは使っていくと思う。

ただ、PVがそこそこあるせいでFirestoreのデータ転送量が意外と多く(もともとFirestoreはめちゃくちゃ安いんだけど)、収入がないの個人サービスを支えていくにはちょっとつらい規模の支出が出ているので、そこはなんとかしたいところ･･･。

インフラ

特に強いこだわりはないがいまのところはHerokuで動かしている。

1台でも余裕で捌けていたのだが、Zero Downtime DeploymentのためにPrebootを使いたかったので Standard-1X dynosの2台構成で今は動かしている。こっちはFirestoreとは違って微々たるもので、5000円/月くらい。

今後どうしていくのか

あくまでマンガアプリのプラットフォーム側の発展を意識して邪魔するつもりや、タダ乗りする気は無く、うまい感じに共存関係を築ければ良いなぁと思っているので、そんな視点でゆるく改善を続けていこうかなーと思っています。

2018-05-06

VIVE Proを買ったので所感

www.vive.com

発売日からは若干出遅れたけど、HTCのVIVE Proを買った。

元々PSVRは持っていていくつかソフトも買っていたんだけれど、960x1080の解像度はいかんせん画質の粗が目についてしまってしまい、没入感はあるものの長時間ゲームに集中することが結構できなかった。そんなわけなので解像度の変化がどれくらい大きく変わるのかが今回一番期待していたところ。

VIVE Pro フルセットが欲しかったんだけれど、完全に売り切れていて入手できなかったので、代わりにHTC VIVE + HTC VIVE PRO アップグレードキットの組み合わせで買った。ドスパラにだいぶ在庫があったので即日買えた。

この買い方をすると実はフルセット版よりも1万円ほど安く買える。ただ、アップグレードキットの場合はベースステーション2.0が付属していないため、HTC VIVEのベースステーション1.0を使うことになる。

ベースステーション2.0は調べた限り一番の違いは、対応範囲がかなり広くなる(4台まで組み合わせると最大10m四方のスケール)という理解。自分の場合はそんな広いスペースがあるわけでもないのでとりあえずこの組み合わせで良いかなーと。HMDが2つになっちゃうけど、旧式は未使用なら2万円前後で売れるみたいなので実質フルセット版より3万円程度安く買える計算になる。

買ったものと所感

PSVRよりも若干浅いかぶり心地で最初は違和感あったけど、慣れるとVIVEの方がフィット感高かった。 PSVRはすぐ上下にズレて視点がぼやけてしまうので位置を直すことが必要だったけど、VIVEはほぼそれがない。

全体的に少し解像度が高いだけでここまで変わるのかー、という印象。あと、体感型のゲームの種類が豊富なので個人的には◎。

ボクシング音ゲー。Youtubeの音源で音ゲーをできるやつ。超楽しい。ゲーム内のメニューの操作性と検索性は致命的に悪いので、公式サイトでSteamアカウントでログインして、「気に入った曲をStar付けまくる→ゲーム内で自分のプレイリストからプレイ」する方式が快適。

ボクシング音ゲー。(たぶん)オリジナル曲が25曲ある。同じボクシング系でもSoundboxingとは結構違う。こっちの方が汗かく。楽しい。曲数追加に期待。

store.steampowered.com アーケード系の音ゲー。上の2つはスポーツ感が強いのに対して、こっちは音ゲー寄り。音ゲーとしての難易度も上2つより高いかな？という感じ。全体的綺麗だし、音ゲーの中に入っている！感が強いので楽しめる。

刀、弓、銃のアクションゲーム。Waveもの。銃のリロードとか刀の取り出しとかがリアルなのもおもしろい。個人差はあると思うけど、この手のアクション系は割と酔いやすいんだけど、このゲームは全く酔わなかった。