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

今、SPA/ReactNativeにとっての必要な PaaS を考える

当方ボーカル、フルスタックPaaS募集

ほしいもののコンセプト

  • SPA職人としてそこに全力を尽くしたいので、それ以外を全部やってほしい
  • とはいえストレージへのアクセスはAWS Lambda/Cloud Function等を介してちゃんとしたコントロールをしたい
  • プロトタイピング時は何も考えずにORMを叩いていたい
  • 運用フェーズでは金を払ってスケールしたい。とはいえボトルネックは常に監視したい。極端にやばいスケールサイズはどうせ人を雇うのでその先は考えなくていい。

より細かい要求

  • 認証はPaaS側が全部持ってほしい
  • JSONSchema でクライアント/サーバーサイドのアクセス制限を定義したい
  • サーバーはフルマネージド
  • Lambda/CloudFunction で関数単位でパフォーマンス監視/障害検知
  • ローカルで本番と同じ構成が建てられる
  • アセットは勝手にCDNに投げといてほしい
  • バックエンドストレージは、 BigQuery/Mongo風の列指向DBで、インデックスが貼れて、オートスケールしてほしい
    • 無停止でなくてもいいから任意なバックエンドに引っ越すのが簡単であってほしい
      • Google だったら Datastore で初めて、辛くなったらSpannerとか。
      • AWS だったら DynamoDB => Aurora とか
      • 結局SQLじゃんってのはわかるが、適切なActiveRecordみたいなのがあれば問題ないと思っている。
    • ちゃんとしたNodeのORMがほしい。joinの抽象は…必要かどうか悩む。非同期アクセッサはどうやってもNodeで表現しづらい。
    • ORMは型を書きやすいインターフェースでないとこの先ダメ
    • たとえ相手がNoSQLだろうがMigrationがないとダメ
    • MongoQuery風のクエリがほしい

妄想したAPI

const schema = {
  definitions: {
    todo: {
      required: ['title', 'done']
      properties: {
        id: {
          type: 'string',
          primary: true
        },
        ownerId: {
          type: 'string',
          index: true
        },
        title: {
          type: 'string',
        },
        done: {
          type: 'boolean'
        }
      }
    }
  }
}

const todoStore: Store<Todo> = new Store({
  storeName: 'todos',
  schema: schema.definitions.todo
})

const main = async () => {
  await todoStore.save({
    title: '朝食', done: false, ownerId: 'mizchi'
  })
  const todos = await todoStore.where({ownerId: 'mizchi'})
  console.log(todos)
}

main()

これが無限スケールしてほしい。いや、このAPIを再現するだけなら簡単だが、運用まで含めると考えることは無限にある。マイグレーションとか、実際 store.save 関数の中身がどこに飛んでるのか、とか。バッチアップデートはどうするんだ、認証は?

それらを全部クリアした上で、あとはフロントエンドとしてReact/ReactNativeに繋いで、終わり!って感じ。いや自分のメインの仕事はそこからはじまるんだけど。

現実の課題

これらを落とし込んだソリューションというか、「正解」なスタックというか、そういうのがない。みんな手探り。

実際今どうするのが正解か

AWS Lambda / Dynamo

調べると、Lambda が RDS とコネクションヒープが持てない関係で相性が悪く、スループットを出すにはDynamo を使え、という感じになっている(たしか公式ドキュメントにもそう書いてある)。Dynamo を使ってみたが、スループットのコントロールAPIでコントロールしたり、金で解決できるんだが、場合によっては取得を諦めたりするし、挙動が難しい。何も考えずに使えるものではない。返り値もなんか変で、毎回整形するのがめんどい。ラップすりゃいいんだが。

S3, API Gateway, Lambda, それらの複合を考えていくと、k8sやTerraform とか使うのが最近の流行りっぽいが、完全にAWS沼/コンテナ沼だと認識してるので、今は距離をおきたい。ビルドツールにDockerを使うのに抵抗はないが、デプロイされる環境まで自分はやる気がない。

Google Firebase

Firebase hosting という機能があって、元々はGoogleクラウドにSPA、というかindex.html をデプロイするだけの機能だったんだが、どんどん機能が増えて、最近 cloud function のインテグレーションがきた。Firebase Realtime Database はローカル制御の限界があったが、ストレージへの保存時の検証をクラウドでやれるようになったので、実質今までのサーバーと同じような運用ができる。

https://firebase.google.com/docs/functions/

とはいえ、Firebase Realtime Database はリアルタイムストリームに優れるけど、ストレージのサイズの料金とreadの料金が高いので、真面目に作ると他のバックエンドに接続する必要がある。しかしそれも cloud function 経由でできるから、もしかして怖いものはないのでは、それが RDS/Lambda みたいな問題がなければ、と思っている。

GCPの範囲内なら、実際の繋ぐ先は、ホビーユースなら Cloud Datastore 一択らしい。Google Spanner がいいらしいって雑な情報で値段を調べたけど、 1ノード1時間 $0.9 で何もしなくても軽い試算でも月7万円ほどかかる。これはない。けど、月7万も必要なサービスを回せるんだったら、売却含めてその時点で何かしらマネタイズできると思うので、まあ考えなくてよい。AWSエンジニアを月100万で雇うのと比べれば7万は誤差。

認証系も組み込まれて強力。アクセス解析やAdMobの組み込みがある。僕はAdMobは使ったことがないので不明だが。

というわけで、最近はFirebaseを掘っている。

Firebaseに足りないもの

GCP全体に言えるが、なんとなくどれもBeta版っぽくて、ベストソリューションもないから、これとこれとこれ!って選択ができなくて、Railsみたいな選択の迷いのなさが生む生産性には遠い。

Node視点だけで見ると、次のものが足りない。

  • Lambda/Cloud Function の抽象化レイヤー
  • バックエンドのアダプターが充実したORM
  • これらを実践した運用の体験談

たとえば、 Rails Tutorial 相当のことを、同じかそれ以下の分量で違和感なく記述するフレームワークがポンと提案されたら、みんなそれに乗ると思う。

自分がそれを作るから金をくれーといいたいのはある。いや、自分はGoogle技術の専門じゃないんで、GCP周りは専門にする他の人にはまだ劣ると思うが、実際にSPAと組み合わせて、オールインワンで諸々隠蔽した上での開発環境のスタックの構築は、自分のようなスキルセットの人間に強みがあると思うので、フリーランスの仕事の幅になるかなと思って勉強中。現状、半年分の仕事は埋まってるけどなんかあったら依頼をください。現場からは以上です。

ただのにっき

アクセス数とか想定反論とか、そういうこと無視して、何も考えずに日記を書きたい、と常日頃思ってるんだけど、日頃の行動の最適化の結果、人間としての基本的な振る舞いがそうなってない。読者を釣りがちというか、読んでくれた読者には満足してもらって帰ってもらいたい、みたいな気持ちが強くて、自分自身の為の日記というのが中々書けなくなってる。

この「日記」は短く終わらせるつもりで、読み応えもないボリュームだし、アクセスつかないだろう、と踏んで書いてるんだけど、変に何らかの共感性のスイッチをつついてしまうと、自分のための日記から、他者に消化されるための日記に変質してしまう。自分の中の他者が、こんなんじゃつまんねーよ、面白いこと書けよ、と急かしてくる。それを諦める訓練をする。

今、この日記を書くにあたって意図して言及してない現象があって、過去記事を時系列で読むとわかるんだけど、そこで同情を誘うような節回しをすると、あの顛末ね、って扱いになって、ただの日記が、そういう性質の記事になってしまう。それも嫌だ。同情を引くために書いてるんじゃない。

今は、エンジニアという立場で要求される以外の、ただの日記というフォーマットを諦めない為に書いている。書いた。終わり。

悪童日記 / 感想

読み終わった。

悪童日記 (ハヤカワepi文庫)

悪童日記 (ハヤカワepi文庫)

ふたりの証拠 (ハヤカワepi文庫)

ふたりの証拠 (ハヤカワepi文庫)

第三の嘘 (ハヤカワepi文庫)

第三の嘘 (ハヤカワepi文庫)

1巻、2巻、3巻と全部異なる楽しみ方ができて良い。双子、三人称、信頼できない語り手、と主観の揺さぶり方がうまく、それによって再読したくなるギミックが随所に仕掛けられていた。ポーランドナチスドイツ占領下からソ連による「解放」までの、重く退廃的な雰囲気がいいスパイスになっている。

ただ、Twitterで書いたような印象にも引っ張られてしまった。

3巻は「第三の嘘」のこと。まあ、リュカとクラウスという名前以外は、ほとんど関係ないんだけど…

削除済

はっきりいって個人の日記レベル、のつもりで書いた記事が、ホッテントリに入って、妙なマウンティングなコメントが増えて、ただでさえ辛いところで、より辛くなるんで消しました。家でなくしたのが見つかって恥ずかしさのあまり消した、とか、そういうのじゃないです。

元々技術記事はQiitaで、こちらはもっと曖昧なもの含む、ノンジャンルなブログにしたいという運用で、人間的な、雑な部分も隠さず公開するつもりだったんですが、ちょっとしたことでも噛みつかれて、そういうのが許されなくなってきたんだなぁ、という気持ちです。

いや、まあ自分は声がでかいのはそうだし、インターネットってそういうところだな、ってのはわかってるんでけどね。自業自得ですね。

以下ゲームにまつわる辛い記憶です。

ニンテンドースイッチ感想、ゼルダ序盤の感想、ニーアオートマタ感想

フリーランスになる前に好みのゲームがどばーっと出てるので消化しきらねばならない。

ニンテンドースイッチ感想

これは据え置き機ではない。ちょっと大きい携帯機だろう。おそらく3DSとのMigrationパスを探ってるんだろう。 WiiUの中途半端なリモートプレイはこの為の実験だったとすら思える。「画面が小さくない」のはモバイルとの差別化だと思う。そこで差別化しないといけないのは悲しいところだが。 モバイル機が立体視2画面ではないのは、推進してた岩田さんがいなくなったからだろう(これ事態はとても悲しいことだが…)。ゲーマーは特に望んでない機能だったので、GBA路線が復活したと思うと嬉しい気はする。

スペック競争に参加していない任天堂はおそらく(他よりも遥かに)本気でインディーを取りに行くべきで、とくに2Dのゲームと相性が良いはず。発売が決定してるStardew Valleyとかバク売れするんじゃないか。Vitaが死に体で、GPD Win みたいなお遊びが競合なら、そこに負けるはずはない。iPhone/Android という強すぎる競合がいるが。

フロントエンドとして、ACCESSNetFrontは、はいはい省メモリ環境のWebkitですねって感じで、とくに惹かれるものはない。実際HTML5のゲーム出すんだったらIntel Crosswalkみたいなの使うんじゃないか。実際はHTML5っていうか、RPG ツクールMVの需要が強いだろうが。

ゼルダ感想

自分は人より多くのオープンワールドやってる自信あるんだけど、ゼルダゲームデザインはかなり特殊。他のオープンワールドRPGだったら素材拾って武器強化して、という感じになるんだけど、武器は使い捨てというのが大胆なデザインで、その場で調達したものを使い切ることを要求されるという、かなりローグライク的構造に寄ったものになっている。そういえば神トラ2もかなりローグライクに寄った雰囲気があったので、任天堂としてはその路線なのかもしれない。

成長要素としてはハートとがんばりゲージがリニアに成長していくが、基本的なアクション要素が拡張されないのが長時間プレーに耐えうるか若干不安ではある。武器を使い切り、というのが、ダイナミズムを維持するための仕組みなんだろう。

ゼルダは世界が生きてる演出が相変わらずうまいが、とくに行商が多いので雰囲気出てると思う。

ニーアオートマタ感想

クリア済み。よかった。個人的にはもっとエグくてよかったが、思ったよりマイルドな着地だった。 オープンワールドというか箱庭だがプレー感はだいぶオープンワールドっぽさがあった。 ヨコオタロウ相変わらずですねって感じ。セーブデータは例のアレで消去しました。

Horizon Zero Dawn 感想

バタ臭すぎてむせたので放置。いや、オープンワールドゼルダとかぶってるならゼルダ優先するぞって感じ。

Qiita の Increments を退職します

4月からフリーランス。直近半年の仕事は埋まってるけど、パイプ作っときたいとかあれば mizchi2w@gmail.com までメールください。

なんでやめるの?

要約: 自分のスキルの、ベンチャー企業の社員としてスキルミスマッチ

フロントエンドの、とくにSPAで高速で堅牢なアプリを作る、という自分のスキルセットを振り返ると、「需要はあって必要なことには必要だが、どうしても瞬間風速が高いそのタイミングを超えると扱いに困る」という人材適正があると認識しており、前職のQuipperから引き続き2社連続で、「そのために入った最初のプロジェクトが終わると、やや手持ち無沙汰になる」という状態になっていました。

とくにスタートアップのような、予算が厳しい上にピボットする可能性ある現場だと、自分のスキルが活かせないフェーズがある、というのが、会社にとっても、個人のモチベーションとして厳しいものがありました。Qiitaでは、そこをサービスへの愛着を保たせていましたが、どうせなら自分が全力を出せる状況に身をおきたい、それは今ここではないのではないか、という想いがあります。

転職定型文っぽいけど本音は?

↑が長期的な理由で、短期的なきっかけは別にあるけど、ネットで全部言うわけないじゃないですか。まあそのうち外部に出るかもしれないので、わかるんじゃないですかね。

Increments でやってきたこと

  • Kobito for Windows
  • フロントエンド基盤の整理
    • Sprockets => npm/browserify で依存解決
    • coffee => ES6 + Flowtype
    • Backbone => React
  • ユニットテストの環境構築 + 追加

Kobito for Windows が一旦仕上がった段階で、そこにフルコミットするより Qiita の基盤を整備した方がいいのでは、というCTOの提案もあって、Qiitaのフロントエンドの基盤の整理に従事していました。それはそれで中々に面白く、また自分が元々Qiitaというサービスのファンだったというのもあって、楽しくやれていました。Rubyのコードは綺麗だけど、フロントはひでえな、という感じでしたが。

というわけで、2011年的JavaScriptだったQiitaのフロントエンドを、この先10年戦えるように、基盤をしっかり整理してきたつもりです。レガシーなコードは残ってるけど、とりあえず臭いものに蓋できるぐらいに交通整理したので。

独特なキャリアだったので、実はSPA以外の「普通の」Webアプリの体験がなく、その経験は他の業種との連携する上で必ず必要だと認識していて、また自分のスキルの落とし所を見つけるのにどういう戦略がいいか考える機会にもなり、有意義だったと思っています。

企画面で提案したことができなかった、みたいな愚痴はありますが、それは自分がうまく動けなかったからなので、ここらへん聞きたい人は雑に飲みに行きましょう。

今後のプラン

翻って世の中のフロントエンドをみると、SPAの構築やフロントエンド技術で困ってる人達がたくさんいて、フリーランスで短納期でスポットでお手伝いさせて頂くほうが、スキルセットにあってるのではないか?という気持ちがあり、一旦、フリーランスで動くことを考えています。社員はよいオファーがあったら考えます、ぐらいの状態です。

うまく回るようだったら、仕事の量を減らして、苦手な英語を勉強して可能性を増やしたいですが、アメリカが新大統領であんな状態なんで、すぐ渡米したいみたいな気持ちはないですね…。

やめるけれど、Qiitaというサービスは今後も頑張ってほしい。あとフリーランスなので、今後またQiitaに関わる可能性がないわけではないです。Kobitoに関してはこれから動きがあるので、後々。

mizchi への仕事のオファーについて

知り合いのツテを使って、直近半年ぐらいの仕事は埋まりそうなんですが、仕事のパイプがほしいとか、フリーランスでのオファーがあったら miz chi2w@gmail.com か、Twitter でフォロー関係があれば Twitter の DM なりでご連絡ください。Facebookは嫌いなのであまり見ていません。SPA設計や React の社内研修やってほしいだとか、ペアプロしてほしいとか、そういうのも歓迎です。

ただ、スキルセットが3ヶ月~半年程度のスポット向けであるということのリスクテイクと、フリーランスになる相談をした人からの、「お前は名前が売れてるから安く受けると全体の迷惑で、人月1xx万以下では仕事を受けるな」という指導?があり、それはそうという感じなので、あんまり安く受けるつもりはありません。xxの部分は公開すると差し障りありそうなので、直接きいてください。

というわけで、僕が興味がなかったり、「安くだったら〜お願いしたい」というような依頼はお受けできませんので、返信しない可能性があります。その点、よろしくお願いします。

修正済み: ニーアオートマタ進行不能バグの原因と対処 #ニーアオートマタ

追記: 修正されました

壊れていたセーブデータからも正常な状態に引き継げたのを確認しました。


色々と情報を集めた結果、完全にDL終わってない状態でチュートリアルステージをクリアして、DLの差分を待つ状態が発生した場合、レジスタンスキャンプより先に、格納庫のクエストを受けると進行不能になるというバグがある模様

対処法、完全にDL終わってなくても開始できるんだけど、できれば完全にDL終わってから開始したほうが安全かも。

週末までには治ってくれ。