イカ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 気になる人は

連休中に苦しみましょう

スターエンジニアはキラーアプリを生み出すのか？

日本Web技術界隈著名人の残念さ具合 - thinkchangの日々日誌 は内容自体はどうしようもないのだけど、テーマ自体は自分も日頃悩んでいたものなので書き出してみる。あ、そういえば行方不明のmalaさんは一昨日のハッカソンで振り向いたらいたんで大丈夫です。

技術的イノベーションによって可能になったサービスはたくさんあって、たとえばデータベースを使った動的なウェブサービス、2000年前ごろにPerl CGIが現実的な速度で動くようになってから増えた。たとえばYouTube、回線速度とストレージ価格が壁で2004年ぐらいまで難しかった。低価格のウェブカムの普及という背景もある。Skypeなどもそうだろう。IoTは現在進行形。

それとは別に、ありあわせの技術の組み合わせで高い付加価値を生むことができる。横井軍平はそれを「枯れた技術の水平思考」と呼んだ。

「枯れた技術」とは"最先端ではないが、すでに広く使われて、ノウハウも固まり不具合も出し尽くして安定して使える技術"のこと。「水平思考」とは"今まで無かった使い道を考える"ことである。 枯れた技術の水平思考とは (カレタギジュツノスイヘイシコウとは) [単語記事] - ニコニコ大百科 http://dic.nicovideo.jp/a/%E6%9E%AF%E3%82%8C%E3%81%9F%E6%8A%80%E8%A1%93%E3%81%AE%E6%B0%B4%E5%B9%B3%E6%80%9D%E8%80%83

ニコニコ動画なんかがわかりやすい例だろう。Youtubeにコメントのオーバーレイ。あれも最初はインフラで躊躇してYouTubeをソースとして読み込んだ挙句にアクセス拒否されたが、そこで自前インフラを組む決断をしたのが凄い。増井さんのGyazoとかもそういう類だと思っていて、単純な画像アップロードと十分セキュアなuuidのパーマリンク。

組み合わせ、思いつくこと自体は簡単で、ウケるかどうかは未知数。だいたい、俺もできる、みたいな錯覚が生まれやすい。クソベンチャーとかだいたい俺のアイデアは革新的だ！最高なんだ！とかファウンダが思い込んでやってみるも市場に需要がなかったりする。今だと単にネット市場が未発達な市場に上手くプロデュースできると売れるみたいな状況はあって、比較的簡単だとは思うが、それでもその業界を知り尽くしてないと厳しい。

そんな状況がありつつも、現在では当たり前のことを当たり前にやるのは、実は結構難しい。難しさの解決には人件費がかかる。プログラマサイドの都合から言うと、昔と比べて「当たり前」がはるかに高い水準にあって、学ぶべきことの量がインフレしている。

その結果一人一人の専門性が高くならざるを得なくて、その結果複数人で働く協調スキルが必須になる。スクラムだgitだコードレビューだなんだかんだ。そんでいろんな役職の名前が増える。最近だとプロジェクトマネージャーから品質管理のためのプロダクトマネージャーをちゃんと区別しようという話が盛り上がったりした。それは顧客にとって間接的なテーマなので、何やってるのかわからなくなる。最初にあげた記事のような難癖つける人が増える。

革新的な技術を使ったプロダクトは、プロダクトがヒットするか自体がそんなに分がよくないレートだが、そこに「技術的な挑戦」が絡むと管理すべき変数が増えて制御ができなくなる。マネージ層はそこを嫌がる。

当たり前のことを当たり前に達成できるチームがあって、その上でやっと技術的な挑戦とその達成確率という変数をコントロールできる段階になる。

で、表題の件だけど、

と思ってる。

たぶん、業界が未発達なときは少人数で個人の範囲が大きく役割があやふやな時代があって、その時代は所謂スターが発見されやすい。ゲーム業界だと故岩田社長や中村光一がそれに当たるだろう。最初にあげた記事であげられたリストに照らすと2003~5年ぐらいのウェブはそういうスターが生まれやすかった時代だと思う。誰もやってない、その人しかできないことがたくさんあった。まあ件の記事の場合は単に観測範囲が初期のライブドア・はてな関係者って気もするが…。

現在では、PaaSによるインフラコスト削減やUnity等の開発環境のイノベーションがいくらかあって、少人数チームに回帰できる今こそスターが出るような時代な気がしなくもない。ゲーム業界はUnityとかその辺があってIndieシーンが盛り上がってる、という認識。MinecraftのNotchというロールモデルもある。対してWebは、その働き方をするはずのPaaSはそれ自体が学習コストとランニングコストかかるのでまだまだ破壊的なイノベーションにたどり着いてない気がしている。AWSそれ自体が一大ジャンルすぎてめんどい。フロントエンド的にはMBaaSがあと一歩進化した先にあると思っていて、Googleに買収されたFirebaseとか? まだわからない。

とりあえずWebRTC/WebSocket/HTTP2あたりのリアルタイムウェブとIoTはこれからいくつかの花火が上がるだろうが、着地点に対してビジョンをもてる人がほとんどいないので、金脈が掘り当てられるまでしばらく試行錯誤の時代だと思う。VRについては未だによくわからん。Oculusが一台3000円になったら今すぐにでも時代くるのでは。

あと、このツイートでは大企業が、って言ってるけど技術優位をもたないといけないのはベンチャーも一緒で、一瞬で実装が見破られて真似されるものは今の速度感においては致命的だったりする。後発に追いつかれないために強固なコミュニティを作ったり、邪悪な囲い込みを実施したりする。BtoCだと反感を買うのでそこまででもないが、BtoBだとえげつない話がたくさんある。

結局エンジニアからしてもヒットするかどうかは全ては確率の話。品質を担保することでプロダクトの持つポテンシャルを殺さないのが役目であり、そもそもの市場の有無について責任を要求するのは、それだけの権限を持ってない場合無理筋だと思う。(企画起こしたり企画に携わる場合はその限りじゃないよ)

そして現在では技術が極まった人はユーザーから観測しづらい基盤技術にいってしまったり、企画に行った人は他のエンジニアから観測されなくなったりで、分断が起こる。これも一つの35歳限界説だと思う。

これも一つのポジショントーク

とはいえやっぱこの記事もポジショントークで、自分は他人ができることはあんまりできないけど、その分他の人が興味を持たなかった箇所に注力したタイプの人間なんで、僕がいたら他者にできないことができますよ、どうですか、というような働き方、転職の仕方になってる。

Kobito for Windows とか国内でEletronを使った前例がない中で僕個人のスキルにだいぶ依存して完成したのがあり、だいぶ他社に真似しづらいのだが、会社としてもスケールしにくいというデメリットがある。なので、自分のスキルのスケールしなさを克服するために情報発信を多く心がけていて、自分自身のスキルの特質性が薄れるかわりに共通認識ができて結果として働きやすくなる、と思っている。

僕は国内市場というガラパゴスをハックしているだけで、日本のエンジニアちょろいとも思ってるが、だいぶリスキーな技術選択をしているので、その分の見返りは欲しい。

最近の若手は一発当てたくて消耗している

まあなんだかんだで、やっぱ働くからには、ベンチャーにいるからには一発当てたいという気持ちはある。ストックオプション当てて休職し、一年好きなコード書いて、その次は自力で一発当てる。そういう目標がある。たぶん皆多かれ少なかれそう思ってるはずで、また外野からもそれが求められている。趣味時間の勉強、趣味時間の個人プロダクト制作を暗に要求されている気がしていて、それが界隈を疲弊させている感覚もある。

あと3年、30歳までにどうにか。ダメだったら情報発信した分の信用を使って技術評価してくれる給与高くて勤務条件いい会社行くわ。

Reactのprops/stateとFluxのStore

基本的に、ReactのpropsはImmutable, stateはmutableという扱いです。

特に理由もなくstateを使うのを許したくない

ネットワークリクエストとかね。Flux, 割とStoreとView以外のコンポーネント曖昧で、View(React)がStoreに逆走しなければ何やってもいい気がする。