悪童日記 / 感想
読み終わった。
- 作者: アゴタクリストフ,Agota Kristof,堀茂樹
- 出版社/メーカー: 早川書房
- 発売日: 2001/05
- メディア: 文庫
- 購入: 100人 クリック: 3,630回
- この商品を含むブログ (275件) を見る
- 作者: アゴタクリストフ,Agota Kristof,堀茂樹
- 出版社/メーカー: 早川書房
- 発売日: 2001/11
- メディア: 文庫
- 購入: 38人 クリック: 327回
- この商品を含むブログ (118件) を見る
- 作者: アゴタ・クリストフ,堀茂樹
- 出版社/メーカー: 早川書房
- 発売日: 2006/06
- メディア: 文庫
- 購入: 40人 クリック: 332回
- この商品を含むブログ (110件) を見る
1巻、2巻、3巻と全部異なる楽しみ方ができて良い。双子、三人称、信頼できない語り手、と主観の揺さぶり方がうまく、それによって再読したくなるギミックが随所に仕掛けられていた。ポーランドのナチスドイツ占領下からソ連による「解放」までの、重く退廃的な雰囲気がいいスパイスになっている。
ただ、Twitterで書いたような印象にも引っ張られてしまった。
悪童日記3巻まで読み終わったけど、2巻の途中からMother3の元ネタだというのがわかってしまい、糸井重里はどういう気分でこれを読んでMother3作ったんだということばかり気になって、自分の感想というよりMother3を生むに至る糸井重里の感想の感想という感じになってしまった
— 現場の声 (@mizchi) 2017年3月14日
3巻は「第三の嘘」のこと。まあ、リュカとクラウスという名前以外は、ほとんど関係ないんだけど…
ニンテンドースイッチ感想、ゼルダ序盤の感想、ニーアオートマタ感想
フリーランスになる前に好みのゲームがどばーっと出てるので消化しきらねばならない。
ニンテンドースイッチ感想
これは据え置き機ではない。ちょっと大きい携帯機だろう。おそらく3DSとのMigrationパスを探ってるんだろう。 WiiUの中途半端なリモートプレイはこの為の実験だったとすら思える。「画面が小さくない」のはモバイルとの差別化だと思う。そこで差別化しないといけないのは悲しいところだが。 モバイル機が立体視2画面ではないのは、推進してた岩田さんがいなくなったからだろう(これ事態はとても悲しいことだが…)。ゲーマーは特に望んでない機能だったので、GBA路線が復活したと思うと嬉しい気はする。
スペック競争に参加していない任天堂はおそらく(他よりも遥かに)本気でインディーを取りに行くべきで、とくに2Dのゲームと相性が良いはず。発売が決定してるStardew Valleyとかバク売れするんじゃないか。Vitaが死に体で、GPD Win みたいなお遊びが競合なら、そこに負けるはずはない。iPhone/Android という強すぎる競合がいるが。
フロントエンドとして、ACCESSのNetFrontは、はいはい省メモリ環境の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の部分は公開すると差し障りありそうなので、直接きいてください。
というわけで、僕が興味がなかったり、「安くだったら〜お願いしたい」というような依頼はお受けできませんので、返信しない可能性があります。その点、よろしくお願いします。
修正済み: ニーアオートマタ進行不能バグの原因と対処 #ニーアオートマタ
追記: 修正されました
1.03VUを行いました。PlayGoの不具合修正を実施しました。DL版で開始した方には大変ご迷惑お掛けしました。申し訳ございません。また開発の意図とは違う誤解を招く表記となっていたご指摘頂いたアイテムの名称を変更しました。不具合の検証と対応は引き続き行って参ります。 #NieR
— 齊藤陽介 Yosuke Saito (@SaitoYosuke_Z) 2017年2月24日
壊れていたセーブデータからも正常な状態に引き継げたのを確認しました。
色々と情報を集めた結果、完全にDL終わってない状態でチュートリアルステージをクリアして、DLの差分を待つ状態が発生した場合、レジスタンスキャンプより先に、格納庫のクエストを受けると進行不能になるというバグがある模様
対処法、完全にDL終わってなくても開始できるんだけど、できれば完全にDL終わってから開始したほうが安全かも。
DL終わったのでニーアオートマタの続きやる https://t.co/qIZWTLpg40
— 現場の声 (@mizchi) 2017年2月22日
ニーアオートマタ、どうもバグ分で進行不能になったっぽいぞ… https://t.co/tmrZ5Hlkmk
— 現場の声 (@mizchi) 2017年2月23日
バグ踏んだ
— 現場の声 (@mizchi) 2017年2月23日
キークエスト受諾不可、サブクエスト報告不可です
— 現場の声 (@mizchi) 2017年2月23日
このプレー手順でキークエスト受諾不可で進行不能です https://t.co/7T1bTkvUfs #ニーアオートマタ
— 現場の声 (@mizchi) 2017年2月23日
あーチュートリアルステージ終わって、DL待ちが発生した人で、レジスタンスキャンプより先に格納庫のクエストを受注した人が進行不能バグ発生、という報告があり、俺完全にあてはまってるな
— 現場の声 (@mizchi) 2017年2月23日
たぶんチュートリアルステージでDL差分受け止める際のマージ処理がミスってて古いマスターデータかなんか食って不整合起きてるんじゃない? #ニーアオートマタ
— 現場の声 (@mizchi) 2017年2月23日
週末までには治ってくれ。
ロックイン
Rebuild.fm の mirakui さんの回聴いてたんだけど、インフラの世界観だと、ロックインさせたい Amazon/Google VS 自由を手に入れたいDocker みたいな構図がある、な話があって、思うところがあった。
勿論、話はそう単純じゃないし、それぞれがそれぞれの成果を利用しあってるので、どっちが正義だみたいな話にはならない。第三者目線としては、寡占にならず競争が続くのが望ましい。僕個人の意見としては、金が生まれるところには、正しく金が生まれてほしい。それで全体としての健全性が育まれるなら。日本にいてあんまり面白くないのは、その辺の基盤技術に関われる機会があんまりないことだが…。
とはいえ、利用者目線としては、できるだけ自由なポジショニングを可能な限り選び続けるべき。だが、自由を手に入れるには、それだけの知識が必要となるし、そこを諦めたところをアウトソースなり、ロックインされることになる。
何にBetするか。これは難しくて、第一言語に引きずられるし、フロントエンドやってる僕も、「最近のお前の技術選定はFacebook党だろ」と言われたら否定できないが、別にFacebookから金をもらってるわけではないので、その点では自由ではある。いいと思ったらいくらでも鞍替えする。CoffeeScriptを諦めたように。
で、最近困ってるのが、フロントエンジニアとしての専門性を高めた結果、インフラをやるにあたって、何にBetするか、で、やはり自分の今の競争力を担保するために、少ない時間で最大限の成果を、という判断基準になる。必要なのは、DB抽象とオートスケール。そうすると、ある程度ロックインされた方が、やはり幸せなのではないか?という気持ちがある。
最近調べたのは AWS Lambda/DynamoDB と Firebase で、ラピッドプロトタイピングで邪魔されない程度に機能が揃ってると良い。そうなると、ロックイン度が高いFirebaseがやはり選択肢になってくる。
でもなー、やっぱFirebaseはなー、クソーという気持ちにはなる。ストレージに掛けられる制約もゆるいし、それによって実装できるアプリの性質が結構変わってくる。Todoアプリぐらいだったら問題ないけど、ゲームのセーブデータを預けろ言われると無理そう。あとなんとなくGCPとかGKEとかGAEがこっちを見てる気がする。
AWS Lambda もそんな嬉しくはなくて、結局あの膨大なAWS関連サービスを使いこなさないとちゃんとしたデプロイまでたどり着けなくて、それに試してわかったけどDynamoDBもかなり特殊なデザインだし、あれをNoSQLとして長期的にメンテ出来るかよくわからなかった。調べた感じMigrationに難がありそうだった。難というか、何も支援がない、という感じで。
ここで個人として取れる戦略は、とりあえず Storage Pattern とかでDBへのアクセスを抽象化しといて、プラットフォームごとに実装を切り替える余地を残しておく、みたいな、とても普通の結論になる。
まあ大抵は僕一人で作るわけじゃないので、AWS系だと扱えるエンジニアが多いの考慮してS3とLambdaとDynamoでちょろっと作るか、最初はFirebaseで作ってあとで切り替えるみたいな展開を想定しておくといい気がする。って感じで今はFirebase使おうとしてるけど、どのぐらいスケールして、どのぐらい金を払うことになるか、の肌感がないので、提案するにも怖いなぁ。いやー金払うのを躊躇するレベルになったらインフラの専任付く余地あるから別に考えなくてもいいんじゃない?いやそういう発想が逃げなの?恥ずかしくないの?いやー僕は基本はフロント沼掘ってるんで任せますよー。えーどうなんでしょうね。
結局アプリケーションエンジニアはDBアクセスを抽象化しましょうねーという当たり前のゴールだけしか見えなくて辛いなーJSにいいORMないからなーActiveRecordほしいなーでもRDBMSだけじゃなくて各NoSQLやIndexedDbという対象がプラットフォームとしてあるから難しいなーという感じです。
オチはないけどこのへんで悩んでます。知り合いが多いGoogleやトップゲート社方面からFirebaseやれよと言われるのまでは見えてる。
GraphQLを勉強した
自分でGraphQLサーバーを実装しながら勉強したログ。間違ってるかも。
コードはここにあるが、何の注釈もない。 https://github.com/mizchi-sandbox/play-graphql-server
RESTの課題
REST は URI とモデルのマッピング構造だが、往々にしてクライアントで必要となる構造は モデルのうち一部であったり、そのリレーショナルな構造に依存する。 つまり、REST というルールに従って必要なデータを組み立てると、リレーショナルな構造によってN回のリソースへのアクセスと、興味がないデータを含んだ不要なペイロードが発生しがちである。
GraphQL は何をしたいか
- 1リクエスト内でモデルへの問い合わせを合成し、さらに必要なものだけ返却したい
- 言語とは独立した、転送経路上のモデルの定義を行いたい
パフォーマンス上の理由とセマンティクスが同居しているが、不適当な要求ではない、と思う。
GraphQL の解決アプローチ
GraphQLサーバーは、まずモデルのプロパティと、他のモデルとの関係のグラフ構造を定義する。次に、クライアントに対して公開するクエリを定義する。
GraphQLクライアントは、使うクエリの選択と、その絞込みクエリの2つを同時に送信する。
クライアントからクエリを受けたGraphQLサーバーは、クエリ定義にそって、なんらかの方法で実装されたモデル抽出関数などを叩き、そこで得られたモデルを、定義にしたがって合成し、絞込クエリによってフィルタし、返却する。
URL的には、シングルエンドポイントを持ち、そこに向けてクエリを発行する。モデルの合成は1リクエスト内で行われる。RESTリソース的なセマンティクスは、GraphQLは興味がない。
GraphQLは何をしないか
- バックエンドの実装
- データの通り道のスキーマを定義しているだけ
- なんらかの言語の実装によって自分で書く必要がある
- 最終的なペイロードに載せるデータのフィルタリングはGraphQL側が行うが、その組立は自分でやる必要があるため、その過程にパフォーマンスの劣化は当然発生する。たとえばRubyバックエンドで ActiveRecord の
to_hashなんらかのシリアライズ(追記: ActiveRecord::Baseにto_hashはない、とのこと)で深いリレーショナルのプロパティを掘り出してしまったら、そのSQLコストは発生する。
- データの転送経路の指定
- HTTPでもWSでも生のソケット通信でもなんでも良いが、環境ごとに実装する必要がある
- 極端に言えばローカルのIndexedDBへローカルのクライアントから問い合わせる、などもある
バックエンドはなんでもよい。MySQL, MongoDB, In Memory、DynamoDB、etc…。 実装言語と独立しているため、サーバークライアントともに、実装は何の言語でも良い。サーバーをElixirで実装してiOSのGraphQLクライアントから呼ぶ、というようなケースも全然あるだろう。
GraphQLのスキーマ
クエリは大きく2つに分類でき、QueryとMutationがある。スキーマ上の type Query {...}
と type Mutation {...}
は特殊化されていて、それらの名前空間はクライアントの query {...}
と mutation {...}
に対応し、いわゆるトップレベルスコープのような扱いになる。それら2つは明確に区別されている。が、実際にどう副作用が起こるかは実装依存なので、queryで副作用を加えることは、一応可能である。やらないとは思うが。
雑感
目的に対して妥当な実装ではあると思うが、資料が少なく、未だ学習コストが高い。その学習コストを乗り越えれば、クラサバ間の通信仕様として、有効かもしれない。
シングルエンドポイントというのが、AWS Lambda などとも相性がよく、DynamoDBバックエンドなどとも有効な組み合わせになる。
自分はFlowtypeで書いていたが、静的型付けな言語環境では、GraphQLスキーマとその言語上の型を2つ定義する必要があり、やや面倒ではあった。ジェネレータがあるといいかもしれない。Subtypingできる言語ならややマシかも。
と思って調べてたらFlowtypeではGraphqlを直接パースするというアプローチを実装中だった。ただ、いまいち何の型をみてるのかよくわからない。Relay以外で使えるのか。https://github.com/facebook/flow/pull/2822