オートチェス入門

今自分の中で熱いゲーム、それが Dota Autochess。この熱はスプラトゥーン以来。

dota auto chess が張り切った麻雀みたいで面白い - mizchi's blog

僕自身の最高レートはナイト 8 で、まったく高レートプレーヤーではありませんが、GW を溶かして最初に学ぶべきことは一通り覚えたつもりです。日本語の記事が少なく、初心者がなにを知るべきか網羅的な資料がなかったので、自分で書くことにしました。

最初に: 負けても気にしない!

このゲームは勝敗によってレートがついていますが、現在の野良マッチではレートが考慮されていません。一人やフレンドと一緒に潜るだけなら、どんなに下がっても大丈夫です。

ビジョップ以上の高レートになるとレート専用部屋を立ててプレーする文化がありますが、最初は存在を忘れて大丈夫です。

このゲームでまず大事なことは、自分が取れる選択肢の多さです。その選択肢ごとに強さのカーブがあります。どんなに言葉で説明されても、そのカーブはやってみないと身につきません。

最初はやったことない戦略をどんどん採用してみて、レートを溶かしてでも肌感覚を身に着けましょう。

まず覚えていくこと

このゲームは、お金を貯めながら、他プレーヤーに HP を削られない程度の強さを維持して、お金に利子を付けて稼いで優位に立つのが基本戦略です。$10 ごとに $1 の利子がつき、利子がつくのは最大 $50 までです。これはマネー戦略と呼ばれたりします。

勝っているときは、連勝ボーナスを稼ぐ連勝戦略もあります。これを採用できるのはゴブリンのような序盤強いビルドに成功したか、他の理由で強運だった 1 位~2 位なので、基本はマネー戦略でいいと思います。結局は連勝戦略でも、勝てる程度に金を残して利子を取りに行くのは一緒です。

マネー戦略では、序盤に負けるのは気にしなくていいです。序盤に負けるとしても、ダメージはたかだか 4~6 点です。ユニットの数が増える終盤で負けると、1 ラウンドに 20 点飛んでいくことはザラにあります。

序盤でカードをドローしても高いユニットはでないので、あまり得ではないです。序盤で $2 払って手札を引き直すのは、Lv2 がまったく作れず負けていて、4ペア以上揃ってるときだけにしたほうがいいです。

Alt を押している間、自キャラの経験値が見えます。これは 1 ラウンドごとに 1 点ずつ増えていきます。これが 4 の倍数の時、5 金で 4 経験値を買うチャンスです。Lv が増えればユニットの配置数が増え、より強いカードを引く可能性が高くなります。

とはいえ、必ず $50 を抱えておかないといけない、というわけでもありません。他のプレーヤーも常に強くなっていきます。中盤で大敗すると、後半とれる戦略の数に響いてきます。レベル差がついてユニットの数で負けたので30金払って Lv9にしたけど、その後カードが引けなかった、ということがよく起きます。

合成しなければユニットの売値と買値は同じです。なので利子が減らない範囲でユニットを買い占め、次のターンで利子が付くラインまで売り払う、という操作で細かく期待値を上げていくのが重要になります。とくに序盤の Lv2 の数は、これで差が出てきます。勝った瞬間に 1 金入るので、それを即座に使うのも大事です。

シナジーについて

最初に留意する点として、シナジーが発生する条件は「数」ではなく「種類」です。違う Lv の同じユニットを二体並べても 1 とカウントされます。

シナジーについて、大雑把にこういうイメージで覚えるといいと思います。

  • 種類が多い役は 3 の倍数で起動します。クラスが多いです。(ウォーリア/エルフ/ハンターなど)
  • 種類が少なめの役は 2 の倍数で起動します。種族が多いです。(オーク/エレメンタル/ヒューマンなど)
  • 他、特殊なもの。(デーモン 1, デーモンハンター 2、神)

最近ナイト 2/4/6 がナイト 3/6 に変更されたりしたので、種族だったら、クラスだったら、という区分けはちょっと曖昧です。

自キャラ(マウント)にフォーカスがあたってるとき、今のシナジー数が発動できるので、2/3 のものを確認するといいと思います。

初心者が覚えるべきは、ウォリアー 6(防御 UP)とゴブリン 3(ランダムなユニットに自動回復)です。これは作りやすく、単純に強力です。

最初に知るべきこと: デーモンについて

デーモン種族は強く設定されている代わりに、2 種以上並べると弱体化します。これはデーモン 1(デーモンにトゥルーダメージ追加)という役があるからです。なのでどんなビルドでも、迷ったらとりあえずデーモンを一体だけ運用しましょう。

シナジーを無視して採用されるデーモンは後に崩すことが多いので、アイテムを一時的に放り込んでおくのに便利です。売ったユニットのアイテムは回収できます。

特殊なシナジーとして、相手のデーモンハンターは対面のデーモンとして数えられるので、相手のデーモンシナジーを打ち消します。

最初に知るべきこと: アイテムについて

アイテムは合成して強く出来ます。が、最初はそれを考えている余裕はないでしょう。防御 UP は前衛に、攻撃力 UP は高いランクのユニットに、マナ回復はスキルが強いキャラに付ける、とおぼえておけば OK です。

シナジーを無視して採用したユニット、とくにデーモン種は後半切ることが多いので、回収を前提にアイテムを突っ込んでおくことが多いです。アイテムを持ったまま活用できないのは、相対的には損なので。

注意すべきは「呪われた吸血マスク」です。これを装備したユニットは、通常攻撃に吸血効果がつく代わりに、スキルが発動できなくなります。便利な棒と吸血マスクの合成なので、これを装備したユニットに装備を追加する際は確認しましょう。ちなみに呪われた吸血マスクを一番活用できるのは、パッシブスキルで通常攻撃が加速していくトロルの戦将です。

配置について

基本は前衛は前、遠隔は後ろ、これだけ覚えてればなんとかなります。が、いくつか特定の戦略に対する戦略が必要になります。

アサシンは自身から一番遠いユニット、つまりは相手の後衛に飛んできます。アサシンを採用してるプレーヤーがいる場合、最後列や右隅、左隅にユニットを寄せましょう。

この逆のパターンで、メイジのスキルはほとんど範囲攻撃です。この場合固まってると全部刺さってしまう可能性があるので、ユニットを散らして配置しましょう。

配置が一番重要なのは最終盤で、1 位と 2 位がお互いをメタりあって配置を頻繁に変えるときです。範囲スタンを持つタイドハンター、自身を見ているユニットを石化させるメデューサ、範囲で割合ダメージの謎のエレメンタルがシナジー無視で採用されたりします。


以降、ビルドごとのガイドです。興味あるものを拾い食いする程度でいいです。

初心者にはとりあえずどんなときでも採用可能なウォリアー軸をおすすめします。

ウォリアー軸

ウォリアーは種類が多く、事故が起きにくいクラスです。また、ウォリアーの中でもシナジーがあります。

  • ☆1 アックス、☆2 ジャガノでオーク 2(オークの最大 HP+250)
  • ☆1 タスカー、☆3 ライカンでビースト 2(全員の攻撃力+10%)

序盤でタスカー、ライカンでビーストが発動したら、ビーストを集めるチャンスです。結果的にビーストが多いドルイドが見えてきます。

岩のエレメンタルは、ウォリアーというよりエレメンタル 2(エレメンタルを攻撃したユニットが確率で石化)を経由して、別のビルドに向かいやすいユニットです。岩のエレメンタルと単品で強い雷エレメントと組み合わせて、あわよくばメイジへ。

ラウンドのスタッツを見ればわかりますが、ウォリアーは序盤に壁を揃いやすいかわりに火力が出しにくいです。メイジのような後衛を揃えるか、☆3 クンカ ☆4 トロルの戦将、☆4 ドゥームデーモンの Lv2 が必要です。トロルの戦将が火力出すにはもう一体トロルが必要です。(無理にトロル 4 をやる必要はないです)

ゴブリン軸

ゴブリンの強さは序盤の引きやすさと、☆1 ゴブリンの賞金稼ぎと ☆2 ティンバーソーの強さ、そしてほぼ決め打ちでメカの自動回復シナジーが付くところです。

☆1 ゴブリンの賞金稼ぎ、☆2 ティンバーソーはわかりやすく強く、☆1 クロックワークと ☆1 ティンカーは並ですが、ゴブリン 3 を揃えた時点でメカ 2(メカ属性が自動回復)が確実に発動します。

しかし、序盤で圧倒的なゴブリンも、中盤、とくに他のシナジーが猛威を振るい出す Lv6(ラウンド 17 あたり)から、厳しい展開が多くなります。☆4 ゴブリン錬金術師は引きづらい上に弱く、☆5 はゴブリンの地雷作業員に至っては Lv があがりきる終盤までドロープールに出現しません。ついでにメカ 4 のシナジーを出すには、☆4 ジャイロマンサーも必要です。

ゴブリン 6 メカ 4 が完成した際の強さは圧巻ですが、そのために一時的に負債となるゴブリンを抱えたまま中盤を乗り切るプレースキルが必要です。序盤にのみゴブリンを採用し、その後他のビルドに切り替えるプレーヤーも多いです。

ドルイド

序盤でエンチャントレスとフリオンが重なったらドルイドをやるチャンスです。ドルイドは進化しやすい代わりに、戦闘には貢献しないシナジーなので、育ちきったら最終的にドルイドを切ることが前提です。

ドルイドは ☆2 フリオンと ☆3 トレントでエルフ 2, ☆1 エンチャントレスと ☆3 ローンドルイドでビースト 2 がついてきます。なので、切り替え先として ビーストかエルフに向かうことが多いです。個人的な印象では、エルフは決め手に欠けるので、エルフ 3 ビースト 2 を繋ぎで発動させつつ、ビースト 4 を目指します。

ドルイドで気をつける点として、☆1 エンチャントレスと ☆2 フリオン が本当に弱いです。エンチャントレス Lv3 はビースト 4 のため残る可能性はありますが、フリオン Lv3 はエルフ軸でも居場所がないかもしれません。

自分がドルイドで多かった敗因が、☆4 ローンドルイドが一体でも出れば Lv3 が出せるのに、というシーンでガチャを回して事故って負けることが多かったです。ローンドルイドが出なければ中盤のドルイド Lv3 の Lv による強さは発揮できないので、諦めてドルイド軸を切ることも大事です。

トロル軸

☆1 トロルの蝙蝠騎士が弱く足を引っ張るのですが、最近になって ☆3 Dazzle という強力な駒が追加されたため、どんな構成でも中盤を腐らせることなく現実的にトロルシナジーを発動させることが可能になりました。

トロル 4 (全員の攻撃速度が+35%) が非常に強力です。マナ はダメージを与えたときに回復するので、単純な攻撃力 UP ではなくスキルが回る速度も速くなります。

トロル 4 はそれ自体では前衛が足りません。なので自然とウォリアーかナイトと組み合わせることになると思います。影のデーモンが育っていたらウォーロックもあるかもしれませんが、ウォーロックで前衛を機能させるのは難しいです。

トロルの蝙蝠騎士を採用するのはトロル 4 ナイト 3 のときだけです。

ナイト軸

安価なユニットがいないウォーリアという感じです。序盤の火力は ☆2 ルナ と ☆2 デーモンナイトに依存しますが、終盤では決め手に欠けるので、メイジを採用するか、☆4 ドラゴンナイトの変身能力を活かすためにドラゴン 3(ドラゴンが開始時に MP 満タン) を採用する必要があります。ドラゴンナイトで最終盤を勝ち切るにはドラゴンナイト Lv2 が最低二体ほしいところです。

最近のアップデートでナイト 2/4/6 がナイト 3/6 になり、弱くなった気がしてます。

メイジ軸

最終的には一番強いと言われています。ただ、メイジは安いユニットが少ないので、序盤で考慮する必要はないです。

メイジを目指すかどうかのキーは、☆1 オーガマギが Lv2 になったか、もしくは ☆3 雷のエレメンタルが Lv2 になることです。雷のエレメンタルは単品で強いユニットなので、他のビルドでも後衛が少ない場合に雑に採用されます。

☆4 光の老魔導士はメイジが勝てるかどうかを決定づけるカードです。正面方向への AOE なので、最下段の画面の隅に配置して、斜めに打ちます。☆5 ゼウスが Lv2 になったら、おそらくメイジが負けることはないでしょう。

注意点として、☆2 リーライは Lv2 になったとしても序盤で出さないでください。リーライのパッシブスキルは他のユニットの MP の自動回復です。これはスキルの強いメイジが完成してはじめて機能するスキルです。

序盤で弱いという同じような理由で、☆2 フェアリドラゴンは単品で弱く、仮に Lv2 になってもメイジ以外の序盤では採用されません。この例外としてはドラゴン 3 です。

アサシン軸

(正直自分が詳しくない)

前衛にはならないので、他の前衛と組み合わせる必要があります。アサシンは自分から一番遠いユニットにジャンプする、という特性があり、配置が重要で、ゲーム理解が必要です。

☆4 テンプラアサシンは単品で強いです。エルフ 3 のために採用されることがあります。

前のシーズンでは一番強かったのですが、今は最初のジャンプが遅れて発動するようになり、ちょっと弱くなっています。

ハンター軸

ハンター軸では前衛をどう揃えるかが難しく、なのでハンターで近接である ☆2 ビーストマスターの役割が大きいです。こいつは単品で強いです。なので自分は ☆2 ビーストマスターが重なってはじめてハンターを候補にいれます。

中盤までウォリアー/ナイトなどを混ぜつつ前衛を確保して、最終盤で ☆4 メデューサと ☆5 タイドハンターが揃えばハンター 6 の完成です。メデューサとタイドハンターは、他のビルドでもピンで採用される、このゲーム中随一の強さです。ただ、この二体とも範囲スタンのスキルを持っていて、配置が重要なのでゲーム理解が必要です。

注意点として、☆2 ミラーナがたぶん ☆2 の中で、ドルイドのお荷物であるフリオンと争うぐらいの弱さです。ハンター 6 をやるとき以外では採用されません。

ウォーロック

不死のリッチがゲームから削除されたため、これは 2019 年 5 月現在、ゲームプランの軸としては機能していません。

トロル 4 やビースト 4 を目指すときに、影のデーモンが育っていた場合のみ、ウォーロック 3 を付けます。あるいは他のデーモンを採用していた場合は ☆5 謎のエレメンタルで付けることがあるかもしれません。

アンデット

ウォーロックと同様、不死のリッチがゲームから削除されたため、軸として機能していません。

軸としては機能しないものの、アンデット 2(敵全体のアーマー低下) というシナジーは気軽に付けられる上に火力+20%相当と強いので、ナイト軸やハンター軸のときに不死の射手を軸にして一時的に採用されることがあります。不死の射手自身は弱いので、アンデット 2 だけなら、終盤で ☆3 不死のネクロマンサーや、☆5 不死の悪霊使いと入れ替えます。

神メイジ

神はそれ以外の種族シナジーが発動していない時、スキルのクールダウンが半減されます。

このマナ回復を一番生かせるのはメイジです。ただし、メイジはヒューマンが多く、シナジーがあるマナ回復パッシブを持つリーライ以外は採用し辛いです。前衛にはスキルが強い ☆2 剣士ジャガノなどが採用されます。

ユニットが増えるほど、シナジーを避けるために変則的な構成になります。なので序盤揃わないメイジを無理やり機能させるのに使われ、その後切られることが多いです。

神メイジの真価は、☆1 マルスと ☆5 ゼウスが揃って神 2 が発動したときです。ここに到達できれば負けることはないでしょう。


おまけ r7kamura が作ってたアイテム合成表

https://cdn.discordapp.com/attachments/574080780259688453/574840388133584916/unknown.png

dota auto chess が張り切った麻雀みたいで面白い

dota auto chess は dota2 の MOD 。Steam で無料の Dota2 をダウンロードして、その MOD として遊ぶ。なので無料で遊べる。Dota2 のシステムを部分的に流用しているが、基本的には独立したゲームであるため Dota2 を知っている必要はない。

Steam:Dota 2

https://steamuserimages-a.akamaihd.net/ugc/802114790893958279/01726D00014FB56457A05FB4A1039CD5896E794D/

元々 autochess は中国産のMODだが 3 月に日本語にもローカライズされ、日本人にもとっつきやすくなった。

このゲームを簡単に説明するならば、麻雀のようにユニットの役を揃えて、ユニットをチェス盤に配置して、戦闘は自動で行われるのを観戦する、といったもの。

ルール

8 人同時プレイ。毎ラウンド自分以外の誰かとランダムに勝負し、生き残ったユニットの戦力差で最大 HP が減る。HP がゼロになれば終了。負けたらさっさと部屋から抜けて、次の勝負にいってもいい。

ラウンドごとに収入があり、ランダムに選ばれた 5 体からユニットを買う。それをチェス盤に配置する。

戦場となるチェス盤は 8x8 で、手前の 4 ラインに自分のユニットを配置できる。大雑把には前衛後衛で管理するが、範囲攻撃を当てたり避けたりするのに工夫する必要がある。

同じユニットは 3 つ揃えると進化する。最大で Lv3 まで上がる(計 9 体)。ユニットには種族と職業が設定されている。例えば「オーク/ウォーリア」の「アックス」。

異なる種類のユニットを複数チェス盤に配置すると役が付くことがある。「オーク 2」という役はオーク種族の HP が増え、「ウォーリア 3」という役は全員の防御力が増える。

要は、強いユニットを高い Lv で揃えて、強いシナジーを出して勝つ、というゲーム。終盤は配置が重要になってくる。

何が面白いか

基本的には麻雀のようなプレー感覚で、他のプレーヤが集めてるユニットをみて、できるだけ集めるものが被らないように、そして上位をメタるような戦略を選べると強い。(ユニットのプールは全員で共通)

とはいえ最初にそれをやるのは無理なので、とにかく効率よく役を作るのを覚える。慣れてくると、シナジーを出す経路が無限に見えてくる。余裕が持てるようになると、他人の手牌を観察する余裕が出てくる、という感じ。そこに自分の成長を感じる。

有名所の戦略だと、「ウォーリア 6」「ゴブリン 6」「ハンター 6」「メイジ 6」「ナイト 6 ドラゴン 3」「神メイジ」がある。初心者はウォーリア軸を覚えると安定すると思う。

http://dota-auto-chess.sakura.ne.jp

自分の戦略

ここからちょっとやった人向けの話。まだ自分がナイト 7程度なので、なにか語れるほど強くはないのだが、参考までに書いておく。(本当はビジョップに上がってからブログを書きたかったが、GW が終わってしまうので…)

基本はウォーリア/ビースト/ウォーロック

  • ウォーリア => ビースト 4(ドルイド経由でローンドルイド Lv3 を作る)
  • ウォーリア => トロル 4(トロルの戦将をエースに)
  • ウォーリア => ウォーロック 3 => アンデット 2(4)

キーとなるカード

序盤引きやすいウォーリア軸なので事故が少ない。仮に事故ったときもドルイドで最下位を回避しやすい。派生のバリエーションが多いので、ドローに合わせて柔軟に戦略を変更できる。タスカー・ライカン・ベノマンサー・ネクロで、ウォーリア 3 ウォーロック 3 ビースト 4 アンデット 2 みたいなルートもある。

初手は可能な限りタスカーだが、正直ウォーリアならなんでもいい。どのルートでもドゥームデーモンとトロルの戦将は強いので、優先的に集める。影のデーモンが揃いそうなときはベノマンサーやトロルの医者を集めて、早期のウォーロック 3 を意識する。

序盤中盤終盤、隙がない半面、完成時にぶっちぎりの火力を出せるというわけではないので、完成したメイジ 6 やアサシン 6 やハンター 6 には弱い。

終盤、対面のメイジ 6 が完成しそうな場合、☆5 タイドと ☆2 スラーガーで「ナーガ 2」 の魔防+35%を狙う。範囲攻撃で全員巻き込まれないように、盤面の配置を左右に分ける。これでタイドのスタンがうまく刺されば、そしてゼウスの雷がはずれれば、自分に Lv3 が多く揃っていたら、もしかしたら勝てるかも、という感じ。正直なところ、完成したメイジに対しての勝率は良くない。

おわり

GW はまだ終わってない!auto chess で効率よく溶かすぞ!

同時接続もやたら多いので、これから流行るの間違いないと思う。

amp-script の実用性について考える

AMP Conf 全体の感想は後回しにして(書かないかも)、 amp-script について

単に使ってみたい人は AMP で任意の JS を実行できる amp-script を試してみた - Qiitahttps://github.com/mizchi-sandbox/amp-script-preact

最初に

僕の amp に対するスタンスは http://ampletter.org/?lang=ja に示された懸念とだいたい同じで、基本的にAMPは邪悪なもの、現代のウェブの事情を考慮する必要悪と悪の中間ぐらいだと思っており、それと同時に極端にリソースが制約されたプログラミング環境というものが好きで、そういう点で AMP 由来の技術を追っている、という立場。

amp-script について知っていること

全然ドキュメントないので、コード読んで、書いて、触って、あと中の人達に直接聞いたりして知った知識

サイズ制限のせいで、いわゆる JS フレームワーク は preact(7kb) か lit-html(3kb) ぐらいしか選択肢にならない。もしかしたら svelte とか使えるかもしれないが…

複数コンポーネントは色々できそうな気がしたが、状態を共有しようとすると indexeddb を介したポーリングになると思って実験しようとしたが、 dexie を引っ張ってきたらその時点で 150kb オーバーした。webpack の minimize を常に有効にして watch させるとCPU負荷がかなり高くファンが唸りまくって、出先でやってたらバッテリ使い果たした。

preact も動いたり動かなかったりで、この Issue を見てる限り対応しようとしてるが、待つしかなさそう https://github.com/ampproject/worker-dom/issues/319

amp-bind との比較

AMP の動的コンテンツといえば amp-bind がある。これで専用のハンドラや mustache テンプレートの展開、 amp-live-list と組み合わせた動的コンテンツと組み合わせて、それっぽいものが作れる。

https://amp.dev/documentation/components/amp-bind

個人的な意見だが、これはよくある「プログラミング抜きで〜できる!」と称して一つの DSL 体系を一式覚えさせられるやつである。個人的に全くモチベーション上がらない。基本的には amp-script で全部済ませられるはずだが、amp-login でつくったセッション情報とかを amp-script 側に引き回せるか、まだよく調べてない。できたら同等の表現力になるはずだが。

コールバックで AMP.setState({counter: 1}) みたいな JS みたいなコードを書けるように見えるが、これは正規表現で使える表現が決まっている。また 1 行あたりの発行可能な文字列制限もある。

AMP Bento

カンファレンス中で発表されたもので、まだどこにも情報が上がってないのだが、AMP CDN 下になくても amphtml project の機能を使える、というやつである。 amp 制約下で全部これから作れと言われるとウッとなるのだが、逆に普通のウェブサイトでも使うと便利なウィジェットなどが色々あるので、これは普通に歓迎したい。

AMP の方向性

元来単純なものはAMP、複雑なものはPWAという棲み分けを意図していたように思うが、今回のカンファレンスで示された方向性からは、AMPがPWAやSPAという領域もカバーしようとしている、という印象を受けた。

どうせ Google のことだし内部で明確な方向性定めず部署ごとに競い合ってる状況だと思うが、個人的には邪悪に寄りすぎない範囲でやれることが増えると、ステークホルダーを説得する方便としては便利な技術であると思うので、邪悪ではない限りで応援したい。邪悪だと思っているが。

フロントエンドの開発環境に Docker は不要(少なくともMacでは)

追記: 前提部分

開発環境を docker-compose で抽象することが最近のベストプラクティスだとされているが、フロントエンドをコンテナに突っ込むと無視できないIOボトルネックが発生する。

とくにwebpackのファイル監視からのビルドで発生する高頻度のIO処理を捌くために、フロントエンドだけはホスト環境に移したほうがいい、という主張。


これについて

speakerdeck.com

自分の意見

  • Web開発者の主要な開発環境である Docker for Mac は I/O がとにかく遅い (3x~5x)
    • data volume の driver やら cache を工夫しても遅い
  • npm install/webpack は 基本的に I/O ヘヴィー
    • とくに大規模開発時の watch => build がクリティカル
    • webpack.conifg の entry で自分が関与する部分以外コメントアウトして開発してることもある
  • フロントエンドの最終成果物(.js, .css, .html)に環境依存なプログラムが含まれない(含まれてたらおかしい)
  • そもそも JS という言語自体がクロスプラットフォームに配慮された言語なので、ホスト環境によるランタイム差がほぼない

ネイティブモジュール周りの既知の問題

  • fsevents: webpack や chokidar などの裏側でファイルシステム監視を行うモジュール。npm の lockfile がビルドした環境次第で optional dependencies の native module をうまく依存に含めることができず npm install で再現されないことがある。ファイル変更監視が低速化するだけで動くには動く。yarn でこれが起きたことはない。
  • node-sass: libsass の node バインディングだが、ややビルドが不安定。nodeのバージョン上げると大抵コケるのでキャッシュ捨てて再ビルドが必要。最近は css-in-js が流行ってるのでnode-sass見かけることが減った。
  • node-gyp: node本体のビルドツール(python2)。 python3 にパスが刺さってる状態でネイティブモジュールをビルドすると失敗する。node でネイティブモジュールを使う環境は python が python2 を指している必要があるが、これは他のビルドツールでも何かと要求される要件ではある。

これらを知っていればそこまでクリティカルにはならない。

運用どうするか

CircleCI、デプロイ時、初期セットアップの手数を少なくするためにとりあえずNodeイメージ経由でのフロントエンドのビルドタスクは用意する。開発環境では使わない。

他のプログラミング言語の人から本体のバージョンを固定することを強く要望されることがあるが(それらの言語が不安定なことが多い)、直近の Stable 使ってる限りは Node の実行に差が出ることは稀で、フロントエンドのビルドツールツェインに関してはそこはあまり抽象してメリットがあるレイヤーではない。が、自分の詳しくない領域の安心感がほしいのはわかるので、上述のビルドタスクを提供する。

node のインストールが困難な開発メンバーがいる場合はサポートする。たぶん二手ぐらいで終わるので、docker それ自体の導入より遥かに簡単。

Windows/WSL環境 の場合

すいません自分がWindowsでフロントエンド開発したことないです。

あんまり人権がある方ではないとは聞いてる。

サーバーサイド node の場合

他のサーバーサイドと環境と違ってビルドによる環境差がそこまでないので気にしなくていいと思っているが、 node はネイティブモジュールの数次第で、 imagemagick あたりが鬼門。こいつは常に鬼門。別環境に追い出したい。

node server を運用する際はこの限りではない。

というのが自分の意見です。

Chrome 73 で Desktop PWA Support & mdbuf アップデート

developers.google.com

Signed HTTP Exchange もですが、個人的に待望だった Desktop PWA が正式リリース。 PWAアプリをウェブアプリのように振る舞わせることができます。

例えば mdbuf を開いて、「mdbuf をインストール」を選択すると…

https://i.gyazo.com/5f64a2c6f9d74b9c2851b4c96baa2a92.png

モーダルが出て

https://i.gyazo.com/e054fe8300c1d3fad1f37fc22f908bec.png

Win/Mac のアプリのように立ち上がります

https://i.gyazo.com/9f617215f1969f750482fd2009e4d3b8.png

mdbuf について

https://mdbuf.netlify.com

サンプルで紹介しましたが、これは僕が作ってる markdown のプレビューツール です。

amachang さんや結城浩先生へのインタビュー、その他このブログの記事、各種書籍への原稿も全部これで書いています。

mdbuf v1.0.0: 最高の Mardkown Preview を目指して - mizchi's blog

この時点からさらに自分で使い込みながら機能を足したので、Desktop PWA ついでに紹介。

アウトライン機能

ヘッダの位置にジャンプします。

prettier の整形

Cmd+S (Ctrl+S)で prettier で markdown を整形します。

バックグラウンドのコンパイル

WebWorker でコンパイルしているので、入力中のラグ(layout junk) が非常に発生しづらいです。普通に実装する markdown コンパイルはCPUを専有しがちなので、効果が大きいです。

編集中の領域に自動フォーカス

編集に対応するプレビュー側をハイライトします。

保存機能(IndexedDB)

保存します。

textarea => monaco editor => codemirror の切り替え

monaco エディタを使えば編集側でコードハイライトできます。

HTMLでコピペできそうでできない要素を作る

歌詞サイト内で湘南乃風の睡蓮花の歌詞がだんだん大きくなっていた「作詞XSSとか楽しすぎるものをみたけど…」 - Togetter

うたまっぷといえばコピペ禁止、コピペ禁止といえば最近こういう嫌がらせを考えていたので、やってみました。

U
O
H
Y
O
-
-
T
N
P
C
-
X
C
-
A
E
I
T
Y
S
O
T
N
T

↑をマウスで選択してコピペしてみてください。うまく範囲選択できないし、できたとしても無意味な文字列になります

仕組み

  • テキストをランダムに並び替える
  • ランダムに並び替えた文字を, 元の位置に来るように flex の order 属性を指定

フレックスアイテムの並べ替え - CSS: カスケーディングスタイルシート | MDN

コード

React でさっくり書いた

function Text() {
  const text = "YOU-CANNOT-COPY-THIS-TEXT";
  const chars = text.split("");

  const textOrders = chars.map(_ => Math.floor(Math.random() * 1000));
  const textOrdersSorted = textOrders.slice().sort();
  const idxMap = textOrdersSorted.map(v => {
    return textOrders.findIndex(n => n === v);
  });

  const chars = idxMap.map((to, original) => {
    return <div style={{ order: to }}>{chars[to]}</div>;
  });
  return (
    <>
      <div>
        <div style={{ display: "flex", flexDirection: "row" }}>{chars}</div>
      </div>
    </>
  );
}

const el = document.querySelector(".root");
ReactDOM.render(<Text />, el);

実行環境

https://markdown-code-runner.netlify.com/MQAgsghgTg1gJgewO4DsQGEFwKYgEoCuKK2UAUGQAbUAuAzmQGZEDGNAlgmgCrYAeNABQBKEAG8yIECy50aIGv3kBeEACIAmgHkAqgFp0AQQByxrdwNaAChr3cAEgEkAynYCiADW5qA3JOmy8iwAFtB0IKqKAgB0dAAOADbsQmpqwn7+MihyCkpaUDhQ4aohYdEAthBxggD6EQB84BA0wdGMCQgIUIKQLdFQECiI5SIgAFQgAIwADLPC6ZmBuQL5hXTOXYpwEcs0q6R0sUks2CKxmyIZUlk57HB8kHE7UXsFBxtQWxVVgoIAbgAaEAkJCOe6iZSNCRSKRQbA0AhQNAvfZFNrsIaOIb8QRoSHAiLKVR-BZSAC+pIC2XkIPQoSKOzuDyq32q7Aa0npdAA2uwALoLRbUkDYBLFEBMx6s340BBArrsADmGIgCQhUP8sPhiLQAB44Ow-iA5ABPBLYZRiMQgLqFABcCgQIDJZPqYlKRW5sr5ZN1AHoDX96n5yZS4QikSBBJqQLr6jGpPrDfGYanY4HjTQzRarSADfEEhATQ61O1+GogWW+AARdhwticFAlqDINTO11iUV0X0B5MJ2O9oMx-0pkALMkUG7yUU7RAsAjlbAoGjRACOBFIJucouwbC6gjU-U6NDSfjw2AgbGrWjA-SXhUEut4AhAfvqQNFC2olDIQA

だるくてマルチバイト対応してないので、コードポイントで分割してください。

謝罪文などでこれが来たらいい感じに読者の反感を買えると思います。 悪用禁止!!!!!!!!!!!!!!!

SPA が、ウェブ開発のベストプラクティスになる時代

最近のフロントエンドに関するお気持ち。正直まとまってはない。


最近、こんな感じのツイートや記事が増えた。

web 技術をキャリアの中心にしない

シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。

自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえばゲームだったり、Electron 環境でネイティブに負けないリッチな UI を提供するためのもの。

しかし、最近ではその潮目が変わってきている、と強く感じる。具体的には、SPA 技術は「すべてのウェブ開発におけるベストプラクティス」になってきたと感じる。

Node.js が Rails に「勝てなかった」理由

元々 Node.js が c10k 問題へのソリューションを謳って登場したのを覚えてる人は、どれだけいるだろうか。その時は他 WAF への Altenative であることが強く打ち出されていた。

それから数年経って、結論から言ってしまえば、Node.js は Rails に勝てなかったのではなく、勝つ必要がなくなった。Node.js は主にフロントエンドツールチェインとして発達し、マイクロサービスにおけるフロントエンド周りを担当する「補助輪」として機能すればよくて、バックエンドに興味を持たなくなった。

現代のストレージは、アプリケーションレイヤーで管理すると言うより、RDS や Aurora, Firebase や Spanner のように、フルマネージドなバックエンドで抽象されるものになった。データベースのスケーリング技術を知識として持つことは依然として重要だが、以前ほど重要ではなくなった。

現代では、並列実行を管理する主体がプログラミング言語のスケジューラから、前段のロードバランサやコンテナのスケジューラに移ってきた。Node.js の弱点はシングルスレッドのイベントループが process fork に向いておらず、シングルプロセスを酷使するや故に例外復帰が難しいことだったが、むしろ現代のマイクロサービス環境ではコンテナに割り当てられた CPU を使い切ることが重要で、例外復帰は投機的なコンテナ単位で行われるようになった。

結論から言えば、 RailsSymfony のような一つの言語に依存するフルスタックフレームワークは今世代が終わりで、これからはPaaSやマイクロサービス環境で他と協調することが前提のものに分解されていくだろう。しかしそのための土台になると予想される k8s は、数年前のフロントエンドと同じような「難しい抽象を一番うまい抽象化したやつが勝ち」みたいなOSS乱立期で、やや手を付けづらい。

JS の進化 / 漸進的型付けの時代

JS といえば昔はphpperlと並んで貧弱な言語の代表格だったが、近年の ES2015 以降の言語仕様の進化は目覚ましい。ランタイムにおいても V8 の JIT は異常な域で、繰り返し実行される処理に関しては、ネイティブから「多少遅い」程度のスピードが出てしまう。

また、今は動的型付に対する反動の時代で、ドキュメンテーションとしての型、ある種の Linter としての型というものが再評価されている。その点で TypeScript は漸進的型付けに必要なものを全部備えていて、現代における動的型付けと型の向き合いに関してはほぼ最強みたいなレベルに達している。

漸進的型付け言語の時代に必要なもの - mizchi's blog

というわけで言語仕様的な貧弱さの問題も解決しつつある。TypeScript の型定義も昔はないのが普通だったが、最近は大方ある、という感じになってきた。

そういえば、 python で pyre-checker や mypy を試してみたが、正直実用に程遠い完成度で、これだったらまだ TypeScript のが開発体験は良いという感想。(ただ js では numpy が現状置き換えられないので機械学習用途に使うのは難しい)

依然として後方互換のためのバッドパーツは残っているものの、ES2015 と TypeScript のプラクティスが普及することで解決される問題だと思っている。

WebAssembly は…、たぶん非常に限られた使い道になりそうな予感がしていて、GC インテグレーションの問題が解決しない限りは C++/Rust 以外でまともなサイズのwasmバイナリが生成できない。ツールチェインは Rust がよく出来るので、しばらくはピンポイントで重い処理を Rust を書く、というのがメインになりそう。

パフォーマンス問題

読み込み問題も、読み込みを lazy に分割する chunk splitting の技術や、precat や lit-html のような軽量 View ライブラリ、vue や angular の静的解析技術によるコード生成サイズの減少で、大きな問題にならなくなってきた。

一部のフロントエンドは、 HTTP/2 + ESModules 環境でブラウザネイティブの ESM ですべてを解決する夢を見ていたが、現状そのための仕様は頓挫し、Webpack を捨てることは、あと数年は困難になった。

Cache Digest と HTTP2 Server Push の現状 | blog.jxck.io

webpack が置き換えられることはあるかもしれないが、その目的はしばらく死にそうにない。

今後の SSR問題

SSRは高難易度の技術だったが、next.js や nuxt.js の普及、国内においては特に nuxt.js が普及したことで比較的手軽になった。自分は React 派だが、正直 next.js より nuxt のが遥かに良く出来てる。(というか next.js は過剰なミニマリズムの病気に掛かっている気がする…)

ついでにいうと、WebComponents は今の仕様のままだと依然として SSR の問題を抱えていて、shadowRoot 下に生成されるコンテンツをクローリングさせるために SSR が必要になっている。というわけで今後もSSRを避けて通ることができないと予想している。

自分が知る限り、SSR を行わないウェブサイトは、ニュースメディアのような速報性が強いサイトには依然として SSR が必要ではあるが、それ以外では意外とインデックスされるし、そこまで重要ではない。(依然として検索スコアが低いような気はしなくはないが…)

これは自分が知る限り、GoogleBOT によるウェブサイトのクローリングが行われると、JS 実行キューに入り、そこでページが構築されるとインデックスされる、という 挙動にある。JS によるページ構築は即座に行われるのではなく、数時間遅れて実行される。

今後の展開としては、BFFのレイヤーはマイクロサービスのクラスターの一部というより、 CDN Edge 上の Edge Worker に主戦場が移って、キャッシュマネジメントとSSRを同時に担うのではないか、と考えている。

Edge Worker PaaS の fly.io が面白い - mizchi's blog

workers.dev

本質的な作業に集中する、とはなんだろうか

主に非エンジニアのスタートアップ事業者や新規事業者にとって興味があるのは、UI と概念のモデリングとそこから生まれる体験であって、そのインフラストラクチャに対応として構成は「仕方なく」やるものなのは変わっていない。(それこそエンジニアリングといえばそうなのだが…)

なので、UI に興味が集中する。なので、競合に勝つための体験、「SPA」に興味が集中するのは、当然のような気もする。ただ、うまく使いこなせているプレーヤーは少なく、とくにパフォーマンスチューニングは属人化しているのが現状(なので自分のようなフロントエンド専門のフリーランスに需要がある)

あるジャンルが高度化しては PaaS/OSS/Container にラップされる、というのを今後も繰り返すだろうが、フロントエンドがそうならないのは、UI は人間の理不尽な要求に振り回される、という特徴にあるという気がしている。

例えばソーシャルゲームはリッチ化の過程でユーザーの期待値が膨れ上がり、開発費が高騰して参入障壁が跳ね上がっているが、似たような現象はどの分野でも起こる。UI への投資が減ることはないだろう。エンジニアとデザイナと連携する部分で AI による生産性の向上はあるかもしれない。

個人的には e2e が未発達なことに課題を感じている。


おわり。