2021年の振り返りと2022年の抱負

今年もいろんなことがありましたね。皆さんはいかがでしたか？　これは自分のメモがてらの毎年書いているやつです。

去年はこちら。

mackee.hatenablog.com

登壇とかイベントとか

Japan.pm 2021

mackee.hatenablog.com

思ったらpublicな場での登壇はこれだけかも。社内だとLT的なことはちょいちょいしているんですが、コロナもあってか勉強会参加の習慣もめっきり少なくなってしまいました。

上のやつでは、hotwireを触っていますが、その他の諸々が忙しくなって触ってないですね〜。

ところで、Perl Mongersなイベント関連では来年YAPC::Japan::Online 2022が行われるそうです。スピーカー募集も始まっていますね。

blog.yapcjapan.org

僕も何かネタを出せたらいいのだけれども。Perlから別の言語へマイグレーションしている途中の話するかな〜。パールパールしていないですが。

ISUCON11

去年に引き続き、fujiwara組の組員として出場し、優勝していました。本人は今でも特に実感はなく、会社の人たちがfujiwara組で出場して優勝してめでたいな〜みたいな一歩引いた視点になっています。何故...

チームメイトのfujiwaraさんとacidlemonさんの記事はこちら。

sfujiwara.hatenablog.com

beatsync.net

僕は特に書いてないというか、優勝報告記事の下書きはあるんですが、天然物の先送り体質のせいで時期を逸してしまった。

内容としては、

• 素振りを2回やった。素振りを一緒にやっていただいた id:Soudai さんと id:uzulla さんにマジ感謝
• サーバサイドエンジニアとしての業務にわりかし近い位置の問題が出たので相性が良かった

みたいな話です。あと、インタビューされた記事が以下に2つほどあります。

gihyo.jp

www.kayac.com

ARCREVO Japan 2020 Onlineのパーカーを着ている者です。誰もそのパーカーなんですかと聞いてくれなかった。

とはいえこの結果に満足せずに精進していきたいですね〜。

仕事

相変わらずTonamelの中の人です。

今年取り組んだ話としては、決済基盤の組み込みでしょうか。その辺の話の一部か以下の記事に書いてあります。

techblog.kayac.com

今年は半年ぐらいStripeのドキュメントやらと睨めっこして、あーでもないこーでもないみたいなことをやったりしていました。

以下ポエム。

ところでこの記事にある、マイクロサービシーズみたいなのは結構楽しいんですけれど、Stripeをいかに使いこなすかみたいな部分に関しては、結構"仕事"って感じになってしまって、なかなか足が向かない。うーむ、何が違うんだろうなあ。エンジニア市場で一般的に価値があるのは決済ゲートウェイを使いこなす人であって、僕が今の仕事で大好きなトーナメント表をいかに綺麗に組むかみたいなのは、日本だと片手で数えるほどの会社しか必要とされてないのになあ。

以上ポエム。

他にも来年に向けてさまざま仕込みをやっているのですが、その辺りはわりかし興味がある分野なので、話していきたいですね〜。Stripeに関しては、、、こういう自分で持ちたくないものこそ書くべきだと思ったので何か書くか〜。社内ドキュメントになるかもしれんが。Stripe Connect使ったプラットフォーム決済基盤とか、ノウハウがインターネットにそんなにないからだいぶ苦労したんよ。

趣味

山

去年少しだけ始めた山登りも、月1ぐらいで登れるようにしようとなって、とはいえ今年登ったのは低山も含めて6座だったと思う。

金時山

金時見晴らしパーキングという最近できた道の駐車場から標高チートして登った。

宝永山火口

会社で「噴火したら大阪リージョンに逃げような」という話をしていて、前に噴火した火口を見にきたのだった。宝永山自体には登っていない。

鋸山 ラピュタの壁

途中でお腹が痛くなって山頂まで行ってないのでまたリベンジしたい。

畦ヶ丸山頂

合計6時間ぐらい歩いた。川を渡るのに石を飛んでいかないといけない箇所があって、恐怖であった。

近所の天園ハイキングコース

鎌倉に引っ越したので、鎌倉と横浜の境目のハイキングコースにチャレンジした。足の運動にちょうどいい感じ。

キャンプ

今年も何回かキャンプをした。とはいえ、緊急事態宣言が開けた後からだったので、回数はそれほどでもない。

西丹沢

前述の畦ヶ丸に登った際に駐車場にデイキャンプ扱いで停めさせていただいたのだが、なんかいいなと思ったので2週間後に泊まりにきた。紅葉し始めな感じでなかなか良かったです。

南房総

山の急斜面にサイトがあるみたいな感じで、オートサイトとはいえ、その急斜面を車で登らないといけなかった。入り口で「この車四駆ですか？」と聞かれ、おそらくジムニーとかランクルみたいな山の四駆っぽい感じで聞かれたのだと思うが、我がGRヤリスは四駆なので「(スポーツ)四駆です」と答えてなんとか登った記憶がある。

ふもとっぱら

言わずと知れた広大なフリーサイトと富士山を望む絶景のサイト。ここで一人焼肉大会とイキっていたものの、台風が過ぎ去った直後で、風がめちゃくちゃ強く、その日はできなかった。これは翌朝に早朝焼肉をしているところ。

カート

八王子の方々に誘われてレンタルカートに励んでいた。

Google Photosを見返すと自分の写真がなく、他の方の写真やヘルメットにつけたGoProの動画しかなかったので、今度やったら撮ってもらおう。

キーボード

今年はKeyboadio Atreusでほぼほぼ過ごしていたものの、年末に機運があって、Atreus風のキーボードを作っていた。

potreus keyboard

これの基板データは以下にある。

github.com

GL516のGBにも参加したのと、他にもアイディアがあるので、基板設計周りはもっと励んでいきたいですね。

組み込みRust

ゴールデンウィークに以下の本を買って、Rustを学んでいた。

www.amazon.co.jp

Wio Terminalでライフゲームを実装していたりしていた。

ライフゲーム on WioTerminal

こちらで同じコードがWebでも動くやつもあげてある。

他にもRust入門として、こちらで紹介されている記事もやった。

diary.hatenablog.jp

というわけで、ある程度、今のRustを知れたので、何かに活かしたいが活かせるかな〜。そういや去年の振り返りの記事に、

あーあと、Rustやりたいんだった。ずっとやりたいって言っているのをどうにかしたいですね。

と書いてあるのはやっと達成できたと言えそう。

格ゲー

eスポーツのトーナメントプラットフォームを仕事でやっているので、そういう類のゲームにチャレンジしてみたいなと思い、今年新作が出たGUILTY GEAR -STRIVE-に取り組んでいた。

一時期は毎日やってたけれども、今は時間をおきつつやっている。メインキャラはラムレザル、ランクタワーとしては9Fぐらい、10Fは一瞬拝んだことがある程度。エンジニア仲間でGGSTをやるDiscordで部屋をたててやることも多いので、それも励みになっている。

ラムレザルというキャラクターはコンボで高火力が出るという、僕はコンボ練習大好きなのでうってつけと言えるのだが、プレイスタイルとしては中距離戦メインで、画面端までなんとか持っていって固めをして崩して一発6割のコンボをやる。それを2回やれば勝ちといった感じ。しかし基礎的な格ゲー筋がついていない僕は、画面端まで持っていったり、相手の崩しに耐えるという点で弱く、なかなか強みをいかせてなかった。最近、出口が見えてきた兆しがあるので、来年は掴み取りたい所存である。

目標は大会で年度内に一勝です。1ラウンドは取れるぐらいにはなってきた。

追いかけているマンガ

ちなみに単行本派です。

去年からの継続

• 新九郎、奔る！
• 銀河英雄伝説(藤崎竜版)
• Dr.Stone
  • 刊行スピードがはやい
• デッドデッドデーモンズデデデデデストラクション
• アルスラーン戦記
• 山と食欲と私
  • 参考になる
• ゆるキャン△
• ダンジョン飯
• ざつ旅-That's Journey-
• バーナード嬢曰く。
• 空挺ドラゴンズ
• チ。―地球の運動について―
  • 結構読むのに心の準備がいる
• 人形の国
  • この前読んだらいきなり終わってしまってびっくりしていた
• ガールズ＆パンツァー　リボンの武者
  • これも終わってしまったなあ
• メイドインアビス
  • 来年アニメ2期なんだっけ...また心の準備をしないと
• 3月のライオン
• 宙に参る
• 僕の妻は感情がない
  • ちょいちょい面白い
• 亜人ちゃんは語りたい
• 銃夢火星戦記
  • 2巻ぐらい前で終わるかなと思ったがそんなことはなかった
• ヘテロゲニア　リンギスティコ　～異種族言語学入門～
  • 異世界ファンタジーが見た目そのままで内容がハードSFに変化してきた

新規

• 望郷太郎
• 怪獣8号
• 紛争でしたら八田まで
  • 勉強になる(?)
• 機動戦士ガンダム 逆襲のシャア ベルトーチカ・チルドレン
  • 映画の閃ハサ見る前に逆シャア思い出すために読んだ
• AIの遺電子 Blue Age
• 逃げ上手の若君
  • 刊行スピードがはやい

三体

https://www.amazon.co.jp/gp/product/B0922G73JR/

ついに、最終巻「死神永世」が出て読んだのだが、読んだ直後は魂を抜かれたような気分になった。作中では宇宙のどこか遠いところ、もしくはこの宇宙ではないところに読者ともども連れてかれるのだが、終わった瞬間に家の部屋にぽつんと一人になってしまって、oh...となってしまった。

ドがつくほどのハードSFでありながら、エンタメ小説であり、ため息が漏れてしまう。読んだ時のことを思い出して、感情が来てしまった。

来年

2022年って、2と0しかなく、次は2200年で多分生きてないので、貴重な1年であると言える。健康を維持しつつやっていきたい。チャレンジしたいこととしては、仕事のエンジニアとしてはいろいろあるんだけれども、まあそれは社内評価システムに書きつつ、表に言えることとしてはあんまりないかな〜。これは前からの課題だけれども、内外問わず巻き込み力をやっていきたいですね。

工作としてはキーボードもあったけれど、仲間内でミニ四駆ムーブメントが起き始めているので、このビッグウェーブに乗り遅れないようにしたい。あと、3Dプリンタ全然できてなかったので、再開したい。やっていなかったわけではないが、また3Dプリンタのパーツ作るので溶けてたんだよなあ。

あーあと！なんかこういう終わり際にいっぱい出てくるな。来年のGWの文フリで何らかを頒布することになっていたので、執筆しないといけない。何らかは何も決まっていない。

では、良いお年を。

大コンテナ時代における.gitを使うワークフローの難点を解決するためにGitHubDDLを作った

こんにちは、この記事はPerl Advent Calendar 2021の4日目の記事です。

3日目は@yoku0825さんのPerlで作られたMySQL用の何かについてでした。日々お世話になっている、pt-query-digestがPerlで作られているのは知っていたのですが、他にもいろいろPerl製ツールがあるんですね。

さて、最近仕事で発生した課題を解決するためにGitHubDDLというCPANモジュールを作ったので紹介させていただきます。

TL;DR

• コンテナ環境において、プロジェクトの.gitをコンテナイメージに焼いたり、volume mountを行うのはいくつかの面で望ましくない
• 仕事ではDBスキーママイグレーションに.gitを用いるGitDDLを使用していた
• 以上のために、ECSでEFSマウントで.gitをマウントして構成が複雑になったり、.gitをイメージに焼いてpullが遅くなるなどしていた
• それを解決するために、.gitを使わないツールとしてGitHubDDLを作った
  • .gitの代わりにGitHubからファイルを取得する

コンテナ環境に.gitを使うツールを使うのは辛い

Web開発においてはほとんどのケースでgitを使うようになっているのではないのでしょうか。gitはバージョン管理ツールではありますが、その副作用としてファイルの変更ごとに対応したコミットハッシュがつき、それをバージョン番号と見なすことができます。このバージョン番号や、過去のバージョンのファイルを取り出せるというメリットを使って古今東西さまざまなツールやワークフローが作られていると思います。

さて、現在の私の仕事では、全ての本番環境はAmazon ECSを使ったコンテナ環境で動作していて、踏み台サーバ的な存在も廃止してしまいました。では、手動でバッチプログラムを実行したり、DBスキーマをマイグレーションする作業をする場合には、本番とほぼ同様のコンテナを起動して、そこにECS Execやそれに類する技術でログインし、実行しています。また、シェルへのログインもせずコンテナ起動時にCMDをバッチプログラムに上書きして実行する場合もあります。

つまり、S3やEFSなどで外部から引っ張ってこない限りは、コンテナイメージに焼かれたファイル群のみを使ってバッチを実行するという制限が付いているわけです。ここに.gitを要求するようなワークフローが存在するとコンテナに.gitを焼くなり、EFSマウントを行うしかありません。このケースは非常にめんどくさくなります。

.gitをコンテナイメージに焼く場合の弊害

.gitにはshallow cloneを活用しない限りは、最初のコミットから今に至るまで全てのファイルが記録されています。.gitをファイル変更履歴として活用する場合、shallow cloneで--depth=1を指定すると意味がなくなるため、ある程度のコミットを掘って取得する、あるいは通常のcloneを行うことになります。

前者の場合、depthで指定した深さよりも前の履歴が必要と思われるケースではさらにunshallowをすることになりますが、それが頻繁に想定される場合はshallow clone自体が意味がないので、結局通常のcloneが最適解ということになります。さらに必要になったらunshallowする場合は何らかの形でcloneする場合の鍵をコンテナタスクが取得できなければなりません。必要になったらunshallowは労力が大きそうです。

というわけでリポジトリの全ての履歴を持った.gitを焼くと楽になるのですが、反面コンテナイメージが大きくなります。大きくなった場合、buildやpushに時間がかかります。一番大きな問題はpullに時間がかかることです。コンテナタスクを増やしてスケールアウトをする場合にpullの時間がかかると、タスク数が負荷を受け止め切れる台数に至るまでに時間がかかり、障害を起こすかもしれません。

また、Amazon ECSの場合はEFSを使用する手があります。つまりコンテナイメージの外に.gitを置くボリュームを作成しておき、これを必要に応じてマウントするという手法です。ですが、これは構成が複雑になり、定期的な.gitのメンテナンスが必要です。頻繁にブランチを切り替えたりする環境ではgit gcを定期的にするのを怠って、checkoutが非常に遅くなり問題になったケースがありました。

.gitを使わないAlternative GitDDL => GitHubDDL

私のプロジェクトで使用しているGitDDLは、DBスキーママイグレーションツールで、.gitを使用してDBに適用ずみのDDLを取り出し、ローカルにあるDDLと比較してALTER文などを生成するものです。

スキーママイグレーションは頻繁に行う作業であり、このためにコンテナイメージに.gitを焼いていたのですが、いい加減なんとかしないといけないなというのと、実装アイディアはあったので、今回新しくGitHubDDLを作成しました。GitHubDDLはGitDDLから多くのコードを利用しており、初期化オプション以外のメソッドの互換性を保った実装にしています。

.gitの代わりにGitHubを使う

GitDDLではgitコマンドを使ってDBに適用されているDDLを取り出すと記述しました。具体的にはこのようなコードになっています。

GitDDL/GitDDL.pm at bdf5dae23d685d90136cec606cbe42d5e9c78c95 · typester/GitDDL · GitHub

sub _dump_sql_for_specified_commit {
    my ($self, $commit_hash, $outfile) = @_;

    my ($mode, $type, $blob_hash) = split /\s+/, scalar $self->_git->run(
        'ls-tree', $commit_hash, '--', $self->ddl_file,
    );

    my $sql = $self->_git->run('cat-file', 'blob', $blob_hash);

    open my $fh, '>', $outfile or croak $!;
    print $fh $sql;
    close $fh;
}

この関数の外部から渡されている$commit_hashは変更対象のDBに存在するgit_ddl_version(名前はオプションで変更できる)から取り出したものです。これからgit ls-treeでgitオブジェクトのIDを取得し、git cat-fileで実際に取り出しています。

一方、GitHubDDLではどうやっているかというと、

GitHubDDL/GitHubDDL.pm at 046e10461231e619aae1473523aeedacfc1031f7 · mackee/GitHubDDL · GitHub

sub _dump_sql_for_specified_commit {
    my ($self, $commit_hash, $outfile) = @_;

    open my $fh, '>', $outfile or croak $!;
    if (my $method = $self->dump_sql_specified_commit_method) {
        my $sql = $method->($commit_hash);
        print $fh $sql;
        close $fh;
        return;
    }

    my $url = sprintf "https://raw.githubusercontent.com/%s/%s/%s/%s",
        $self->github_user,
        $self->github_repo,
        $commit_hash,
        $self->ddl_file;

    my $furl = Furl->new;
    my $res = $furl->request(
        method          => "GET",
        url             => $url,
        headers         => [
            Authorization => "token " . $self->github_token,
            Accept        => "application/vnd.github.v3+raw",
        ],
        write_code      => sub {
            my ( $status, $msg, $headers, $buf ) = @_;
            if ($status != 200) {
                die "status is not success when dump sql from GitHub: " . $self->ddl_file . ", status=" . $status;
            }
            print $fh $buf;
        }
    );
    close $fh;
}

このような形で、GitHubへ直接アクセスすることでファイル本体を取得しています。ちなみにprivate repositoryなどでも使えるように、Access tokenをつけています。これは基本的にはいわゆるPersonal Access Tokenを指定しますが、拙作のGitHub::Apps::Authを使うことで、GitHub Appsの認証情報でも同様に使うことができます。

その他おまけ

上記の__dump_sql_for_specified_commitメソッドの動作を外部から書き換えられるように、dump_sql_specified_commit_methodというオプションをつけられます。これはCodeRefを受け取るもので、どういうケースで使うかというと、.gitがあるときはGitDDLと同じ動作、GITHUB_TOKENが与えられたらGitHubDDLの動作という風に切り替えられます。

以下のコードは、これに加えて、DDL_VERSION環境変数にローカルのDDLのコミットハッシュが与えられるつもりだが、ない場合はGitDDLと同じ動作という挙動を実現しています。

my $ddl_version = $ENV{DDL_VERSION};
if (!$ddl_version) {
    $ddl_version = `git log -n 1 --pretty=format:%H -- sql/schema.sql`;
    die 'require $DDL_VRESION or .git on local for migrate' if $?;
    chomp $ddl_version;
}
my $dump_sql_specified_commit_method;
my $github_token = $ENV{GITHUB_TOKEN};
if (!$github_token) {
    $dump_sql_specified_commit_method = sub {
        my $commit = shift;

        my (undef, undef, $blob_hash) = split /\s+/, `git ls-tree $commit -- sql/schema.sql`;

        my $sql = `git cat-file blob $blob_hash`;
        chomp $sql;
        return $sql;
    },
}

my $gd = GitHubDDL->new(
    ...,
    ddl_version => $ddl_version,
    dump_sql_specified_commit_method => $dump_sql_specified_commit_method,
);

このようにすれば、漸進的にGitDDLからの移行ができます。

いかがでしたでしょうか？　明日5日はid:kfly8さんの「Perlのコンテキストクイズにツールで答えてみた」です。お楽しみに！

以下は捕捉情報

DBスキーママイグレーションとは

普段のWeb開発で私はMySQLもしくはMySQLプロトコルをしゃべるDBソフトウェアを使っています。MySQLが属するRDBMSというデータベースの種族は、かっちりと形が決まったデータベーススキーマを定義してRDBMSに適用し、それに沿ったデータを実際に稼働するWebアプリケーションで操作します。

ところで、RDBMSのスキーマ、一般的にはDDLと呼ばれる形式で記述されます。例えば新しくテーブルを作るときは、

CREATE TABLE `sample_table` (
    `id` BIGINT NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(191) NOT NULL,
    PRIMATY KEY (`id`)
);

のように記述するわけです。

ただ、私がお仕事で作るWebアプリケーションは、インターネット上で公開された後も、数年間の運用というものが発生し、その間も機能を追加したり修正をしたりなどの作業が発生します。

そういった既存コードをいじる作業もあるのですが、DBスキーマを変更しなければならない場面も発生します。

例えば、上記のsample_tableにカラムdescriptionを足したいとなった場合、これがお手元の開発環境であれば、

DROP TABLE `sample_table`;
CREATE TABLE `sample_table` (
    `id` BIGINT NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(191) NOT NULL,
    `description` TEXT DEFAULT NULL
    PRIMATY KEY (`id`)
);

とすれば良いのですが、これをこのまま実際に稼働している本番環境で適用できることはまずありません。何故なら、運用を始めたWebアプリケーションのDBには消えてはいけないとされるデータが既に入っており、そこにDROP TABLEを打つことはできないからです。

ではどうするか。以下のDDLで既存テーブルにカラムを追加します。

ALTER TABLE `sample_table` ADD COLUMN `description` TEXT DEFAULT NULL;

このような一連の作業をDBのスキーママイグレーションと呼びます。

実際に世間ではどうやっているの

人間がスキーマ変更を伴うデプロイのたびに、手で温かみのあるALTER文を書くのは、できなくはありませんが、めちゃくちゃ大変なことではあります。また、ローカル開発環境構築時などではイチから完全な状態のDDLが欲しいところです。その場合、開発環境向けには完全なDDL、デプロイ用にALTER文を用意することになり、ミスや抜けもれが容易に発生します。もちろんこの完全なDDLとALTER文を逐次適用した状態のDBを比較するテストコードを作ることはできなくはないとは思いますが...。

というわけで私の知るかぎり、この辺りの運用を解決するためのアプローチとして以下の2つがあります。

• 変更したい部分を記述したDDLもしくはそれに準じるDSLを書く。完全なDDLはそこから生成する
  • 例: Active Record Migrations
• 古い(もしくは適用されている)完全なDDLと、変更後の完全なDDL間の差分をプログラムで計算し、ALTER文を生成する
  • 例: schemalex, sqldef, ridgepole, GitDDL

また、後者の差分を出すケースの場合の中にも、比較対象のDDLの取り出し方にいくつかアプローチがあるようです * 適用したDDLをバージョンごとにローカルファイルで保存しておく * メリット: ローカルファイル同士の差分でシンプル * デメリット: DDLの適用ごとに完全なDDLのファイルが増えていく。以前に適用したファイルはどれか何らかの方法で覚えておく必要あり * バージョン管理ツールでDDLが管理されている場合、比較する際にバージョン管理ツールで前回適用したコミットハッシュからDDLを取り出す * メリット: バージョン管理ツールでDDLを含んだコードを管理している場合は合理的 * デメリット: ALTERを生成する場所にバージョン管理ツールのメタデータファイルが必要, 適用済みコミットハッシュを何らかの手段で覚えておく必要あり * 変更対象のDBに接続し、SHOW CREATE TABLEなどのコマンドで適用済みのDDLを取り出す * メリット: 前のDDLのバージョンなどを覚える必要はない。適用したいDDL以外のローカルファイルが必要ない * デメリット: ALTERを生成する場所からDBに接続できる必要がある

それぞれメリットデメリットがあります。

GitDDLのやり方

GitDDLは今まで説明した方法のうち以下を採用します。

• 2つの完全なDDLから差分を生成する
• gitから過去に適用したDDLを取り出す
• 適用したコミットハッシュはgit_ddl_versionという専用のテーブルに記録する

プログラミング言語・技術を流行りで選んでもあんまり意味がない気がする

これはただの持論だし、さらに今はこう思っていたよっていう感じで、思想をブログに焼き付けておいてあとから自分で見たときに「ガッハッハ、このときはこう言う考え方をしていたんだな」とあとから自分を振り返って酒の肴にするぐらいの意味なんだけれども。

過去を振り返ってみると、プログラミング言語やその他のWebに関連する技術を流行りで選んだとしても、あんまり意味がない気がしたと思った。

ある言語は将来が無いから選択しない、ある技術はこれから伸び盛りだから選択する、みたいなことを僕は昔していた。ここでいう昔というのは2005年ぐらいのときに、Webプログラミングを独学でやっていたときにしていた気がしていた。いわゆる駆け出しって言う感じだし、そもそも高校生でアマチュアも当然、お金をもらってWebプログラミングをしている今とは環境も状況も全く違う。

当時の僕から見たWebプログラミングといえばレンタルサーバでPerlを動かすCGIであり、PHPが盛り上がってきていた時期がと思う。その時期にはRailsもでてきて、フロントエンド技術としてはAjaxが提唱された頃。でもブラウザ上でゴリゴリ何かを動かすのであればFlashを使うのが主流だった。

僕はこれらの選択肢の中から、PHPとFlashを選択している。Flashではモーショングラフィックスっぽい感じの動きで自分のサイトを作ってみたり、PHPではスレッドフロート掲示板を作ってみたりしていた。そこに「将来これが盛り上がるだろうからベットする」ではなく、今選べる選択肢の中からしっくり来たものを選んだ。その時期にCやPerlなんかもコピペまじりでHello Worldぐらいのチュートリアルはやってみたものの、一番「これは自分で物を作れそう」と思ったのは唯一PHPだけだった。Flashはその後に見様見真似でonClickでgotoAndPlayとモーショントゥイーンだけで作っていた。そのぐらいでも楽しかったし、何かしら物を作って公開している感は出ていた。その時の僕のモチベーションというのは、「物を作って人に見せる」というものだった。だから自分が考えたものを自分の手で完成しきれる技術なのか、という軸で選んでいたと思う。ただ、意識的にやっていたわけではない。

時が経ち、Webサービスのプログラマとして就職したときには、今流行っているだとか、やっている人が多いだとか、キラキラしてそうみたいな観点で選ぼうとしていた気がする。ただ技術選択の余地というのは新人さんだとそんなに選択幅がないので、入れられる範囲で流行っていそうな物を取り込んでいた。これはこれで当時は正解だったと思うし、今となっても、吟味するという力にもなっていると思う。ただ、そのときプログラミング言語や技術に惹かれたときの最初に興味を持った理由は「流行ってそう」である。たぶん今はこう言う理由で選ばないと思う。

ポジションを話すと、僕は運用しているWebサービスを開発しながら発展させていく立場で、技術選択も出来る立場である。が、故にコンサバに技術選択をしていると思う。これは回り回って原点に戻ってきたのだけれども、一番の軸で「自分たちに扱える技術なのか」という点である。お仕事でプログラミングしている以上、完成してユーザに提供しないと意味がないことを今の僕は知っている。当時の僕は知っていたけれど見ないふりをしていた気がする。

俺たちには今しか確実には見えないし、今やれるかどうか、そして今選んだものを未来も選び続けられるかどうか、選ばないとして捨てられる選択肢かどうか、つまり自分がコントロール出来る範囲で選択するという感じである。軽量なフレームワークやライブラリを選べば、いざとなれば自分でメンテナンスができるが、重厚だとそれもままならない。これもコントロールできるかどうか、扱えるものなのかという観点だと思う。

これはチーム全体を見るベテランの観点であり、ジュニアのレベルで大事なのは、作りきれるかどうかだと思う。自分で作ろうと思ったものを作りきれたときに学べることは大変多い。言語や技術に特化した知識も学べるけれども、あとに効いてくるのはもっとメタな知識だと思う。メタな知識があれば、他の技術にわりかし楽に乗り移れる。強くてニューゲームがこの界隈にはあると思っている。あと技術を学ぶっていうのは、脳に覚えられる容量があって、一定の容量までしか詰め込められない、みたいなものではない。いっぱい覚えられるし、覚えれば覚えるほど技術の理解の解像度が上がる。ただ、時間的制約はあるので、そういう観点から使える技術をまず学ぶという圧力はあると思う。

最初に選んだ選択肢のうち、PHPは世間では広く使われている主流のプログラミング言語であるものの、今の僕は仕事で使っていない。もう一つのFlashの今の状況は、皆さんがよく知っているとおりである。だが、この選択肢は間違っていたかと言われると、全然間違っていなかった。なぜならどちらの道具も当時の僕が作りたいと思ったものを作りきれる技術だったからだ。それで学んだことは多いし、今にも活きている。

いつも調べることをチートシートにしてTシャツにした

相変わらず仕事ではPerlを書いているんですけれど、none とか zip とかそういう便利関数がList::UtilにあるのかList::MoreUtilsにあるのかわからなくて困っていた。

List::Utilっていうのは何かというと、Perlで配列を扱うときに便利な関数集で、コアモジュールなので特に追加でモジュールを入れなくても(CentOSとかのシステムPerlでない限り)使える。

例えばmaxっていう配列(厳密にはリスト)を渡したら最大の値のやつを返してくれる君があるんだけども、こんな感じ。

use List::Util qw/max/;

my $max = max(1..10); # 10

別にこれはList::Utilを使わなくても、こんな感じでsort使えばできるんだけども、

my ($max) = sort { $b <=> $a } (1..10);

firstとかnoneとかは確定したら途中で打ち切ってくれるので自前で書くよりは速いし、そもそもXSだし、名前もわかりやすい。sumとかはmy $total; $total += $_ for ...;ってやればできるけれど、まあなんか$_とかあんまり使いたくないじゃないですか。そういうのを丸っと引き受けてくれて便利。

ところがこれだけだと足りないことが世の中あり、もっといろんな便利関数が実装されているのがList::MoreUtilsです。こっちはコアモジュールではないのでcpanm List::MoreUtilsをやる必要がある。

Pythonでもあるzipって関数がList::MoreUtilsにあったり、after { $_ > $treshold } @arrみたいなのもあって便利。

というわけで普段の暮らしでは、これらを両方使っていくという感じなんですが、List::UtilにあってList::MoreUtilsにないもの、List::MoreUtilsにあってList::Utilにないもの、両方にあるものがあってどっちがどっちだっけとuseを書くときに毎回perldocで調べていました。

毎回調べるのはなんだか無駄だなと思っていたある日のこと。

suzuri.jp

インターネットにこれが流れてきて、なるほどこれはコードの主義主張ですが、もしかしたらチートシートをTシャツにするといちいち調べなくてもいいかもと思ったのでした。というわけで画像を作ってTシャツを作って人生を豊かにしましょう。

List::UtilとList::MoreUtilsの差分を知る

両者はコードを読むとExporterを使って関数を外から使えるようにしていて、@EXPORT_OKに入っているのでこんな感じでワンライナーで生成してみる。

$ diff -u <(perl -MList::Util -E '$"="\n";say "@List::Util::EXPORT_OK";' | sort) <(perl -MList::MoreUtils -E '$"="\n";say "@List::MoreUtils::EXPORT_OK";' | sort)

これでdiffが出る。ちなみにList::MoreUtilsは_XScompiledってやつも出てくるが、これは実際に使える関数ではないので、取り除く。

画像を作る

このままImagerモジュールなどを使って生成したらPerl Hackerっぽいなと思ったけれども、僕はプロプライエタリ野郎なのでAdobe Colorでいい感じの配色を探しつつAffinity Designerで作る。

何がどっちにあるかいつも忘れるので表にした pic.twitter.com/aeuuBiY3z1

— 構造体移し替え業 (@mackee_w) 2021年3月27日

背中はこんな感じにしようと思った。どちらかというと背中の方がわかりやすい。

こっち https://t.co/tFdfkgrYaR よりも実用的な方 pic.twitter.com/JM41aUAN33

— 構造体移し替え業 (@mackee_w) 2021年3月27日

ちなみにこんな感じでレイヤーで分けている。

Tシャツにする

Tシャツは上記ツイートと同じsuzuriで作った。

suzuri.jp

パーカーも作った。

suzuri.jp

ただ、思ったのはこれを着てどっちがどっちかわからなくなって見ようと思った時に、自分の胸からお腹を見ると逆になっているので見づらいと思う。なので、同僚などに自分を見てもらって、どっちがどっちか教えてもらおうと思う。

左手キーボードPulsar(Rev.2)が #remap に対応してキーマップ変更もお手軽になりました

はい、自キ業は最近ご無沙汰してます、macopyです。在庫切らしていてすみません。近況としては現在仕事で使っているキーボードはkeyboardio atreusにhako clearを組み合わせてます。

本題としては以前販売していた左手キーボードPulsarですが、11キー版のRev.2に関してRemapに対応したのでお知らせします。

Remapとは

remap-keys.app

Remapとは特別なソフトウェア無しで、キーボードのキーマップを変更できるソフトウェアです。つい最近リリースされたChrome 89の機能であるWebHIDを用いています。

使用できるブラウザが限定されるとは言え、qmk firmwareに対する知識がある程度必要なファームウェア書き換えによるキーマップ変更と比べてかなりお手軽です。

Pulsarで使用するには

Pulsarで使用するには、Remap(およびVIA)に対応したファームウェアを書き込む必要があります。以下のページにビルドしたhexファイルを置きましたので、QMK Toolbox等で、Pulsarに書き込んでください。ちなみにPulsarのファームウェア書き込み時のリセット方法ですが、レバースイッチ押し込み+USBコネクタを上にしたときに右上のキーを押します。

github.com

このファームウェアが書き込まれた状態のPulsarをPCにつなぎ、Chrome89でRemapを開きます。その後、START REMAP FOR YOUR KEYBOARDを押して、+KEYBOARDをクリックし、現れたダイアログ内のpulsarを選択すると、以下の画面になります。

ここからキーマップの変更が出来ます。接続の方法がうまくわからなかったり、これ以降の詳しい設定方法については、サリチル酸さんが解説している以下の記事がわかりやすいです。

salicylic-acid3.hatenablog.com

Remapでできること

PulsarとRemapの組み合わせでは以下のことができることを確認しています。

• キースイッチおよびレバースイッチに対する記号や数字、文字、メタキーなどの基本的な設定
• フルカラーLEDバックライトの設定変更
• レイヤー変更

ただし、以下の設定変更は出来ません。従来どおり直接ファームウェアの変更が必要です。

• ロータリーエンコーダーの設定変更
• TapDanceを用いる設定変更

以上は私の身の回りの人が使っている機能のうち現在使用できない物をあげました。qmk firmwareの機能は豊富なのでRemapおよびVIAで使えないものも中にはあるようです。とはいえ、Pulsarのファームウェア側でなんとかすればできそうな気はするので、要望が多ければこれらの対応も挑戦してみようと思います。

Remap上のキー配置について

上の画像から見えるように、私のJSONの書き方がまずいのか、レバースイッチ部のキーが変な位置にあります。VIA Config上では以下のようにうまく表示されるのですが、VIA Config上で試行錯誤しながら角度をいじっているので、Remapでうまく表示できていない可能性があります。こちらは今後も私が原因を調べてみて、JSONを修正するかRemapに対してissueを上げるなどの対処をしていきます。

まとめ

• Pulsar Rev2がRemapに対応し、ブラウザからキーマップ変更ができるようになりました
• 一部使えない機能がありますが、ソフトを使いながらキーマップをリアルタイムに変更できるなど、試行錯誤にぴったりなのでぜひ使ってみてください

おまけ: 今後のPulsarの販売について

Pulsarの販売についてときどき聞かれることがあるのですが、正直言うと私のやる気次第という感じになっています...。というのも、PulsarはRev1/Rev2どちらも中国でPCBAを行うキットではありますが、OLED用ピンヘッダ(Rev1)やType-Cコネクタおよびレバースイッチ(Rev2)など、私が手半田をしなければ完成できない商品だったので、私の時間を奪っている状態で製造していたのが問題でした。

次に製造するときは、これらのはんだ付けもPCBAを行おうと思っているのですが、なかなか条件に合うやり方が見つけられてないのが現状です。なのでしばらくお待ち下さい。

#japanpm Japan.pm 2021でhotwireをMojoliciousから使うLTをしてきました

久しぶりに勉強会発表して緊張したなということで。

yapcjapan.connpass.com

これに参加&LTしてきました。

参加の感想

• 型や(静的|動的)解析に関連する話が多く、Perl型マニアとしてはとても満足するトークばかりでした。

scrapbox.io

Perlでも関数の型をチェックしたい - Speaker Deck

scrapbox.io

• データ解析ツールを作った話やAWS CDKの解説、InnoDBクラスタの仕組みなど、実世界に寄った話も盛り上がり、裏トークも合わせて聞くと深く知見を得られた気がしてよかったです

• オフラインにあって、オンラインカンファレンスではなかなか成立しにくいものとして、セッションの間の時間での廊下での交流や、会の後の懇親会がありますが、それに似たような体験を得るために会の後に、交流会と称してDiscord内にボイスチャットグループを話題別にたくさんつくって解決していて、かなり面白かったです

• 交流会に「型」と名付けられたルームがあったので思い切って飛び込んでみたのですが、型や静的解析関連の登壇をされた方や興味がある人でPerlの型チェックにまつわる悩みトークが出来てよかったです。

blog.sushi.money

型チャンネルの話題は参加されていたid:hitode909さんの記事のも言及があります。

発表

speakerdeck.com

Mojoliciousでhotwireを使うトークをしました。というかhotwireっていうのがあって、それがこう言う事ができて、しかもフレームワーク依存はないですみたいなのを伝えたかった感じです。

スライド中のコードはこちらに上げています。動かす手順なども書いたので、興味がある方はぜひ。

sandbox/turbo/example1 at master · mackee/sandbox · GitHub

個人的な反省

• 速く終わりすぎた。多分速く終わりすぎていたと思う(計測していない)
  • 手元にストップウォッチを置くの忘れていた
  • 通しの練習が不足していた
  • このへんは終わらないので事前に説明を飛ばすと決めていたところを予定通り飛ばしたが、時間を手元に用意しておけば飛ばさない判断もできていたと思う
• hotwire/turboがなんであるか(そもそもJSのライブラリであるよとか)そういう前提の話をすっ飛ばしてしまったなと、スライド見返していて思った
  • 20分40分のトークだと、この辺の前提条件の共有みたいなのを、僕はかなり念入りにやるのだが。というのもWebエンジニアのカンファレンスでハードウェアの話をするなど聴者の専門分野と違う話をすることが多いので。ただ久しぶり&LTというのもありすっぽ抜けていた
• 今回は高度な話題はなくして中級者レベルの話題を目指したが、そういう人たちにとって重要な「これをやって何が嬉しいか」みたいな部分の説明が不足していた
• HTMLぶん投げて書き換えているみたいな当たりの面白さの説明は、「面白さが分かる人向け」なので果たして入れるべきかどうか、しかし演者が面白いと思うことをいうのが重要だなとは思う

hotwireについての感想

主にフロントエンドエンジニアやサーバ含めて全部やるエンジニアからhotwireという技術が広まることについての懸念がインターネット上で話されている。というのも、turboやstimulusという技術は現在のWebフロントエンド技術スタックからは連続していない技術であり、どちらかといえばRails/Django/Laravel的なHTTPリクエストを受けるとレスポンスとしてHTMLを返す技術の延長線上に存在しているものだからだと思う。これらは技術の相互運用が難しい。turboの前身であるturbolinksでも同種のハレーションが起こっていた。その時の記憶を思い出す人も多いのだと思う。

昨今のいわゆる"モダン"と呼ばれるWeb開発の環境は、JavaScriptによって駆動するブラウザ上で動くGUIアプリケーションに対して、サーバはHTMLではなくJSONやその他シリアライズフォーマットで返すものが指すものが多い。僕も仕事ではそういう環境でAPIサーバを書いている。もっというとBFFと呼ばれるアーキテクチャを採用すると、フロントエンドリソースの配信やキャッシュ、複数のAPIサーバからのレスポンスを集約するなど、フロントエンドのためにサーバサイドでしかかつて出来なかったことを、フロントエンド技術の延長線上で行うことが提唱されている。ここまでくると、サーバサイドとしてはWebアプリケーションを書いていると言うより、domain specificなデータベースのプログラムを書いている感覚に近くなってくる。そして、APIをしゃべる汎用的なデータベースでよいのであれば、そもそもmBaaSでよいということになり、FirebaseやAppSyncといったサービス、GraphQLとhasuraのようなAPIサーバを構築してくれる技術などが発達していく。

おそらく、僕の予測では、この流れは一般的な消費者がアクセスするようなWebサービスでは止まらないと思う。一方で、そこまでみんなGUI書くのが好きかと言われたらそうではないし、限られた組織向けのWebアプリケーションに、ユーザ体験が良くすることが得意なフロントエンドエンジニアを充てられるかどうかと言えば、今はノーであるという現場が多いのではないのだろうか。ここで指している"限られた組織向けのWebアプリケーション"というのは、社内向け管理画面だとか、勤怠管理システムだとか、在庫管理システムだとか、一般のお客さんからは見えないところで動いているサービスのことを指している。

とはいえ、体験が悪い勤怠管理システムに悩まされている業界の人は結構いるようで、僕もかつてはその一人であったけれども、やはり優れたGUIというのは充てられる人がいるいないに限らず、必要なものだと思う。しかし、優れたデータベースを作れる人が必ずしも優れたGUIを作れるかと言われたらそうではないし、いても超人の類なので、片手間でも優れたGUIを作れる機構というのは、選択肢として悪くないと思う。優れたGUIを作るのには技術だけではなく、作ろうとするシステムに対する深い理解も必要だし、他の例を引用するなどの労力も必要である。現代のフロントエンドスタックは 、それらとデータベースの操作をきちんとやる作業の片手間にやれるほど、お手軽ではないと僕は感じている。なので、hotwireを管理画面に採用するのを同僚に提案してみようと思う。フロントエンドの人には、僕ら以外の一般ユーザの体験を向上するのに注力したほうがビジネス的には正解だと思うからだ。

ただ、hotwireを剥がして一般的なフロントエンドスタックに載せ替えますといったときに、フロントエンドエンジニアの呪詛が激しいと思われるので、採用するなら採用したときのメンバーで閉じて作り続けていく覚悟が必要なんだと思う。ただ、turboを剥がしても普通のMPAとして作動するように作れとドキュメントにも書いてあるので、turbo特有の挙動に頼ったUIを作らなければ、そこまで移行は難しくない、そもそもMPAのアプリケーションをSPAにするのと同じぐらいの労力にとどまるのでは、とは思う。ただ、MPA -> SPAも難しく、というか静的なドキュメントをGUIアプリケーションという別物に作り変えるようなものなので、そもそもページの再設計が必要。

turboをMojoで使うときに困ったときのtips集

onchange=this.form.submit()でfetch requestが発火しない

this.form.submit()をすると、普通のHTMLであれば、submit buttonが押されたのと同じ動作、つまりフォーム送信が行われる。しかし、turboが導入された環境だとsubmit buttonが押されたらページ遷移せずにfetchが使われてリクエストし、レスポンスに応じてturbo driveやturbo framesによるDOM要素の書き換えが行われる。

ただ、今回のデモアプリで示した、トグル状態が変更したら送信するようなときに、素のJSだとタグ内にonchange="this.form.submit()"と書いてしまうのがお手軽だが、これだとturboの環境でもフォーム送信&ページ遷移が行われてしまう。

ググったところ以下のフォーラムのスレッドが見つかり、このスレッドではstimulusでrequestSubmit()というメソッドを呼び出していたが、普通に書いても使えそうだったので、onchange="this.form.requestSubmit()"と書いたところ、ちゃんとfetchのほうが発火したので、そのようにした。しかし今書いてて思ったのだが、turbo無し環境だとこれ動くのか？と思った。

Triggering Turbo Frame with JS - #23 by walterdavis - Hotwire Discussion

turbo streamsでメッセージを投げつけるときの形式

どうやるんやろと思って、turbo-rails gemを呼んでみたのだが、railsにはそんなに詳しくなくて、ぼんやりしかわからなかったので、とりあえず分かる言語でまず調べるか思ったところ、以下のGoでturbo streamsを使う記事が出てきた。

Turbo Streams powered by Go WebSockets - DEV Community

この記事で上げているリポジトリには、

{ 
  "identifier": 
     "{\"channel\":\"Turbo::StreamsChannel\",  \"signed_stream_name\":\"**mysignature**\"}",
  "message":
    "<turbo-stream action='append' target='board'>
    <template>
        <p>My new Message</p>
    </template>
     </turbo-stream>"
}

という形でWebSocketにメッセージを流しているっぽいので、これをそのまま採用したところちゃんと動作したのでそのまま採用している。しかし、messageキーの部分はわかるが、identifierの部分は何なのかわかってない。ActionCableとかそっち方面由来なんですかね？消しても動くのではと密かに思っている。

...

思ってるんなら試せばええやんと思って試したところ、普通に動いたので、message部だけで良さそう。

件のリポジトリのHTMLにはこういう記述もあって、

<!--
  <turbo-cable-stream-source 
    channel="Turbo::StreamsChannel" 
    signed-stream-name="**mysignature**"
    >
  </turbo-cable-stream-source>
-->

たぶんチャンネルとかシグネチャを設定できるんだと思う。これに対応するturbo-rails gemの実装はここだと思う。

turbo-rails/cable_stream_source_element.js at main · hotwired/turbo-rails · GitHub

これ、turboじゃなくてturbo-railsの方なので、turbo単体で動くのか？という気持ちがある。過去のバージョンだと動いていたのかもしれない。

turbo-streamsのmessageの文字化けだとかタグがエスケープされる

どちらかというとPerlあるあるなんだけれども、utf8フラグがあべこべの状態でながすとどうこうというやつである。最終的には、

my $rendered = $c->render_to_string(template => "append_messages");
$connection->send(decode_utf8(encode_json({
    identifier => encode_json({ channel => "Turbo::StreamsChannel", signed_stream_name => "**mysignature**" }),
    message    => $rendered->to_string =~ s/\n//gr,
})));

こんな感じのへんてこりんになってしまった。この中には様々なトラブルシューティングの跡が詰まっている。

まず、MojoのWebSocketの接続オブジェクト(ここでいう$connection)は、Mojo::Transaction::WebSocketなのだが、これにもちゃんとJSONエンコード機能はついている。それを使うと上のコードはこのようになる。

$connection->send({ json => {
    identifier => encode_json({ channel => "Turbo::StreamsChannel", signed_stream_name => "**mysignature**" }),
    message    => $rendered,
}});

render_to_string使ってレンダリングしたやつも、to_stringと言いながら実はMojo::ByteStreamというオブジェクトなので、そのままJSON::XS::encode_jsonに突っ込んでも、シリアライズ出来ませんと怒ってくる。しかし、$connection->sendの機能でJSONエンコードした場合は、Mojo::JSONが使われるので、こいつはMojo::ByteStreamを食べられるので、そのままエンコード可能だ。

しかし、Mojo::JSONには普段は有用だがこの場合にはおせっかいな機能があり、

ドキュメントの記述なのだが、つまりXSS対策のためにHTMLタグをエスケープする。しかし、今回は実際にレンダリングするためのHTMLを送っているので、エスケープはされてほしくない。というわけで、Mojo::JSONを使わずにJSON::XSを使っている。

それから、s/\n//grとしているのは、改行コードが入っているとそれがそのまま\nと表示されてしまうからである。これ思ったが、turbo-rails側はどうしているか見に行けばよかったなと思った。この記事も長くなってきたので、今は調べないが、ちゃんとした解決方法を教えてほしい。

あとは、全体をdecode_utf8することである。JSON::XSにもutf8フラグを立てたり立てなかったりする機能があるのだが、それだとうまくいかなかった。なんでこれでうまくいって、JSON::XSでうまくいかないかは分かっていない。こんなのでPerlで仕事している。仕事でもあまり深く考えずにdecode_utf8 encode_utf8を試して文字化けしなかったら採用みたいなことをやっている。utf8フラグがどうのこうのあるが、こういうのは変数を受ける側がどう言う状態を想定しているかで挙動が違うので、知識よりはライブラリ側のコード読むか実際に試したほうが良いみたいな悪い学習をしている。

WebSocketのコネクション維持と再接続

turbo側が切っているのか、それともMojo側が切っているのかは知らないが、Webインスペクタを眺めていると素のnew WebSocketだと無通信が30秒で切れるような挙動を起こしていた。このへんは昔にWebSocket接続管理ミドルウェアを作ったときの知識から引用して、5秒おきにping messageを投げるようにした。そうすると切れなくなった。人生そういうものである。

my $id;
$id = Mojo::IOLoop->recurring(5 => sub ($loop) {
    if (!defined $c->tx || $c->tx->is_finished) {
        $loop->remove($id);
        return;
    }
    $c->send([1, 0, 0, 0, WS_PING, 'Hello World!']);
});

このとき、接続が切れている(is_finished)などのケースでは、繰り返しのタイマーを削除するなどしている。ちなみにMojoはイベントドリブンで動くので、こう言う芸当が可能なのである。ノリもJavaScriptに近い。

しかし、それでもアプリケーション再起動とかのときに接続が切れて切れっぱなしで不便というのもあったので、ReconnectiongWebSocketを使っている。これと同名でおそらく機能が同じのライブラリもあり、こちらはメンテされている雰囲気でなんだかモダンだし、普通ならこっちを選ぶんだが、cdnjsから配信されているからという理由で、前者を選択した。とにかくJavaScriptのビルド環境を用意したくないという気持ちが全面に現れている。

まとめ

Japan.pmまたやってほしい。というか** Weekly Talksみたいな感じで、週1とにかく集まるみたいなのもありでは無いか。それほど技術的な雑談に飢えている。特に会社外の人の意見を吸いたい。

あと技術は触ってみると印象が変わることがあるぞい

Backends for Frontendsはあるが、Frontends for Backendsはなぜ無いのか

この記事では僕の以下の疑問について書き出して、思索し、議論を喚起するものであり、何らかの答えが書かれているものではありません。

Webフロントエンドエンジニアに向けたバックエンドサーバーを構築する仕組みは様々提案されているものの、その逆であるバックエンドエンジニアに向けたフロントエンドを構築する仕組みがあまり提案されていない

この記事を書くきっかけ

以下の記事を読んで、フロントエンドの技術スタック内でサーバサイドアプリケーションの一部の責務を負うような動きがどんどん加速している現状であるが、我々バックエンドエンジニアはどういう動きをすればいいか考えている。

zenn.dev

zenn.dev

筆者の立場

• 自社開発のWebサービスのバックエンドアプリケーション開発を担当している
• 現代フロントエンドに関しては、社内ツール程度はNuxt.jsを用いて書いたことがある。2C向けのプロダクションコードではデバッグ目的でTypeScriptを読む程度
• 関心があるのは効率かつユーザのニーズを満たせる永続的データ構造とそれをうまく扱えるバックエンドアプリケーションの設計

なぜBackends for Frontendsと分かれているのか。

日本のほとんどのWeb開発現場においてはフロントエンドエンジニアとバックエンドエンジニアという2つの職能が並立して存在していると、僕の観測範囲では思う。しかし割り当てられたロールのラベルがそうなっているだけで、用いる技術はかぶっているケースもある。

現代の一般的なWebアプリケーションの構成は以下のようになっていると想定している。

これはかなり簡略化した形であり、例えばほとんどのサーバサイドWebアプリケーションにはログ集計解析基盤もあるし、フロントエンドスタックにSentryなどを用いたエラー監視スタックが含まれていることもあると思う。また、僕はフロントエンドエンジニアの仕事をすることはあまりないので、どうしても解像度に偏りが出てしまう。あくまでも、同僚がやっていることを外から観測するとこういう形で触っていることが分かれているようだ。さらにいうと僕が関わっているWebサービスはSPAとサーバサイドテンプレートレンダリングを併用しているものの、フロントエンドスタックでのSSRは採用していない。

そして職能ごとの責務はこのように分かれている。

ブラウザからこっちと、ブラウザがネットワークを通して向こう側に分かれている。ただし、フロントエンドスタックのビルドを通してキャッシュ制御を行っている領域もあるし、HTMLテンプレートはUIにも関わってくるため、フロントエンドエンジニアが担当している。というわけで赤字にしておいた。

つまるところ、「あなたはここまで」「わたしたちはここからここまでやる」と壁ができている。そのほうが専門性が深まり、効率が高くなるからだ。でももっと細かく分けることも出来る。実際、我々のチームは社内の他のプロジェクトではSREチームと呼ばれる部署が担当している部分もサーバサイドエンジニアが行っている。インフラ構築であったり、監視の部分だ。でもこれは切り出す事例が世の中にはたくさんある。更にいうと、データベースの管理はDBAという職能の方が専門的にやっているケースも世の中にはある。やろうと思えば無限に分割できるし、やろうと思えば全部やれる。全部やっている例が、世間ではフルスタックエンジニアと呼ばれること僕は理解している。

また、昨今ではこれらの一部をSaaSやPaaSに任せる例もある。僕のWebサービスはAWS上に構築され、メインのDBはAmazon Auroraを用いていることから、DBAおよびSREの一部の役割をAWSにやってもらっていると考えられる。アプリケーションによっては、FirebaseやVercelなどを用いると、CDNから先の向こうをほぼ全てサービス側にやってもらうことも可能である。

フロントエンド技術がバックエンドへ揺り戻しされる対する考察

じゃあなぜ全部やらないのか。それはそれぞれの技術スタックが複雑になり難易度が上がってきたからだ。僕の記憶では2010年以前のWeb開発においてはフロントエンドエンジニアと呼ばれず、マークアップと言う仕事として、現在のサーバサイドエンジニアが片手間にHTMLとCSSを書いたり、現在のデザイナーがこれらを書いていたと思う。しかし、Webが単なるページから動的なアプリケーションに進化し、HTMLがドキュメントを表現するための記法から、UIを記述するための基盤として利用されるようになった。そのため、より多くの技術の理解が求められて、マークアップ周辺の仕事はフロントエンドエンジニアという職能に切り出されてきた。同じ現象は、サーバサイドエンジニアからSREという職能が切り出されたのにも似ている。

一人で担当できないぐらい、技術が発展したから複数人で切り分けて担当するようになった。では、なぜフロントエンドエンジニアがわざわざ現状切り分けられているバックエンドの領域に足を踏み入れようとしているのか。それは2つの理由があると思っている

フロントエンドエンジニアが達成したい目的がフロントエンドのスタック内では収まりきらなくなった

Server Side Renderingという技術は、ブラウザサイドでのJavaScriptの実行では実現できなかったことをサーバサイドで実行することで解消する。アクセス一発目のレンダリングスピードを高めるためにサーバサイドリソースを使ったり、CDNキャッシュを利かして解決する。また、JavaScriptを解釈しないクローラに対しても有効に働く。しかし、本来はブラウザ向けに書かれたコードをサーバで実行するには制限が多い。フロントエンド感覚でサーバサイドで動くコードを書くのは未だに難しい。

そこで、React Server ComponentはSSRが抱えていた、SPAのアクセス一発目のみにフロントエンドのコードをサーバサイドで実行するのではなく、SPAのコンポーネントを局所的に常にサーバサイドで実行したものを透過的にクライアントが取得する点で違いがあると考えている。境界を再設定することで、よりフロントエンドが主でバックエンドが従である関係を強調し、扱いやすくしている。

フロントエンドでの実行に比べて、サーバサイドでの実行はいくつかのメリットがある。ユーザのブラウザに依存しないコントローラブルな実行環境、実行内容やコードの秘匿性などだ。このへんをどう実現するかは、様々なアイディアが出てくると思われる。しかし、どうやって運用するかどうか、うまく運用するかという点についてはもう少し事例がほしいと感じる。

この辺の議論はこちらの記事にもまとめられている。

zenn.dev

◯◯エンジニアの〇〇には関心領域が込められている

じゃあみんなフロントエンジニアがフルスタックエンジニアになればいいじゃん、それが幸せと思うが、僕はそうはならないと現実的には思う。一人の人間が関心を寄せられる領域というのは思ったよりも狭い。UIを構築するためのマークアップは専門的な知識が必要だし、ビルドパイプラインにも、HTTP通信についてもそうだ。既にフロントエンドエンジニアが抱えている技術の領域は広く、そして深化していっている。

エンジニアというのはくっきりしているか、ぼんやりしているかの過多はあるものの、その仕事をするときのある程度の軸が存在すると僕は考えている。これを関心と呼ぶ。関心の周辺の領域というのは、効率よく学習でき、モチベーションもあるが、関心から遠いと効率が悪くなる。仕事上のWebサービスというのはユーザに見たり使ってもらったりして、その結果直接的・もしくは間接的にお金をもらうことを目的としているが、それはどのエンジニアであっても共通している目的だ。しかし、関心がそれぞれ違うし、それによって目的に対する手段が変わってくる。それがフロントエンドエンジニア・バックエンドエンジニアとラベリングされている物の本質である。一般的には責任の範囲とも言われるが、僕の仕事場ではあまりそれが当てはまらない。得意不得意はあるものすべての技術領域には物理的にはチーム内の人間は手を出せるので、責任範囲より関心の違いといったほうがしっくりくる。

どうしても、普段触ってる関心領域より遠い技術領域は学習の効率が悪くなってしまう。フロントエンドエンジニアで、普段はUI周りを触っているエンジニアほどバックエンド方向の技術領域は精度良く進めるのは難しい。これは世の中の情報についてもそうで、「フロントエンドエンジニア向け」「バックエンドエンジニア向け」とわかりやすいように情報が分かれている。BFFに必要とされる技術は、これまでのバックエンドの知見をかなり含んでいる。しかし、情報収集の際にフロントエンドエンジニア向けばかりの情報を読むと、理解が遠回りになってしまう可能性があるのではないか。

こういったラベリングは、主に求人上のマーケティングワードや、働く人のコンフォートゾーンとしても機能していたが、それが実態を表さなくなってくると思われる。実態が先か、言葉が変わったり、新しい言葉が生まれるのが先か、それちょっと予想がつかない。

バックエンド側からのアプローチがもっとあってもよいのではないか

Backends for Frontendsがフロントエンドの人が使いやすいように、バックエンドの仕組みをフロントエンドの技術スタックで構築したり、理解しやすいように抽象化するという目的もBFFにはあると思われる。では、バックエンドの技術スタックでフロントエンドを構成するアプローチは考えられるのか。

RailsのHotwireやPhenixのLiveView等が挙げられる。これらはSPAをトラディショナルなテンプレートレンダリングを行うフレームワークで作ることに対する回答だと見ている。また、vuguという、Goのフロントエンドライブラリがある。GoでVueライクなコンポーネントを書いて、wasmで実行するものである。本来、ブラウザ向けの技術スタックがNode.jsを介して動いてBFFを構成するように、バックエンド向けの技術スタックがフロントエンドで動く一例だと思う。

また、そもそもバックエンドだけ書いて、フロントエンドの記述を最小限に抑えるアプローチもあるのではないか。バックエンドアプリケーションの記述を最小限にするために、BaaSやサーバレス環境を用いる手法に対するアプローチである。これが僕が捉える、Frontends for Backendsであると感じる。実際この記事でいいたいのはここだけです。

僕は仕事では、GraphQLをしゃべるサーバを書いている。ここで思うのは、GraphQLさえ吐いて、あとは汎用的なコンポーネントを配置すればWebアプリケーションが作れたらいいのになと思う。例えば、管理画面のような独自のデザインやブランディングが必要ない場面ではbootstrapのようなコンポーネントとGraphQLのクエリを紐付けることさえすれば、そういったSPAが構成できるのではないか。React Adminがかなりこれに近いが、それにしてもReactやJavaScriptツールチェインの知識が多少必要である。

管理画面向けで言うと、Vironがある。VironはSwaggerを元にしたAPIサーバを書けばUI側を自動構成できるフレームワークである。こういったものをフロントエンドエンジニアの人はどう考えているかを知りたい。

github.com

しかし、一定の管理画面ではこれらは成立するだろうけれども、現代はSPAは、独特のコンポーネントのライフサイクルが存在する。これを、自動生成のツールだけで実現できるかは僕はわかっていない。また、多くの人が使うWebアプリケーションだと、出来合いのコンポーネントでは実現できないようなUIやインタラクションも存在すると思う。そういうのを人手を介さずに生成するには難しい。そこまで来るとノーコード, ローコードの領域に入ってくる。

というか僕がここまで言っているのは、得意なこと/力を入れたいこと以外はノーコード, ローコードで解決したいという話に近くなってくる。SaaSを活用してWebサービスを作ることもそうだし、サーバレスも、実際はサーバ運用レスであることもその証左だと思う。

僕は、バックエンドが得意だ。だからフロントエンドは楽して書きたい。そもそもフロントエンドがないとCLIのアプリケーションしか作れないからだ。

まとめ: とはいえ結局全部やることになる

もともとは一つの職能であった、Webエンジニアが技術の発展に伴って複雑化し、分業化されていったことを話した。しかし、それがBackends for Frontendsに代表されるような、それぞれ分割統治されていた技術領域だけで解決できなくなり、他方の領域の一部を担当するような現象が起こっていることを話した。

最終的には、全部やる人と、一部を深くやる人に分かれていくのではと予想している。実際にはクラウドコンピューティングという領域ではそれが起こったのだ。かつて、インフラエンジニアというデータセンターのサーバラックを管理したり、調達するような職能の人は会社内にいたり、委託されてそれをやる専門業者がいた。そういう仕事のやり方もまだ残って入るものの、AWSに代表されるクラウド事業者を用いてサービスを構成する際には、インフラエンジニアはクラウド事業者内で深く作る人と、クラウド事業者が提供するサービスを構成して組み合わせて使う人に分かれた。それでより高度に、より堅牢なサービスを作れるようになった。

フロントエンド・バックエンドにもそういう変化が起き、あるコンポーネントを深く作る人と、それを組み合わせる人に分かれていく。そうすることで、必要な知識を分担することが出来、さらに高度なWebサービスが作れるようになる。ただ、それどういう職業であると求人市場で言うか、どういった給与体系/雇用体系、サービス体系なのか。まだ僕にはわかっていない。