銀ダイナモですがS+昇格に失敗しました(S99)
今はS70まで落ちて反省している。
スプラトゥーン、最近 @omochimetaru さんや @mizuharayuki さんらへんでS~S+のフレンドとタッグマッチやプライベートマッチで遊ぶことが増えたんだけど、彼らと戯れた結果、苦手ステージは本当にダメなんだけど、僕も得意ステージならS+いけるのでは??いや〜でもそんな都合いい組み合わせないよな〜と思ってこんなツイートしてたら、本当に来てしまった。
t.co一番得意なのはハコフグエリアとモズクエリアなんで任天堂頼むよ
— ダイナモS99カンスト (@mizchi) November 11, 2015
18時間前のツイート https://t.co/tBENLO38Nj 23:00~03:00 のルール https://t.co/jvLTLU4t86 マジかよありがとう任天堂
— ダイナモS99カンスト (@mizchi) 2015, 11月 12
ステージ 12C2 とルール3つで 1/(66*3) = 0.5% の確率引いたことになるけどマジかよ任天堂俺のツイート見てないだろうな
— ダイナモS99カンスト (@mizchi) 2015, 11月 12
当日は実況プレイ、というかマイクを入れてゲームプレイをtwitchでタレ流ししてて、なんか最高で30人ぐらいに見られてたんだけど、twitchの自動録画機能で4時間分録画されてる。youtubeへのexport機能で S+昇格戦のところを切り出してアップロードした。
未編集の録画はこっち http://www.twitch.tv/mizchi/v/25395430
見どころとしては、自分以外S+の部屋に突っ込まれて、劣勢時に味方頼む〜っと泣きながらバシャバシ塗ってるとこですね。
反省
最近の反省点として、プラベのS+連中に思い知らされたんだけど、ナワバリやり過ぎたせいで相手がガバることに甘えて突撃する癖がある。S+相手だと一方的に死ぬ。リスク負ってでも前に出るところとそうでないところの判断がまだダメ。なので悪い癖つかないようにナワバリあんまりやらないようにした。
あとダイナモで段差の後ろに隠れたとき。振る前に小ジャンプで障害物の上を一瞬越えるようにして振ると強いんだけど、その入力精度がまだあまり良くない。
録画見直すとスピナーに弱かった。
スプラトゥーンアドベントカレンダーに登録したので、それまでにS+昇格報告したい…
ギア
フクをマキガ+インク効率x3 にしてる時もある。
録画
twitchで生放送してて、たまに動画アップロードしてる。主に自分で見返すようだが。
https://www.youtube.com/channel/UCDIj9TmckobVQT2KyXIwxnA
この動画、なぜか味方のトラップで死んでて面白い。
趣味プログラミング業
ゲームやりまくる時はひたすらゲームやってるんだけど(2年前のLoL業のときもそうだった)、RPGツクールMVアドベントカレンダーのためにRPGツクールのエンジン部分のコードひたすら読んでるんで、その辺あとで報告したい。
型付きJavaScriptの将来についての最高のシナリオ
typescriptが独自AST捨ててEcma準拠して今のflowと同じTypeCheckerだけの存在になって、Babel が TypeScript の型アノテーション互換になり、ESNextで型アノテーションが仕様化されるのがフロントエンド界最良のシナリオ。そうならんだろうが
— Dvorak対応型人類 (@mizchi) 2015, 10月 14
実際はFacebookとGoogleとMSのメンツが掛かっててややこしくなってる
— Dvorak対応型人類 (@mizchi) 2015, 10月 14
babelのsebmck(18歳)がfacebookに入ったのは吉と出るかどうか
実際外部に依存しないならflowとtypescriptの両方のサブセットでどっちでも動くコードを書くのは難しくない。castとnullable が使えないが
— Dvorak対応型人類 (@mizchi) 2015, 10月 14
あるいはtypescriptがいらないぐらいにflowが発達するのも筋悪ではないが今の開発ペースだとダメそう
— Dvorak対応型人類 (@mizchi) 2015, 10月 14
flowは外部ライブラリ呼んだり野良ライブラリの型アノテーション違反を握りつぶすのがとにかく苦手で実用足り得ない、という認識です。
さらなる理想を言えばES Nextで型アノテーションを仕様化したあとで use native みたいなフラグ追加して全てのノードの型が判明していればネイティブコンパイル出来るって状態までもっていけたら最高。実は既にtypescriptを直接JVMに落とす実装は存在してる
— Dvorak対応型人類 (@mizchi) 2015, 10月 14
今の段階でやってるのは気が狂ってると思う。
そうすればJSの規約の追加だけで自分自身で高速なwasmをコードを吐けるようになる
— Dvorak対応型人類 (@mizchi) 2015, 10月 14
ここではV8を想定してます
まあ夢ですけどね
— Dvorak対応型人類 (@mizchi) 2015, 10月 14
イカSランク到達
A+30から14勝5敗で Sランクに到達した。使ったのは銀ダイナモとスシコラ。ダイナモ、横に拡散するんだけど細い通路が多いホッケではとにかく弱いので、スシコラ使っていた。
B帯の辛さ
B帯が一番抜けるのきつい、というのは良く聞く話なんだけど、自分もそう感じた。たぶん、A帯はそこまで酷い地雷がいないので自分のウデマエが適切に反映されるんだけど、B帯はそうじゃないからだと思う。B帯は自分が頑張ってもどうにもならない要素が強すぎたので、今いる人も諦めないで欲しい。
ガチ、自分はランクが落ちることに強いストレスを抱えていて、上達した、と確信したときだけやってて、結局A-30からS30 まで 32勝8敗、たった40戦で抜けれたので、満足感がある。ヤグラの対ブラスターだけは未だに対処ができないので避けた。
日頃ナワバリやプライベートマッチでS~S+のイカと戯れていたので、S+は撃ち負けるがSはトントンだったので、Sはいけると思っていた。まだS+の器ではないと思うので、またしばらくガチはいかずに練習することにする。
スプラローラー
最近はコラボじゃない方のローラーが強いんじゃないかと思ってる。コラボと違ってキューバンに飛距離UPつければ中〜遠距離で死なないのが良い。モンガラ序盤のポーク合戦にも強い。ダイオウイカがないのは確かにアレだけど、上位帯だとよっぽど虚をつかないとキル取れず追い払うことしかできないケースも増えてきた。ガチでのメガホンは弱くはない。
Dvorak2週間経過
変えた直後は何するにも本当に身動き取れなかったんだけど、結構マシになってきた。
キーボードの配列をDvorakにしてみた - mizchi's blog http://mizchi.hatenablog.com/entry/2015/09/22/211239 から二週間してからの報告。
現時点での入力速度
体感。
タイピング速度 80% タイポの多さ: 150%
まだ本調子というわけではない。
イジった設定
Google IMEでのローマ字入力の設定を次のように変更した。
ci: し -> き ce: せ -> け
要は日本語入力中はcをkだと思って入力しても問題ない設定。
タイポしやすいキー
f がきつい。使用頻度が高い割にストレッチが必要。よく隣のy(ただし右手・左手の担当は逆)と間違える。 「ひ hi」がやや打ちづらい。h が元の位置の1つ右に移動しているだけので、逆に混乱する。
全体的にqwertyの元の位置と近い場所にあると誤爆しやすい気がする。ただ全く同じ配置のmとaはほぼ間違えない。これはまだ体が qwertyを引きずってる証拠だと思う。
母音は o u が誤爆しやすい。
Dovrakで非効率に感じているところ
- 母音が多い左手側に日本語で使用頻度が高い y があるのはあまり嬉しくない
- w と v が隣りあってるのがややこしい
- 英語入力でも使用頻度が高いLが右手小指ストレッチで遠い(vimでも辛い)
体感
リハビリ(?)のつもりで多めにブログを書いていた。睡眠学習か何かわからないが、寝て起きるとタイポが減る感覚がある。
もうちょっと頑張れば元の入力速度を上回れそうな気がする。また報告します。
さよなら CoffeeScript
prototype.js が jQuery に置き換えられた時、開発者が気づいたのは、自分に本当に必要だったのはprototypeのメソッド拡張などではなく、クエリエンジンだったということ。
coffeescriptが当初、熱狂的に支持された背景はなんだっただろう。今思えば、それはアロー記法とクラス構文だったと思う。
javascriptの関数型への憧れ、prototypeベースの限界
javascript は断じて関数型言語ではないが、他の言語と同じぐらい関数型言語に憧れていたのも、また事実だろう。しかしビルトイン関数が高階関数を要求するデザインにしては function というキーワードはながすぎたし、その function が暗黙に作り出す this スコープの複雑な振る舞いも開発者の悩みの種だった。「あらゆる関数スコープで状態を持つことが"できすぎる"」という割れ窓だった。
ES5 で Array.prototype.map / Array.prototype.reduce が採用され、より関数型っぽく(正確に言えばRubyっぽく、なのだが)書けることになったが、それに対してESの文法はまだ冗長だった。
2011年ほどから2つの理由で JavaScript への要求が増大した。一つはHTML5と呼ばれる仕様群でブラウザのポテンシャルを上げていこうと言う動きに伴って、JSの記述量が増えつつあったこと。もう一つは Node.js でサーバーサイドスクリプティングを行なうためだ。さらに突き詰めるとGoogleChromeやFirefox、V8エンジンの存在がある。
コード量の肥大化はクライアントサイドMVCという発想を産み、prototypeベースの限界、というか需要の無さをJavaScriptに突きつけた。現実的に、現代の開発者が獲得しているGUI実装パターンは、クラスやコンポーネントベースだった。そう、やっとWebはGUIになった。
JSの肥大化とCoffeeScriptの登場
そのような背景でCoffeeScriptが登場したと記憶している。クラスとアロー記法とインデントブロック。== の排除などの JavaScript バッドパーツを踏ませない設計。Backboneに始まるJavaScriptMVCとともに、大規模開発での採用が増えていた。Rubyを髣髴とさせる設計は、元々Rubyユーザーが多かったNode.jsとも相性がよく、またRubyらしさが買われてRails標準になったりした。
CoffeeScriptの一番の成果は、現実の仕様が追いつかない部分はプリコンパイラで先取りしてもいいんだ、という雰囲気を作ったことだと思う。typescriptも6to5(現babel)もそういう雰囲気の中で生まれたものだと記憶している。
CoffeeScript の衰退
CoffeeScript が用いたクラス構文や継承ポリフィルはほぼそのままES6の仕様として採用された(正確にはstatic継承はオミットされた)。() =>
のアロー関数もだ。これによって将来的にはピュアな javascript でも将来的にはクラス構文やアロー関数が使えることが約束されている。
これは coffeescript にとっては 勝利であると言えるかもしれない。coffeeで書いたコードが将来的にもjsでそのまま継承できるようになるからだ。
僕はこのまま coffeescript は先進的な仕様を実装しESのオピニオンリーダーの一人になると思っていたのだけど、現実は違った。ユーザー数が多くなった CoffeeScript は保守的になり、ES5の互換性志向が強くなった。いや、具体的にそう明言されたわけではないのだが、リポジトリを眺める限り、僕はそのように感じた。また開発者のjashkenasも理由がわからないが、ある時点からやる気を失ってるように見えた。Issueは消化されなくなり、PRのマージ速度も目に見えて鈍化した。もともとコードが綺麗ではなかったのも理由の1つだとは思う。
言語からイノベーションが失われた。これが僕がCoffeeScriptを見限る理由となった。
「その場に居続けるには全力で走り続けなければならない」
最近 typescriptやbabel でasync/await を試していたのだけど、これは今のJavaScriptを大きく変化させるだろうなあ、という実感がある。ただ、coffeescript でそれが使えるようになるのはいつになるだろう、と考えてげんなりした。CoffeeScript に付き合っていると変化に追いつけないだろうという予感がある。とくにES7は。
Typed CoffeeScript の副目的
そういうものを作っていた時期もあるのだけど、その目的はTypeScriptの猛追で雲行きが怪しくなり始めたCoffeeScriptを殺さないため、外部から何かしらのイノベーションを起こしたかった、というのがあった。結果は、一人でやるにはまったく時間が足りず、とある設計変更を見積もった結果、まったく時間を捻出することが不可能で、放置されることになった。僕の型システムに対する勉強不足、実力不足もあるが、この手のことをやるにはパトロンがいるという認識に至った。次に何かこの手のものを作る必要があれば、フルタイムの時間を捻出するために、そうしようと思っている。
(今回の記事とは関係ないけど、宮下さんのリクルートテクノロジーズ Advanced Technology Lab の技術顧問就任とか、OSS支援でそういう選択肢を提供してくれるかもしれない会社が増えるのはいいことなんだろうな、と思っている http://mizzy.org/blog/2015/10/01/1/ )
なぜこの記事を書いたか
僕は coffeescript を推進していたし、それで技評で本も書いたし、国内に限ればGithubのCoffeeScriptプロジェクトのスター獲得数も一位だし、本家にコミットはしてなかったものの、勝手に責任を感じている。だからこういう表明も必要だと感じた。自意識過剰かもしれないが。
好きな言語・技術が腐っていくのを見るのは、これが最後ではないだろう。でもいつだって心構えが必要なんだと思う。全ての技術は生まれながらに腐っていくといってもいい。なるべくそうならないものを選ぶのも技術者としてのスキルの1つだろう。
書き捨てのスクリプトやgulpfileはまだ多分もcoffeeで書くだろうが、今後新しく書くものはbabel か typescript を必要に応じて選んでいくことになると思う。
イカとしての今
スプラトゥーンくっそ面白かったので話をさせてくれ!!!(ブキ寸評+マップ寸評+その他) - mizchi's blog http://mizchi.hatenablog.com/entry/2015/06/01/195123 を書いてからだいぶたったので、今の気持ち。
フレンドをイカで叩くの楽しくてナワバリばかりでやってた。ランク40。 メインの武器はダイナモ金銀、スプラシューターコラボ、バレルスピナーあたり。
みずちっていう他のイカに遭遇したことないので、いたら僕です。
ガチ
昨日は気分が良かったので久しぶりにガチいったんだけど、A-30から18勝3敗ですんなりA+に昇格した。A相手の試合ならキルレート3以上維持していたのでSはいけそう。S+はわからん。
まだやってるフレンドだいたいS以上なので、彼らとプライベートマッチやナワバリで戯れてた成果が出たんだと思う。
S解禁のアプデ前にB帯にいた時間が長くて、ほんと辛かったんだけど、それが理由でナワバリやってなかったんだけど、A帯は抜けられそうなので、やっと気分が楽になってきた。
ジャイロとエイム
ランク25にしてジャイロをオンにした。このゲーム多分ジャイロオフだとエイムに限界がある。ジャイロになれたのがランク35あたり。そこからランクあがるようになった。
ジャイロなれてからの世界は以前と別物で新鮮。自分が飽きてない理由はジャイロオフという縛りプレーしてたからだと思う。
とはいえもともとFPSとかのシューターやらない人間なので、ガバエイムなのでS+相手だと対面での勝率が良くない。その為のダイナモだが。
ダイナモローラー・ダイナモローラーテスラ
塗りが強いのでスパセン持ちの銀ダイナモがお気に入り。とはいえスプリンクラーは自分にはちょっと使いづらい。その点金ダイナモはスプラッシュボム持ちで悪くないんだが、実際はダイナモの射程が十分に長くて山なりに濡れてボムの射程がやや被ってるし、トルネードはそんなに強くないと思う。というわけで銀ダイナモ。
ダイナモは隙が多くて難しいというイカも多いんだけど、多分考え方が違って、これは常に跳ねながら振り続ける連打寄りの武器だと思う。そのためにある程度のメイン効率UPは必須。転がすタイミングは殆ど無いが、ゼロ距離インファイトで空振った時にそのまま足元を狩りにいくのに使う。相手がバッタシューターだと効かない。
ダイナモの強みは一見弱点にも見える振り始めてからの入力猶予にあって、常に振り続けることで奇襲に対応できる点だと思う。敵が見えてから振るんじゃなくて、振ってから考えるイメージ。
自分のギアは、メイン効率19・安全靴・インク効率10・防御9・ヒト速度3(ヒト速度はいらない)
自分の足元塗りにくいので安全靴は重宝する。
スプラシューターコラボ(と同性能のオクタシューターレプリカ)
今の環境のトップメタ。キューバン・スーパーショットで遠中近隙がない。勝ちたいなら対策を覚える意味でもまずこいつを使いこなせるようになりたい。 トップメタだけあってこいつを確定3から4にずらされる防御UP20がメタゲームの一つの基準になってる。 立ち歩き性能が高いのでヒト速ビルドが多い。自分はアンチメタ対策の攻撃UP積まずにサブ飛距離とサブ効率積んで多めにキューバン遠投してる。
自分はヒト速19・サブ効率16・サブ飛距離10・攻撃UP3な感じ。
バレルスピナー
遠距離からの塗り性能はピカイチ。そして何よりシールドが強い。後方支援向き。シールドは奇襲されたら嫌な方角を守る5人目の仲間。 こいつを使う場合も強みを活かすためにメイン効率積みたい。あと意外と撃ってる時の立ち歩きが速いのでヒト速もアリ。
シールド持ちのトップメタといば確定2・シールド・ダイオウイカの96ガロンデコなのだが、塗り性能が低くエイムがシビアで自分は使いこなせていない。練習中。
対チャージャー
上手いチャージャーいると完全にゲームを支配される。 とにかくマップ覚えて射線通らないところを辿って前線を押し上げるて退かせるしかない。本当に上手いチャージャーは逃げこむ先まで把握してクイックボムダンスはじめるが…。とはいえ本当に上手いチャージャーは数が少ない。
フレンドに1人異常なチャージャーいて、一瞬でも射線通ったら死ぬというステルスアクションゲームになる。圧倒的成長機会に感謝🙏(辛い)
ローラーについての現在の所見
最初はローラーばかり使っていたが、自分は限界を感じた。強いことは強いが味方への依存が激しい。押し込まれた時一人で状況を打開できないことが多かった。塗りが十分なときの前線維持能力は高いんだが…。
チーム戦ならともかく現在のマッチングの仕様なら一人で打開できないとダメ。
フェスについて
報酬でつるのはいいんだが、やることつまらなさすぎるのでどうにかして任天堂。
フレンドリスト
100じゃ足りない。手軽に再申請できるイカから外してる。スマン。
以上
やり込むにつれ別の景色が見えてくる。自分はトップ層になるのは諦めたが、まだまだ飽きそうにない。
この記事は Dovrak の練習の一貫で書いた。
キーボードの配列をDvorakにしてみた
昔からずっとqwertyの非効率さは感じていて、前々からやろうと思っていたのだけど、仕事中にやるとおそらく仕事がまったくすすまなくなり、ストレスでヤバくなるということはわかっていたので、この連休中に覚えてしまおうと思った。
今は二日目
なぜ Dvorak か
英文入力において、QWERTY配列と比べて上段と下段の使用頻度が低くなるように設計されている。 そのためQWERTY配列に比べて、英文入力における指の移動距離を短くすることができる。この特徴から、腱鞘炎などの予防に効果があるとされる。 母音は左手に集中しており、英文の入力において母音に連接しやすく高頻度で使う子音ほど、右手に集中している。 このために右、左、右、左とリズミカルに打鍵できる確率が高まり、QWERTY配列に比べて高速かつ効率的な入力が可能であるとされる。キーボードをタイプする速さの世界記録は、この配列を利用する者によって樹立された。
Dvorak配列 - Wikipedia https://ja.wikipedia.org/wiki/Dvorak%E9%85%8D%E5%88%97
タイピングは僕の仕事中の作業のかなりをしめていて、改善の余地があるなら投資するだけの価値があるだろう、という予想。
あと僕は家系的なアレでかなり指が短いので、負担少しでも減らしたかったというのもある。
やったこと
いわゆる dvorak-j ではなく dvorak。日本語に関しては間違いなく dvorak-j が良さそうだけど、プログラマなんでどっちで行くか思案中。単にCをか行に割り当てればいい気もしている。
手元のキーボードはもともとHHKB無刻印でブラインドタッチなので問題なし。無刻印なのはいずれ dvorak にしようと昔からねらっていたため。
誘惑はあるがまだ一度もQwertyにもどしていない
今の習得具合
- 配列は暗記はすぐ終わった
- 速度は元の3割程度
大変だろうと予測していた暗記は実際一時間ぐらいですぐ終わって、問題は体に染み付いた qwerty のニオイとの戦い。
あらゆる身体性がリセットされるので時間をかけて復元するしかない。
感想
左手の移動がかなり減る。合理的なのは肌で感じる。 日本語と英語でかなり使用感が異なる。日本語の方が改善の幅が大きい気がする。
入力速度が落ちたことで思考に枷がはまっているような感覚がある。これがかなりのストレス。
困ったこと
- 文字入力はともかく、アプリのキーバインドは体で覚えていて、誤爆が頻発する
- コード書くのが億劫になり、作業が進まない
- ストレスを感じるとイカに逃げてしまってランク40でオクタシューターをゲット
- vim/vimperator/atomのvim-mode が辛い
いろんなアプリをVim風にしていたのだけど、これがいまいち使い勝手が悪い
Dvorak 気になる人は
連休中に苦しみましょう