それはベンツなんよ
総括
今年はコードをよく読むようにした。
技術的にはひき続きPaaSやクロスプラットフォーム の動向に注目した。
デファクト の移り変わりを感じるので来年以降はGoやGraphQLに手を出していきたい。
去年のエントリ: 2021年に作ったモノや技術をふりかえる
今年やったこと
コード読み
去年はコードを書くことに注力していたので今年は一転コードを読んでいた。
プログラム雑談 ポッドキャスト を聞いていて「コード読み」っていう言葉がよく出てくるので聞きながらそういえば自分もこの分野が好きだなと思い出したので意識してやることにした。
丁度、最新技術のトレンドだけ俯瞰しているのに学びを感じなくなってきたのでより潜りたい気持ちがあったのでそれを満せたと思う。
IntelliJ IDEAで全言語のプログラミング環境が楽に揃っているのが心強い（Samuraismさんありがとう ）。
読んだ成果はメモして主にzennに投稿している。
zenn.dev
ソースコード を読んでると「これってどうやるんだろう?」という時の具体的な語彙が増えていくのでリポジトリ を検索してGitHub IssuesやDiscussionsに辿り付くことが多くなった。
そういう時に特定のGitHub Issues単位で更新を購読しておくと、コメントが付いた時にメールを受信するので、新機能の実装などの時にリリースされる前に一早く気付いてテストすることができるようになった。
最初にテストするので問題の発見も早くなるし、開発したばかりなので開発者が議論に参加している可能性も高くて良い。
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ファーストなアプリケーションフレームワーク にしたのがRemix とHono でどんどん勢力を延していっている。
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)
Astro やQwik のこと。
最初にIsland Architecture というキーワードを知ってそこから今までとは違う文脈でMPA が使われだしていたので気になって調べていた。
前MPAsは「SPAじゃないもの=PHP やRails のテンプレートエンジンを使ってサーバー側でHTMLを描画するもの」という意味で読んでいたがどうやらSPA→SSR →SSG→Jamstack→MPA と合流してきたらしい。
つまりSPAのJavaScript アプリケーションをページごとに分解して生成、動的なCSR をIsland ArchitectureのようなHydrationが別途加わるので完全な静的サイトではなく動的なアプリケーションにもなる。
しかしこういうHydration戦略の他にもReactのSSR StreamingがありNext.jsのRSCがあり、Hydrogen もLiveView シリーズやBlazor のようなWasmナニカを含めたら画面を作る技術の大渋滞がすごい・・
しかもWebフロントエンドのアーキテクチャ って最近はどんどんモバイルアプリ系にも影響を与えてくるのが常なので、そのうちServer-Driven UI のようなシステムと合体してモバイルアプリもストリーミングレスポンスで画面全体を組み立てるようなアーキテクチャ が普通になったりして……
閑話休題 、趣味開発で最新技術がたくさん出てくるのは普段の仕事で使っているのが退屈な技術が中心であることの反動というのがあって、退屈な技術というのは悪い意味でもなくて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系サービスやツールも使ってみる、ぐらいのところから始めてみたい。
![Galaxy Watch5 44mm/ グラファイト [by Galaxy純正 国内正規品] SM-R910NZAAXJP](https://m.media-amazon.com/images/I/31HqFYnUfwL._SL500_.jpg "Galaxy Watch5 44mm/ グラファイト [by Galaxy純正 国内正規品] SM-R910NZAAXJP")
