はてなブックマーク

株式会社スタディスト様の依頼で、フロントエンド傭兵として、Rails 内の巨大SPA の段階的なモダナイズの提案を行った事例紹介です。 いつもはパフォーマンス視点で仕事にかかるのですが、今回はマクロな設計視点でソースコードを読んでいきます。一旦は中期ゴールを提案しつつ、その作業の必要性を通して、なぜその変更が必要なのかという解説をしていきました。 コスパが良い部分からやりたいですね。でもコスパ感覚は人それぞれです。あくまでフロントエンド専門家の自分が優先度付けるなら、という観点でやっていきます。 今回の仕事にあたっていくつかの技術的な課題を取り上げますが、それはスタディスト様に問題があるという話ではありません。むしろ問題を修正しようという意思が強く、実際1ヶ月の期間中にいくつかの修正をマージすることもできています。 以下、敬称略。注意点として、今回の内容は中の人達が見返すための記述が多いの

以下の公開計測会でやったものを個別に解説してみる。 細かいテクニックが多いのだが、それを可能な限りテキストとスクショで解説したい。使い方の解説が中心で、どういう意味があるかは解説しない。 Chrome131時点のスクリーンショットで、後で読む場合は頻繁にUIが変わっている点に注意。大事なのは意図。 宣伝: これを御社のサイトで解説する仕事をやっています。 デモのURL これに意味はなく、今日偶然見ていただけで意図はない。関係ないがエッジランナーズは最高のアニメ。 DevTools を開く F12 or 右クリックから「検証」 DevTools > Lighthouse この状態で計測 このとき、新しいプロファイルを作ったりして、可能な限り Chrome拡張が入ってない状態にすること。Chrome拡張による処理も計測に含まれてしまう。 Lighthouse レポートの読み方 点数部分にマウス

import { createSelectorGenerator, toLocator } from "@mizchi/selector-generator"; const generateSelector = createSelectorGenerator(window); const selected = generateSelector(document.querySelector("div")); 与えられたDOM要素が、レイアウト上どのようなパスでたどり着けるかを解析して、その要素を Playwirght が選択するための locator コードを生成します。 生成されるコードの例。 page.locator('html') page.getByText('Click on the links above to') page.getByText('xxx') page.getBy

ポリシー: この世界では常に最新版を使うという気持ちで生きていく Node.js は枯れるという概念がなく、常に古いことはリスク という認識。LTS も短め(3年) 古いAPIのドキュメントは常に消失する モダンなツールは、モダンな前提を要求する ~2020: CJS/ESM 関連で断絶がある(jestが動かなくなりつつある) ~2019: パフォーマンス意識が低い時代の実装が多い ~2015: Node.js のみでしか動かないものが多い。peerDeps の意識が低い この辺で目視でポチポチする npm: npm-check-updates - npm yarn upgrade-iteractive pnpm upgrade -i サーバーランタイムには安定を、ツールチェインにはパフォーマンスを サーバーランタイム(Node.js) Node 本体は Stable LTS か、一つ前の

最近、技術書を読んでいると「完成形から逆算された、書き手にとって嬉しいコード」によく遭遇しています。 これが自分の理解ステップと噛み合わず、自分はこうだと嬉しい、といっても文句だけいうのも良くないと思い、自分の思う良いサンプルコードをまとめてみようと思います。 先に言っておきます。自分も自分の要求を全部同時に満たすことはできません。また、普段が自分が書くものは想定読者は自分として手を抜いています。手間を書けたとしても、一定以上の文量で必ず手間や実現性の部分でトレードオフが発生します。 自分の考える良いサンプルコード 最小スタート ステップ毎に何らかの動的/静的検査で検証できる。TDD だと望ましい 一度のコード追加は20行あたりが上限 上から順にコピペするとモジュールが動作する 最小スタート これは何らかのコンパイラを想定した適当なサンプルコードで、良い点悪い点両方あります。 // BAD

Server-Timing というヘッダがあります。サーバーからブラウザへのレスポンスヘッダとして、リクエスト内で発生した指標を送ることができます。 Server-Timing: miss;desc="Cache Miss", hit;desc="Cache Hit", db;dur=53.2, app;dur=47.2 何に使うかというと、ブラウザの DevTools や JS API からこの値にアクセスすることができます。 (現代のブラウザサンドボックスやJSではサーバーから送られたすべてのヘッダを覗き見れるわけではありませんが、これは見える値の一つです) サーバーから Server-Timing を返す方法 実験用の hono + deno で雑なサーバーをでっち上げます。 import { Hono } from "npm:hono@4.6.9"; const wait = (m

実践 いつ使うんだこれと思ってたら使う日が来たシリーズ。 今回、Deno で使ったんですが、 Node.js やブラウザでも Polyfill を入れれば動きます。 try finally で puppeteer を終了したい Deno で puppeteer を扱うために、こういうコードを書いてました。 // original import puppeteer from "npm:puppeteer@23.6.1"; import chromeFinder from "npm:chrome-finder@1.0.7"; let browser: puppeteer.Browser | null = null; try { browser = await puppeteer.launch({ headless: false, executablePath: chromeFinder(),

Vue Vapor Mode をやる可能性があるので、調べることにした。 Svelteの知識があるので、自分の為のキャッチアップとして、Vue Vapor と Svelte 出力の比較を行う。SSR時の処理などは追ってない。 試した場所 https://vapor-repl.netlify.app/ の @2ed0be8 https://svelte.dev/playground 静的コンポーネント まず何もしない Static なコンポーネントで比較する。 Svelte import "svelte/internal/disclose-version"; import * as $ from "svelte/internal/client"; var root = $.template(`<h1>Hello</h1>`); export default function App($$an

ブラウザ内テキスト探索の高速化というテーマで改善を行いました。公開許可は頂いていますが、先方の希望で社名は伏せさせていただきます。 技術的には「再現性がある木構造のノード探索の条件の生成、その実行の高速化」という少しR&Dっぽいタスクでした。Playwright のコードを参考にしつつ、個別により速いパーツで置き換えていく、というもので非常に興味深いものでした。こういう仕事は楽しいので、いくらでも歓迎です。 今回は最初はドメイン理解に時間をあてて、その後十分にドメイン理解が進んだら計測しつつ改善する、という流れです。 以下、敬称略。 相談内容 ブラウザを自動操作する技術を開発している。技術的には一種のE2Eテストの応用技術で、サーバーに要素の探索条件と、その操作を登録する。 今回の相談では、その要素探索が重くなってしまうケースがあり、これを改善してほしい、という依頼。とくにテキストを条件に

株式会社ハウテレビジョン様で、 質問箱サービスMondのパフォーマンス分析と改善を行いました。 内容としてはLCPの内訳の計測、その解決方法の提案、そして一番大きな問題だった GraphQL リクエストの最適化という話になります。 現時点で全ての問題の修正には至っていませんが、開発的には全ての問題の内訳が認識可能になっていて、検証が終われば段階的にリリースできる、という状態です。 以下、敬称略 相談内容 mond.how のLighthouseスコアを改善してほしい 主要な技術構成 Next.js - Page Router Hasura CE - GraphQL Server Hasura のセルフホスティング版 計測と問題 最近は Chrome が出してくれる Lighthouse スコアの推移が見れるダッシュボードがある。 ここで Mond の直近のスコアをみる。 代表例として ht

パフォーマンスチューニングで、ソースコードに触らず非破壊でネットワークリクエストを書き換えて、LCPがどれだけ改善するかの実験ツールが欲しかったんですが、この目的で良いプロキシツールがないです。 世のローカルプロキシツールは DNS の設定を要求してきます。これは潜在的に意図しない状況を引き起こすので、使いたくありませんでした。 tl;dr puppeteer の page.setRequestInterception(true) でリクエストを覗いて、書き換えた ブラウザからリクエスト内容を奪う方法 テスト用HTML <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> </head> <body> <script type="module"> const x = await fetch('https://jsonp

Zaraz はCloudflare 版の GTM 要約すると Google Tag Manager の Cloudflare 版。クライアントだけではなく、Cloudflare CDN を通る時の CDN Edge でも動く。 メジャーなサードパーティスクリプトはCloudflare謹製のものがあるが、基本的には GTM にあるものをそのまま移せるようなものではなく、専用に実装されないといけない。 詳しい使い方はこちら Zaraz の目的 なんでわざわざ普及したGTMではなくこんなものを？という疑問があると思う。とくに初見だとこれがなんなのか本当にわからないはず。自分もサードパーティスクリプトの開発者を経験したからこそ分かる部分と、まだわかってない部分がある。 とりあえず次のブログでZarazの買収意図が書いてある。 あなたがサードパーティのスクリプト開発者で、スクリプトを適切に保護してい

YouTube Live で Moonbit を紹介したので、そこで使った資料。 ソースコード Moonbit を紹介する 今日のコンテキスト 過去に書いた記事 『RustによるWebアプリケーション開発 設計からリリース・運用まで』という本を共著で書きました Rustってバックエンド開発に向いてるの？ (中略) あまり深く考えずに字面通り答えるなら、本書を書いた以上は「向いている」と言いたいところですが、私個人としては「Rustでも実装できるし運用できる」くらいの感覚を持っています。上述した通り、現代におけるJavaやPHP、Ruby on Railsなどの立ち位置になるのはちょっと難しいのではないか？と思っています。そもそもシステムプログラミング言語ですしね。 俺「Moonbitはいいぞ」 課題感がありそうな __syumai さんを捕まえて、ペアプロしつつ紹介したい。 (でもたまにキ

Claude or ChatGPT + Tools やモデルの組み合わせで対応パターンが膨大で面倒だったのを、 Deno + ai-sdk(Vercel) で書き直したらだいぶ楽になった。 この辺を参照した。 OpenAI と AnthropicAI の Tools の叩き方を確認したが、 Gemini はそこを省いている。 前提 まず、 AI 周りの CLI ツールは専用の面倒臭さがあることを知っておく必要がある。 ストリーミング Tools の応答 AI 周りの応答をストリーミングするのは LLM 関係なくストリーミング処理を大量に書く必要がある。 ストリーミング処理は WebSocket や WebWorker 周りのAPIハンドルと同じノウハウが必要になる。別に難しくはないが、既存の Promise 抽象に当てはまらないので、都度考えることになり、だるい。 Tools の応答は、A

この文章はプログラマじゃない人向けに JSON を知ってもらうメリット、とくにAIとの効率的な対話方法を説明し、そしてあわよくばプログラマとも JSON の水準で会話してもらえたら嬉しい…というものです。 あなたは誰 UI を作るのが専門のエンジニアです。 エンジニア以外が使うノーコードのエディタを作ったりしてました プログラマじゃない人が JSON を知る利点 プログラマとして、プログラマじゃない人向けのノーコードなどを作っていたんですが、わかったことがあります。それは、「抽象的なロジックを記述するには訓練が必要だが、眼の前のデータとUIに対応したものは簡単に変更・記述できる」ということです。 自分の考える、もっとも成功したノーコードエディタこと Google Form JSON はよく知られているデータを記述する方法の一つです。特定の言語などとは関係ありません。 で、今現在 JSON

これは YouTube Live で写経の必要性についてディスカッションするために、自分が用意した資料。 急いで書いたので色々雑。 議論が終わったら追記する、かも。 争点 プログラミングの写経に意味があるのか。ないのか。 あるとしたら、その意味は。 ないとしたら、なぜ無意味なのか。 また、少し違った視点として、とくに学校教育の現場で、モチベーションが低い対象を前提として、写経を行わせる意味などもあるかもしれない。 語らない点 個別の言語ごとの写経の向き不向き 特定ツールの良し悪し 個々のライブラリでは云々 一般化できなさそうな N=1 事例 プログラミングの写経の定義 (同意できそうなところ) 完全に思考を停止した状態で、意味を理解せずに上からタイプする作業を写経と呼んではいない。なので、仏教的な意味においての写経・読経や、ヨーロッパの修道院で行われた聖書の写本的な意味合いからは(完全に無

モダンなブラウザは JS API として gzip や deflate が使えます。 昔から Chrome に搭載してるのは知ってたんですが、今見たらだいたい搭載してました。 わかってる人向けに言うと、バンドルサイズ大きめの JS実装の pako や zlib.js が不要になって、ブラウザネイティブの(たぶんHTTP上のgzip展開と同等の)高速な実装が使えます。 // impl const encoder = new TextEncoder(); const decoder = new TextDecoder(); export async function compress(str: string): Promise<ArrayBuffer> { const cs = new CompressionStream("gzip"); const buf = encoder.encode(

最近になって Frontend Ops の傭兵として活動を始めました。 Frontend Ops 実践のモデルケースとして、 株式会社GiXo様で Next.js 仕事に取り組ませいただきました。今回、その内容を公開する許可を頂けたので、事例として公開させていただきます。 依頼主 株式会社GiXo様 以下、敬称略 相談内容 フロントエンド関連のリポジトリで、Next.js のビルドが遅くなってしまった。 重いことに起因して Vercel CI で OOM で確率的に落ちるようになった。CIが信用できなくなり、とりあえず再ビルドするクセがついてしまって、生産性が落ちている。 モノレポ内にとくに重いアプリケーションが一つあり、これを調査・解決してほしい。 仮ゴール: VercelCI 上のビルド時間を半分OOM が発生しないようにしたい 調査フェーズ リポジトリの閲覧権を頂き、プロジェクト構成

node の最新に近いバージョンで TypeScript の実験的なサポートが入っている。ts-node や tsx に頼らず typescript のスクリプトを実行できる。 ロードマップ 実験的な機能であることは承知の上で、動かしてみる。 tl;dr # ~/.zshrc alias nodets="node --experimental-strip-types --experimental-transform-types --experimental-detect-module --no-warnings=ExperimentalWarning" # run nodets run.ts

タイトルのこともできることを検証した。（ORM で文句ない人は ORM として使えばいい） Prisma は TypeScript の優秀な ORM / QueryBuilder だが、Prisma 以外で運用されていると途中から投入するのが（一応可能ではあるが）面倒だったりする。 だが Typed SQL によって、既に存在するDBに対して、副作用なくクエリビルダとしてのみ導入することができるのでは、と思いついて試したところ、できた。 今回はリモートの Supabase の PostgreSQL に対して行ったが、たぶん他の環境にも使える。 d1 とか。 prisma の最小プロジェクトのセットアップ $ mkdir prisma-qb-only $ cd prisma-qb-only ## 初期化 $ pnpm init $ pnpm add prisma @prisma/client

自分が思う最強の(かつ貧者の)構成を目指したログ。流行りの技術選定ってやつしたかった。 結論だけ言うと、まだ綺麗ではないが現実的に動く。動かし方を理解してないと事故る、かも。 この記事は自分がたどり着いた結論を順を追って記述するが、自分にとって自明な場所の差分を記録してないので、コードをなぞるより変更意図を追って各々自分で組み立てる、ということを推奨する。 動いてるリポジトリはここ。ただこの記事の説明を読まないと、その意図が伝わらない。 追記 20240829: DATABASE_URL で Connection Pool を有効にするのに ?pgbouncer=true を追加 https://supabase.com/partners/integrations/prisma このスタックの意図 Remix on cloudflare-pages コストとパフォーマンスを両立できる、20

この記事は、静的解析とビルドサイズ面で興味深いテーマでした。記事として自分の考えを書きます。 注意。あくまでビルドパフォーマンス視点での最適化です。強い意図があって、自分のドメインモデリングの方法論ではこれが最適なんだ、というなら元コードの方法論を止めるつもりはありません。 元記事のコードを minify するとどうなるか 元コードを参考に、それにアクセスするサンプルコードを書いてみます。 const sortingOptions = { priceDesc: { id: "priceDesc", sort: "price", order: "desc", label: "価格が高い順", }, priceAsc: { id: "priceAsc", sort: "price", order: "asc", label: "価格が安い順", }, ratingDesc: { id: "ra

wasi-http によって wasm がホスト言語に頼らずスタンドアロンで web server を立てられるようになった。 最近出た中で wasm のホスティングサービスに, spin と wasmcloud がある。これら2つを比較しながら試す。 spin fermyon が開発している wasm serverless service. spin 自体が提供する spin cloud にホスティングするのと、 SpinKube で k8s にホスティングするパターンがある。 install $ curl -fsSL https://developer.fermyon.com/downloads/install.sh | bash $ cp spin ~/bin use spin_sdk::http::{IntoResponse, Request, Response}; use spi

Moonbit が Component Model に対応した。 これはずっと自分がほしかった機能で、これによって moonbit が実用言語に一つ近づいたと思う。やっていきたい。 何が可能になったか できることになった例 Moonbit で書いたコードを TypeScript で型をつけて呼び出せる rust-wasm で生成した wasm コードを moonbit で呼べる wasi で CLI, wasi-http でサーバーが書けるようになる component-model とは wasm はそのままだと数値の関数呼び出ししかインターフェースを持てない。 component-model は wit という IDL でインターフェースを宣言して、wasm バイナリにインターフェースを埋め込む。 利用側(guest)は埋め込まれたインターフェースから 自分の言語用の呼び出しコードを生成

WebAssembly First な言語として自分が注目してる Moonbit 言語、過去に記事を書いてからしばらく経ったんですが、色々と大きな変更がありました。というわけで、新しい言語機能や構文を紹介してきます。 https://www.moonbitlang.com/weekly-updates/ の 4/15 ~ 8/22 を見ています。 日本だと実際に使ってる人がまだいないと思われるので、実用のための変更というより、変更された点を見ることで進化の方向性を掴んでおこう、という趣旨で読むといいでしょう。 配列リテラルがデフォルトでミュータブルに 自分が触ってから最も大きな変更です。(これでほとんどの既存のコードが動かなくなりました) ミュータブルな@vec.Vec[T] が Array[T] にリネームされ、型を省略した際の let x = [] の配列リテラルはイミュータブルな L

TypeScript は本質的に自分に型が付与されていると思っているだけの JavaScript です。 いくら型を付与しようが、それが実行時に影響を与えることはありません。 コードレビューをしているとここを誤解している人が本当に多いです。何度も解説しているのですが、なかなか浸透しないので、TypeScript におけるバリデーションという視点で記事を書くことにしました。 あと TS でバリデータ使って色々作ろうとしている友人と、プログラミング始めたてで zod と openapi を使っいる友人がいたので、彼らが想定読者です。 型と値の名前空間 TypeScript 上での名前空間(スコープ)は2つに分類できます。 値: 実行時にランタイム上のメモリに存在するもの 型: 静的解析時にのみ参照可能なもの。コンパイル時に完全に消滅する。 TypeScript は基本的に JavaScript

既存の LLM コード生成の問題 LLM は行カウントやワードカウントが苦手。 例えば自分は SourceMap を扱うコードのテストを書かせようとしたが、モックデータの line:column がガバガバな位置を指してまともにテストにならない。行カウント/ワードカウントができないのはつまり diff がうまく生成できない。 これらの問題があって、コードを生成するパイプラインを組む場合、 全文出力が主流になっている。 ここで何が問題になるかというと、コードが膨らんで来た時に、(書き変える対象が一部だとしても)生成が顕著に遅くなる。うまく生成できなかった時にリトライを繰り返すと、問題がさらに悪化する。 改善手法の提案: 明示的な Line Number の付与 最近の LLM は入力ウィンドウがある程度大きくても、そこそこの速度で応答する。(お金はかかるが...) 問題は生成速度にある。特に