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

フリーランス一週間目、不安、人格、Redux

契約先

週3でアカツキ様、週2でリクルートテクノロジー様で開発に関わらせてもらっている。どちらも公開の許可を貰った、というかむしろ宣伝してくれと言われた。アカツキは @seizans さん、 リクルートテクノロジーズは @yosuke_furukawa さんの繋がりで仕事をとった。事前に面識がある人に相談することで、人格面や技術面のすり合わせが楽で、ゼロベースの信頼関係にならず対人関係のストレスが減るようにコントロールした、つもりではある。

全く違う仕事をしているのではなく、どちらも redux 周りをやっている。みんなそこで苦しんでいる。今、界隈を絶望させているのは react-router v4 であり、これが諸悪の根源であるといって差し支えない。既に辛い気持ちなっている。絶対に倒したい。

ネットの人格

契約先の話で思い出したんだけど、僕はネットで暴れてる方と、リアルで卑屈になってる人格に乖離があるので、前者のせいで警戒されている、と感じていて、そのイメージは崩していきたい、と2年ぐらい前から思っている。ブログだと、まだ冷静なんだけど、Twitterは、本当に思ってもないことを言っている。言い訳すると、フォロワーが多くて言いたいことを言うには、マジレス避けに多少気が狂ってるふりをする必要がある。

木を隠すなら森。

Redux について

いくらか誤解があった。リクルートテクノロジーズで koichik さんと議論して幾らか解決した。いろいろとネガってきたので、あとで別途記事を書くが、要は middleware はいわゆる middleware ではなく、 input: Aciton => Promise<Action> とでも表現する、 mapAsync な層だという話。名前が悪い。

それとは別に、やっぱまだ好きじゃない気持ちがあり、しかしコミュニティの力は偉大で、我々はそれに巻かれるしかない。それがマーケティングの敗者の敗戦処理。僕は、そこに訴求できる人間になりたかったのだけど、国内はある程度できるとして、海外の趨勢は何とも言えない。

とはいえ、猫も杓子も redux という世界観は絶対に間違っていると思う。

不安

これはしゃーないと思っているのだが、最初はどうしても環境構築/キャッチアップから入るので、自分のやりたいレイヤーにたどり着くまで時間がかかる。で、まだ2つの環境では、まだキャッチアップしかできていない。 また、使ってるフレームワークの、使い方がそのプロジェクトでどう決まってるか、どこからドメインなのか、で、頭の使い方が変わる。コンテキストスイッチもある。

あと、自分が知らないことを、周りの人がみんなが知っていて(勿論ドメイン知識の差だというメタな認識がありつつも)、卑屈になりがちで、ハハァソウナンデスネースゴイとなりがちで、こんなんでいいのか、もっと短期にバリューを出さないと、フリーランスとして価値が出せてると言えないのではないか?という焦りもある。新しい環境とはこんなもんだ、というのもある。

自分より凄い人がいて、自分が劣っている、という劣等感は常にあるんだけど、実はあまりマイナスのものだと思っていなくて、自分がプログラミングを覚えて、その後成長したのも、それがあったからだと思っているので、この劣等感は大切にしたい。勿論、これを感じることによるストレスを扱いきれるかどうかは、その人次第なので、みんながこうあるべきとは思わないが、自分はそうという話。

あと、最近わかったのは、自分は不安を感じると事務作業に逃げる傾向がある。不安の種が別の不安を生むので、小さい不安をとりあえず排除したくて、税金周りの手続きを、徹夜ですませたりした。むしろ、不安がないと楽観しすぎてこの作業が進まないので、たまに必要だという気がする。不安がなくてもやるべきだが。

休日のとり方

フリーランスの休日というものが、よくわからない。週のうち何日働くという契約だが、GWとかどうなるんだろう。お伺いを立てるんだろうけど…。

結局この週末は知識が追いついてない不安を排除するために勉強時間にあててしまっている。一回倒せば2年ぐらい大丈夫そうなんで、やっておくが。

今後の技術的な方向性

  • redux middleware を倒す
  • flowtype の普及に努める
  • Backend For Frontend
    • next.js
    • さらにその間の層として ServiceWorker がありそう
  • react-native?

Reactはもう僕が宣伝しなくていいステージにきていて、ぶっちゃけView基盤としてのReactは簡単で、特に教えるものはないと思っていて、やはりその周辺、redux middleware 周りにドメイン知識の差が出る。

フロントエンド特化から Backend For Frontend までレイヤーを一つ増えた感じはある。

react-native は需要の高まりを感じており、モバイルというものそのものが嫌いだが、react-native の技術的な方向性は好きで、需要から逃れきれない雰囲気などもあり、Universal JavaScriptの文脈で、とりあえずキャッチアップはし続けておく。

読書

移動時間が増えたので、Kindle積読を増やして消化していっている。最近は「高い城の男」を読み終わって「スカイ・クロラ」読み始めた。あと Rebuild.fm の未消化のやつ。

ニンジャスレイヤーの第三部の真ん中から先を読み直したいのだが、1年読んでないので忘れてしまっている。

スプラ2試射会感想

https://topics.nintendo.co.jp/c/article/1e79cd99-ec4b-11e6-9aaf-063b7ac45a6d.html

6回中、4回参加

よかった時のを貼ってるだけで、実際のキルレは2.0ぐらい。ほとんどローラー持ってた。試射会2時間前からスプラ1を久しぶりに起動して、仲間内のナワバリでエイムを温めていた。やっぱ1年放置してると鈍っている。

雑感

どうしても初心者狩りになりがちで、すまんという気持ちはありつつも、興奮が抑えられず、安全圏から離れた敵は見つけ次第狩りにいってしまっていた。とはいえ初心者とそれ以外をゾーニングするのは任天堂がマッチングでなんとかしてほしいんだが…。後半ほど手応えがあったので、内部レートがあったような気がする。わからん。

回線、自分は一度も落ちなかったが、8人中、誰か一人は落ちてて、ワンサイドゲームになりがちだった。これは改善してほしいが、自分が一度も落ちてないことを考えると、そもそも改善品質に問題がある人(テザリングなど)がそれぐらいで紛れてる可能性はある。

ブキ

スペシャルが基本的に抑え目。打開というより、全体的に安全圏から落ち着いて使わないといけないような技に寄せられてる。スプラ1が無敵ゴリ押しゲーになってる現状、無敵は今後も追加されないか、なんらかのトレードオフとともに実装されるだろう。

ローラーの縦振りは足りない射程が得られるがエイム要求が厳しい。外すと死を覚悟するやつ。ローラー同士だと落ち着いて横振りを出せる方が勝てる印象だった。発生も同時なら横振りのが速い。とはいえローラーの腐りがちな中距離戦で選択肢が増えたのはいいことだと思う。スーパーチャクチは初見殺しで強かったが、試射会終盤だと徐々に見切られていたので、実際の運用できる使い方は限られる気配がある。壁際に追い込んで使うか、完全に意識の外から使うか、どっちか。無理に距離を詰めるムーブは既に試射会中でも見切られていた。

マニューバは何一つシューターに勝てておらず最弱という仲間内の評判。レートか飛距離が上がらないと未来はなさそう。ジェットパックは操作に慣れてる人がおらず、あんまり脅威ではなかった。

シューターはいつもどおりの性能。サブ次第でこれからもトップメタ張り続ける気がする。ミサイルランチャーは追い込み用で、単独でキルを取るというより、索敵兼、退路を固定して追い込んで狩る用という感じ。今回のスペシャルの中では一番使いやすい。

チャージャー、わからん。あたらん。上手いチャージャーは無限にうまい。

発売まで

夏になったら起こして。

今、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 感想

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