タオルケット体操

サツバツいんたーねっと

スプラトゥーン なぜお前はいつも打開に失敗してボロ負けするのか

よく来たな、俺は墨噴射八兵衛だ。俺は毎日すごい量のツイートをしているがあまり長文は書かない。だがスプラトゥーン2に関しては別だ。今日はスマッホでSiriから聞きかじった内容でバランス調整に文句を言うことに気を取られてナイフを研ぐことを忘れた腰抜けどもにメキシコの荒野で生き抜くための基礎を叩き込むためにやってきた。
最近スプラトゥーンの日記ばかり書いているように見えるが実はマッチングのレーティングがあまりにもファックすぎることに腹を立てて一ヶ月以上プレイしていなかった。Ver1.3.0で向上されたというアナウンスーがあったので戻ってきて、こうして今日の長文を書いている。

(スポイラー:今日の文章はダイハード・テイルズで時々素敵な文章を寄稿してくださっている社会派コラムニスト、逆噴射総一郎先生から大いにインスパイアされた文章スタイルになっています)

この文章を読んでいるお前らは当然スプラトゥーンを知っているだろうが念のために教えておくと任天堂が製作したTPSシューティングゲームのことだ。そしてあたりまえだが本稿では最新作である2を基準に語ることになる。
任天堂が作ったホットなイカのベイブに騙されてはいけない、このゲームはそうとうなハードコアでナメてかかったアホはT-1000のように突然インクから現れたローラーに頭を殴られ、クラゲ以下の無残な死を迎えることになる。任天堂が作る対戦ゲームはいつだってハードコアで人を熱くさせる。エンジョイ勢を気取った連中も負けがこめば発狂してjoy-konを投げつける狂気のインク・バトルグラウンド。つまりメキシコだ。

だがお前らはこのインクのジャングルで生き残るために必要な知識と知性があっとうてきに不足している。おまえらはスマッホを手に持っているが検索に必要な知識をもっておらずYAHUU知恵袋などで「S+のひとにしつもんですが感度はいくつですか?」などと無意味な質問をすることに費やしてしまいどうしようもない。

なお今回のメキシコはあくまでスプラトゥーンを対戦ゲームに勝ちたいというゲーマーの基本的欲求に正直なものへと向けて書かれたものだ。勝ち負けに興味のない人間やサーモンランといった別のメキシコに惹かれた者たちは読む必要がないので帰るがいいだろう。
またすでにS+の維持*1が安定しているバンデラスやカンスト組のマリアッチも当然こんな文章を読む必要はない。

*1:正直今作のレーティングはもはや意味をなしていないのでS+にあまり意味はないが一応

続きを読む

スプラトゥーン2のゲームバランスについて俺も一言物申したい

追記:この日記はver 1.2.0よりも前に書かれたものです。

最近、空き時間はほぼ全てスプラトゥーンに費やしてましたよ。先週末にようやく全ルールS+(とはいえ強ブキ使ってガチパワー1900〜2000前後をうろうろしてるくらいのレベル感)になってケジメがついたのでゲーム以外のことに時間を使う気持ちになれました。

ちなみに今回の論についてはガチマッチ前提で語りがちですのであしからず。

  • 今回の全体バランスに対する雑感
    • ブキの調整について
      • シューコラ、ヒッセンそしてジェットパック、インクアーマーについて
  • ロビーでの装備変更ができない仕様が全ての元凶
    • 編成をランダムにしつつ運ゲーを防ぐ提案
  • スプラトゥーン2のe-sports展開の可能性について
  • まとめ
  • 追記

今回の全体バランスに対する雑感

続きを読む

スプラトゥーン2のためにNintendo Switchでサラウンドヘッドセットを使う方法について調べた

そもそもスプラトゥーンってヘッドセット必須なの?

(必要)ないです。せっかくもっているんだから試してみたかっただけです。

スプラトゥーンはR6SやPUBGのように1デスの重たい足音ゲーであったり、OWのようなサウンドデザインで裏取りなどをコントロールしているゲームではありません。
床を塗るというルールの都合上、敵味方がそこらじゅうで銃を撃ちまくっています。そしてBGMの音量がかなりでかいので金属床をのぞいて基本的に足音はきこえません。

これらの理由からサラウンドヘッドセットを使うメリットは特にありません。
たいていのFPSはサラウンドヘッドセットで有利に立てるようにデザインされてますが、任天堂的にそういう周辺機器で差がつくようなゲームデザインは避けたかったのでしょう。

続きを読む

プログラマーは業務時間外でも勉強すべきかどうかについて

そんなことを考える暇があればスプラトゥーン2やろ

マジレスすると

  • 「プライベートでもプログラミングするくらい好き/ではない」
  • 「業務時間外であっても勉強すべきだと考えている/いない」
  • 「優秀なプログラマーである」

は相関があるようでそれぞれ個別の問題なので分けて語った方がよいかとおもいます。

一番の人は優秀である確率が高いですが、こういった人が普段している活動は

  • 仕事ではまだしばらく使えないようなエッジの技術を試す
  • 仕事では避けるようなマニアックな技術で遊ぶ
  • 自分でサービスを作って運営する

などで、これらの活動によって「流行ったばかりの技術を軽々使いこなす」「コーディングテクニックがすごい(語彙力)」「一人でサービスローンチまで一通りできてしまう*1」というようなスキルが身につく(つかないこともある)わけです。
ですが、こういった"活動"は「業務時間外でも勉強すべき」という軸足が仕事にあるようなタイプの人間はまずやらないことなのです。

反面、軸足が仕事にある族の人たちがする勉強は業務をスムーズに遂行するためのものなのでムラがなく、成果に結びつきやすいものであることが多いです。でも資格だけは勘弁な。

プログラミングが趣味族の人間は誰も知らないようなことを知っていたり、突然すごいパフォーマンスを叩き出したりする一方で、つい我を忘れて暴走したり、仕事という窮屈なしばりでするプログラミングが退屈すぎて反乱を起こしたりする扱いにくさを持つ傾向にあります。
あとプログラミングはただの趣味で義務感などは存在しないため、スプラトゥーン2などの等価な楽しみが出現するとそちらに突っ走ったりします。
個人的な意見です。

最後の優秀さについて。
効率よく云々の話はありますが、スキルというのは概ね勉強している時間に応じて伸びるものです。そして先述したように趣味活と業務向けの勉強はベクトルがかなり別の方向を向いています。
してる、していない。すべき、すべきでない。などを論じるのも良いですが、例えば経営者の方などであれば自分がどういう人間を欲しているのか分析した上で採用をすると
「あいつプライベートでも勉強してるっていってたのに全然使えないんだけど」
といってしまうような不幸なすれ違いを防げるんじゃないかなとおもいました。

ちなみに仕事中以外なにもしてなくても優秀というチートっぽい人も中にはいますが、ソフトウェアエンジニアリングという領域は求められる知識がそもそも膨大なので、四次元殺法的な引き出しの多さはやはり趣味活によってのみもたらされるものでしょう。というわけでこういった人たちは仕事軸足族よりのスキルセットであることが多いです。
それとは別に仕事中であっても勉強しない人がいますが、そういう話は不毛なのでやめておきましょう。

じゃあ自分スプラトゥーンあるんでこれで。

フレンドコード: SW-0963-2705-5306

*1:非ITエンジニアの人が考えるフルスタックはこれです

Reduxバリデーション実装パターンとReducerの呼び出しを遅延させたい問題(debounced-action-dispatcherを作りました)

アイデアです。
ちなみにredux-observableやredux-sagaを導入している場合はそちらで解決したほうが良いんじゃないかとおもいます。

f:id:hachibeechan:20170714180530p:plain

MVXアプリケーションのバリデーションとパフォーマンス問題

Reduxを使っていなかったとしても、Reactを使って素朴にアプリケーションを開発しているとある程度以上の規模になって発生するのがバリデーションのパフォーマンスではなかろうか。

最初は一つのinputに対応するプロパティの正当性を素朴に判断するだけだったのが、ある程度の規模になった時点で同一モデルの他のプロパティも一緒に合わせてみなければいけなくなったり、あるいは他のモデルの面倒もみないといけなくなったり。 そのうちに、あちこちに散らばっていたバリデーションのロジックを一箇所に集めたくなる。それが終わったら次はパフォーマンスの問題だ。Facebookのアプリケーションなどを使ったことがある人はわかるだろうが、textboxで一文字入力するたびに画面がプチフリーズするうえ、ボタンを連打しようものならしばらくブラウザが固まってしまう。Facebookのアレはバリデーションの問題だけではないのだろうが、無関係でもないだろうとおもう。ともあれ、ユーザーの連続入力が終わるまでバリデーションを待機して別に悪いことはないだろう。

ここで問題になるのは、一体どこの関数呼び出しをdebounceするかという問題だ。

“純粋"関数縛りがあるのでreducerはなし。となるとActionCreatorかCallbackということになるが、ただでさえThunkやなんかのせいでカオスになりがちなActionCreatorにこれ以上余計なボイラープレートを噛ませたくない。 Callbackだが、例えばActionCreatorが常にPromiseを返すようにして終了を監視するようにすればあるいはバリデーションの非同期な呼び出しは可能かもしれないが、明らかに責務の範囲外で筋悪な実装のようにおもえる。

やはりActionをObserveしているReducerが、Storeへ引き起こす変更を検知してバリデーションを行うべきなのではないか。ですよね?

そこでMiddleware(redux-debounced-action-dispatcher)

実はReduxの各層においてActionをObserveしているのはReducerだけではない。もうひとつMiddlewareでも同様のことが可能だ。 (ReduxのこれはMiddlewareというにはなんでもかんでも実装可能すぎてどうなんだろうという気持ちがないでもない)

というわけで作ってみた。 https://github.com/hachibeeDI/redux-debounced-action-dispatcher

サンプルにあるように、TRIGGER_ACTIONSにバリデーション(あるいはLocalStrageにキャッシュするとか)のキーとなるようなActionを宣言して、DEBOUNCED_ACTION_TYPEにそれを受けて発行させたいActionを宣言刷るだけというような使い方になる。

import createDebounceMiddlewareGenerator from 'redux-debounced-action-dispatcher';


const TRIGGER_ACTIONS = [
  'HOGE_CHANGED',
  'FOO_CHANGED'
];

const VALIDATION_DEBOUNCE_TIME = 500;

export const DEBOUNCED_ACTION_TYPE = 'VALIDATE_ALL_DATA';

const debouncedValidationDispatcher = createDebounceMiddlewareGenerator(
  TRIGGER_ACTIONS,
  DEBOUNCED_ACTION_TYPE,
  VALIDATION_DEBOUNCE_TIME,
);

const store = createStore(
  todoApp,
  applyMiddleware(debouncedValidationDispatcher)
);

使いこなせるメンバーで構成されているならばredux-observableやredux-sagaなどが導入するEpicなんかで解決すればいいだろうが、これら2つのMiddlewareはそれなりに難解で、かつオーバーキルな印象がある。
僕の作ったMiddlewareの利点は簡単なことで、欠点はそもそもredux-actionsなしではカオスになりがちなActionの管理だが、TRIGGER_ACTIONSが膨れ上がるとさらに意味不明になってしまうことだ。これは例えば正規表現のサポートを実装して、各アプリケーション内で厳格な命名規約を導入すれば防げるかもしれない。

まとめ

ReduxでSPAのエラー情報の管理を一体どうやっているのかの話をあまり見かけないので僕なりの考えを書いてみた。

たぶんもっといい方法があるだろうとはおもうので教えてくださいお願いします。

今ブログを書きながらふと思いついたが、そもそもエラー情報をReduxのStoreで管理するのはやめて、例えばreselect(https://github.com/reactjs/reselect)を使うようにするなんてのもありかもしれない。その場合、debounceは不可能になるがmemorizeしてくれるのでパフォーマンスへの影響も多少軽減できるのではないか。

まとまりがないけどもこちらからは以上です。