2022年の技術トピックをふりかえる

それはベンツなんよ

総括

今年はコードをよく読むようにした。

技術的にはひき続きPaaSやクロスプラットフォームの動向に注目した。

デファクトの移り変わりを感じるので来年以降はGoやGraphQLに手を出していきたい。

去年のエントリ: 2021年に作ったモノや技術をふりかえる

今年やったこと

コード読み

去年はコードを書くことに注力していたので今年は一転コードを読んでいた。

プログラム雑談ポッドキャストを聞いていて「コード読み」っていう言葉がよく出てくるので聞きながらそういえば自分もこの分野が好きだなと思い出したので意識してやることにした。

丁度、最新技術のトレンドだけ俯瞰しているのに学びを感じなくなってきたのでより潜りたい気持ちがあったのでそれを満せたと思う。

IntelliJ IDEAで全言語のプログラミング環境が楽に揃っているのが心強い(Samuraismさんありがとう)。

読んだ成果はメモして主にzennに投稿している。

zenn.dev

ソースコードを読んでると「これってどうやるんだろう?」という時の具体的な語彙が増えていくのでリポジトリを検索してGitHub IssuesやDiscussionsに辿り付くことが多くなった。

そういう時に特定のGitHub Issues単位で更新を購読しておくと、コメントが付いた時にメールを受信するので、新機能の実装などの時にリリースされる前に一早く気付いてテストすることができるようになった。

最初にテストするので問題の発見も早くなるし、開発したばかりなので開発者が議論に参加している可能性も高くて良い。

Platform as a Service(PaaS)

Vercel Build Output

mozaic.fm(ep110 Yearly Ecosystem 2022)でも同じ話があったけど今年はPaaS各社が次々に独自のNext.jsアプリケーションのホスティングに対応しはじめた。

zenn.dev

zenn.dev

zenn.dev

これを実現しているのがVercelのBuild Output API (v3)で、どういうことかというとBuild Output APIでNext.jsのウェブアプリケーションをVercelにデプロイする時の中間ファイル形式が定まって公開されたので、それに従って各社が変換されたファイルをデプロイして動くように接続するっていうことがやりやすくなった。ということだと思う。

これはNext.jsに限ったことではなく、Nuxtでも応用されてVercel上でISRが動くような計画がされていた。

zenn.dev

さらにこの仕組みはVercelの中でホストされているAWS Lambdaを経由したランタイムのハックにも使うことができて、自分はSwiftやRailsを動かして遊んでいた(今ならWasmのがいいかも)

zenn.dev

zenn.dev

(ちなみに遊び過ぎてまたBANされてる)

Cloudflare Workers

2022年はCloudflare Workers周りに怒涛のアップデートがあって連日ひくぐらい新機能が発表されていた。

VercelがフロントエンドのAWSとたまに言われていたりするがCloudflareは直球にAWSと同じ領域にサービスをどんどん展開してきている。

サービスの中核にあるのはService bindingsというやつで、これを使っていい感じにサーバレスアーキテクチャやってくれということらしい。

zenn.dev

直近の関心事としてはtcpクライアントのAPIで、これがあるとHTTP経由でDBを呼び出すしかなかった部分がネイティブドライバーやORMを使えるように変わるので注目している。

zenn.dev

一方Deno Deployは既にTCPアウトバウンドに対応しているらしい(?)

deno.com

ただORMのPrismaはネイティブドライバーにはまだ対応していなかった。

zenn.dev

Web Standard APIs

Cloudflare WorkersやFastly Compute@EdgeのようにブラウザのWeb Standard APIsに近い環境のJavaScript実行環境を提供するPaaSがいくつか出てきて、それらはCDNのEdgeサーバーで動かすことを想定されているんだけど、ここでアプリケーションも動かしてしまう。という方向に発展してきた。

laiso.hatenablog.com

Deno DeployやバックエンドがCloudflare WorkersらしいVercelのEdge Functionsのこのカテゴリに入れていいかもしれない。

これからコンテナ仮想化技術になぞらえてJavaScript Containersと呼んでいくらしい。

laiso.hatenablog.jp

今まで「重い処理やライブラリをNode.jsのSSR側に逃がしてフロントエンドを高速化」という発想でいたので、逆にサーバー側も切り詰めないといけなくなって最初は戸惑った。

この流れにうまく乗ってWeb APIsファーストなアプリケーションフレームワークにしたのがRemixHonoでどんどん勢力を延していっている。

laiso.hatenablog.jp

BunではWeb Standardが使えるが、 逆に言えば、それら以外にWebアプリを作る手段がない。 つまり、Expressが動かないのだ。 これが重要なキーになる。 https://yusukebe.com/posts/2022/how-i-got-2k-stars/

初期のGoogle App Engineの時のように、一見不自由に制限された環境の中で新しいものができていく感じがわくわくする。

Bunについては気になったのでコミットログからソースコードを読んでいた。最初の方のドキュメントにはesbuildをzigで書き直すプロジェクトだったということが書かれていた。

自分はなんでここからNext.jsのサーバーが立ち上がるんだ、という部分が気になったので以下を調べていた。

zenn.dev

安データベースを求めて

昨年と同様に最小限のFirestoreとAlgoliaを使ってFirebaseは難しいと思いながらツール開発をしていたが、個人開発のコストはDB次第を投稿してからはSQLite系の活用に関心を持った。

LitestreamをCloud RunやVPSで動かしてみたり。fly.ioのディスク上やCloud Storage FUSEに直接置いてみたり。

辿りついた先が発展的バージョンのLiteFSで、これからはLiteFSを中心にバックエンドを開発していこうかなーと計画している。

zenn.dev

zenn.dev

その他にはAlgoliaのかわりにGoogle Driveを使って全文検索する仕組みを構築してる。

zenn.dev

ただ同時に、安さを求めて調査のためにクラウドサービスにバンバン課金しているので本末転倒感はある。

クロスプラットフォームなアプリケーションフレームワーク

ハイブリッド(WebView)アプリのアーキテクチャを考えていて、Ionic Portalを見つけたのであらためてハイブリッドアプリの意義を考えていた。

laiso.hatenablog.com

その結果一番必要なのはネィティブアプリのオンラインアップデートだなと思ったのでローカルWebViweアプリであるIonic Portalは使わなかった。

今のところオンラインアップデートを第一に考えるならExpoのEAS Updateに乗るのがベターそうではある。

WebView関連ではTauriのモバイル対応にも注目した。Tauri on mobile 現状確認会時点では本当に実現できるか怪しいと思っていたが半年後に完成させてきて驚いた。

zenn.dev

一方Hotwire Stradaはあれから音沙汰がない。こっちはこっちで厳しそうだがHEY Emailアプリは順調にアップデートしているしいつかリリースされるのかも。

laiso.hatenablog.com

新世代MPAs(Multiple-page applications)

AstroQwikのこと。

最初にIsland Architectureというキーワードを知ってそこから今までとは違う文脈でMPAが使われだしていたので気になって調べていた。

前MPAsは「SPAじゃないもの=PHPRailsのテンプレートエンジンを使ってサーバー側でHTMLを描画するもの」という意味で読んでいたがどうやらSPA→SSR→SSG→Jamstack→MPAと合流してきたらしい。

つまりSPAのJavaScriptアプリケーションをページごとに分解して生成、動的なCSRをIsland ArchitectureのようなHydrationが別途加わるので完全な静的サイトではなく動的なアプリケーションにもなる。

しかしこういうHydration戦略の他にもReactのSSR StreamingがありNext.jsのRSCがあり、HydrogenLiveViewシリーズやBlazorのようなWasmナニカを含めたら画面を作る技術の大渋滞がすごい・・

しかもWebフロントエンドのアーキテクチャって最近はどんどんモバイルアプリ系にも影響を与えてくるのが常なので、そのうちServer-Driven UIのようなシステムと合体してモバイルアプリもストリーミングレスポンスで画面全体を組み立てるようなアーキテクチャが普通になったりして……

PHPエンジニア業

閑話休題、趣味開発で最新技術がたくさん出てくるのは普段の仕事で使っているのが退屈な技術が中心であることの反動というのがあって、退屈な技術というのは悪い意味でもなくてBoring Technologyエッセイに出てくるような意味で、要は技術の種類より重視する問題があるということ(人手不足、とか)。フレームワーク乗り換える必要なしの考えにも通ずる。

boringtechnology.club

で退屈な技術筆頭であるLaravelアプリケーションを今年も書いていた。

今年は一緒に開発していたチームメイトがユニットテストのDB接続を全部スタブ定義するタイプのエンジニアで、Mocks Aren't Stubsなどを上げつつ改宗を促していたんだけど、まぁ自分の方が間違っている可能性もあるよな〜と思いしばらくモック多用スタイルで書いていた。

1年書いた感想としては、やはりモック多用は私たちに向いていなかったと思う。なぜならスクラッチからプロトタイピングしながら開発しているプロジェクトなので常にカバレッジが低くて、そこにモックによってテスト対象の粒度が細かくなったことによってモックテストを書いてあるが結合した結果は検証できてなくて、テストはパスするが動かないという場面によく立ち合って直していた。

モックは控えめに。

システムエンジニア

PHPエンジニア業の傍ら今年はよく要件定義や基本設計だけやって後は開発ラインに流すためにドキュメント書く、みたいな言わゆるSWEじゃなくてシステムエンジニア(SE)っぽいこともよくやっていた。

ドキュメント書いているうちに自分で実装できちゃうよな〜と思いながら形式的にこなしていたけど、なかなか思ったより難しくて苦労した。

何がそんなに難しく思うんだろうと考えていたんだけど、コードを書くことで業務知識の理解を担保していたんだなという部分だけスッポリ抜けている感じがして、あーはいはい、ここの仕様は分かりますが、よく分からん。コード読むか。みたいな虚無っぽいフローになっていた(自分でドキュメント書いてるのに)。

なのでSIerでこの辺の業務をソツなくこなせている人は優秀だったんだなという感想を持った。

シーケンス図やフローチャート書く時にMermaidを使ったがこれはVSCodeでコーディングできるのが快適だった。

laiso on Speaker Deckなどを見ても分かるとうり自分はプレゼン資料作りとか図解が苦手で、あまり満足のいくものが作れたことがない。

これは思考をテキスト=散文からスタートして、その後に構造化して、すべてが完了してから意図が伝わるよう図を付け加える。というやり方がうまくいっていない気がしていてて、最初からイメージで捉えて物事を考えたいなぁというのが現在のところ。

最近、なんでも図解という本を読んでいるんだけど、これぐらいのシンプルなルールなら真似しやすいのでやってみる。

インフラエンジニア業

ソースコードを書くなど単純な作業は外部に委託するなど柔軟な対応 をしているので、そのぶん保守系の開発やインハウスなAWSリソース管理などを重点的にやっていた。

今年の大きなテーマは2019年に構築したEKSクラスタのNodeを新バージョンに総入れ替えするついでにEC2インスタンスをEKSマネージドなNode Groupに移行するというものだったけど無事無事故で完遂できた。

最初の構築時にシステム基盤をECSかEKSかにするかをかなり迷ったけど、10個ぐらいの御互いに呼び出し合うアプリケーションを一人で管理しないといけないから、システム境界を曖昧なままにして必要であればEC2インスタンスやコンテナにシェルで入って泥くさい対応もできるようにする必要があったのでEKSにして良かった。

ただの偶然だけどJason Warnerが言ってた「まずAppsに分けろ」の方針になっていた。

来年やりたいこと

Go言語でWeb開発

「スタートアップの開発に参加するならgolang履修必須」程度に身の回りのプロジェクトで使われているぐらいに偏ってきたのでGoでひととうりのバックエンド書いて運用したい。

自分はちょうど10年前ぐらいにこの動機で片手間にRailsアプリの保守ができるようになった。

あとGraphQLも導入したい。

実践的なWebフロントエンド開発

自分は本業はテンプレートjQueryを使った管理画面エンジニアリングしかしていなく、SPA以降のアーキテクチャは趣味で書いたり学習していたりするだけなので実践的なスキルはあんまりない

Web Speed Hackathon 2022 を勝手に開催するをやっていたら専業フロントエンドエンジニアはこういう最適化をしているのね……と大変さが分かった。

これを業務でやるならもっと経験を積みたいなと思ったので来年は大きめのアプリケーションを作ってみたい。

モバイルアプリ開発の学び直し

モバイルアプリ開発はキャリアの半分をiOSエンジニアとして過ごしたので自分の中ではやればできる枠=後回しになっていたがもう数年も経つし「昔開発していたらしいマネージャー」ぐらいの感覚になっていて今の一線の開発現場に入るには学び直しが必要かなと思っている。

Androidアプリ開発も既存のソースコードちょろちょろいじるぐらいなら余裕だけど、ベストプラティクスを自分で考えたりするぐらいの余裕はない。

いい機会なのでJetpack Compose, SwiftUIの世代からまた入門したい

データ分析、統計処理、機械学習

学習意欲はあるはずがやりたいことと関心が結びつかないのであまりモチベーションが高くない状態。

数理系の基礎教養が不足していて理論に関心を持てない要因かもしれない。

最近活発なAI系サービスやツールも使ってみる、ぐらいのところから始めてみたい。