tsc の代替実装は作れるのか - mizdra's blog
tsc の代替実装を作る話、とりわけ Rust や Go で tsc を高速化した移植版を作る話について。非常に野心的で面白いと思いつつ、正直僕は実用レベルまで達したものが本当に登場するのか疑問に思っている。今ある型システムもそうだし、新機能として追加されるものにも追従する必要がある。当然、実用レベルとして使ってもらうには、不具合も少なくないといけない。 それに tsc も最近はパフォーマンス改善に力を入れているように見えている。実際にリリースノートを見ると、ちょくちょくパフォーマンス改善系の変更が入っている。 TypeScript: Documentation - TypeScript 4.8 TypeScript: Documentation - TypeScript 4.9 TypeScript: Documentation - TypeScript 5.0 TypeScript:
fetch の中断と Back/Forward Cache からの復元で発生する奇妙な現象について - mizdra's blog
TL;DR あるリソースの fetch 中にページ遷移すると、一部ブラウザでは fetch が中断される 中断されると、TypeError が throw される ページ遷移時は、ブラウザによって遷移前のページの実行が"停止"され、"捨てられる"ので、通常 throw された後のことは考えなくて良い しかし、そのページが Back/Forward Cache から復元されうるなら、話は別 ブラウザバックすると、エラーが throw された後からページが再開される！！！ そして発生する、奇妙な現象の数々... はじまりは、あるサービスの不具合報告 ある日、「Webサービスから外部サービスにページ遷移した後、ブラウザバックで戻ると、エラー画面が表示される」という不具合が報告された。どうも Webサービスの ErrorBoundary で何かしらのエラーが catch され、それによってエラー画
GraphQL のレスポンスのモックデータの作成を補助する TypeScript ライブラリを作った - mizdra's blog
GraphQL を使って Web アプリケーションを実装していると、GraphQL API のリクエストをモックしたいことがあると思います。 ユニットテストのために、ダミーレスポンスに差し替えたい ビジュアルリグレッションテストのために、ダミーレスポンスに差し替えたい Storybook で story を書くために、ダミーレスポンスに差し替えたい バックエンドの resolver 実装を待たずにフロントエンド側の開発を始めるために、ダミーレスポンスに差し替えたい 一般には GraphQL Client にモックするための機能が実装されてるので、そうしたものを使うことが多いと思います。 zenn.dev また最近は Client よりも外側のレイヤーでリクエストを interrupt してモックする「msw」を使うケースも増えてきてます *1。 blog.engineer.adways.n
アセットの import を簡単にする TypeScript Language Service Plugin を作った - mizdra's blog
Web ページを作るときに、あらかじめファイルに書き出しておいた画像 (アセット) をページに埋め込みたいことがよくあると思います。例えばヘッダーにサービスのロゴ画像を埋め込む場合、以下のようなコードを書くと思います。 // src/components/Header.tsx export function Header() { return ( <header> <img src="/assets/logo.png" alt="Logo image" /> {/* ... */} </header> ); } 一方で、最近のWeb フロントエンドフレームワーク (例: Next.js, Remix) を使う場合は、import 文を用いて以下のように書くことが多いと思います。 // src/components/Header.tsx import I_LOGO from '../asse
Twitter に投稿したツイートを Mastodon に転送するようにした - mizdra's blog
去年の 11 月から続く一連の騒動を受けて、id:mizdra のフォロワーの中でも Twitter から Fediverse に移行してきている人が増えてきた。僕自身は移行するつもりはないけれど、移行したフォロワーが僕のツイートを Fediverse から見れるように、ツイートを Mastodon へと転送するようにしてみた。せっかくなので、そのやり方について書き残しておく。 作戦 IFTTT という「〇〇したらXXする」みたいなピタゴラスイッチをボタンポチポチで作れるサービスがある。これを使い、当該 Twitter アカウントでツイートがされたら、それを契機に Mastodon にトゥートを投稿する、というピタゴラスイッチを組むことにする *1。 転送する上での注意点 (2023/4/10 追記) (トラバで情報を頂いたので追記) 今回紹介する方法では、普段は自動投稿のみをする BOT
CPU シミュレータを用いて継続的ベンチマークを安定化させる - mizdra's blog
id:mizdra は eslint-interactive というツールをメンテナンスしています。このツールを使うと、多数の ESLint エラーを効率的に修正できます (詳しくは以前書いた記事を見てください)。 www.mizdra.net eslint-interactive では「中規模〜大規模なコードベースであってもキビキビ動く」を大事にしてます。その一環として、eslint-interactive には CI (GitHub Actions) でベンチマークを取り、以前から大きく劣化していたら CI を fail させる仕組みがあります。 https://github.com/mizdra/eslint-interactive/actions/workflows/benchmark.yml?query=is%3Afailure しかし CI で実行するためにノイズが大きく、よく
試行錯誤を邪魔しない開発環境 - mizdra's blog
ある機能を実装する際、完成形のコードになるまでには、プログラムとして不正確な状態や、プロダクト品質ではない状態を経る 静的型検査や lint rule に違反したコードが途中に挟まる 型エラーや lint エラーは望ましくないので、できるだけ早くこうした情報を開発者に伝え、気付けるようにすると良い CI でこうしたエラーを検知して、Pull Request をマージする前に気づけるようにするとか エディタ上にエラーの情報を表示して、コーディング中に気づけるようにするとか エラーを積極的に通知してくれるのはありがたいけど、やりすぎには注意するべき なんとなくでも動いてくれたほうが嬉しい 例えば lint エラーがあった際に、watch モードで起動しているビルドやテストの実行を止めて、lint エラー見つけたよーと教えてくれる開発環境がたまにあるけど... 別にビルドやテストの実行は止める必
ネイティブモジュールに依存しない node-canvas 代替ライブラリを使う - mizdra's blog
Web フロントエンドにて、Canvas を使った View のテストを書きたいことがたまにあります。ブラウザであれば以下のようにして Canvas を利用できますが、テストが実行される Node.js ではそのような API は生えていません。 const canvas = document.createElement('canvas'); canvas.width = 200; canvas.height = 200; const ctx = canvas.getContext('2d'); ctx.fillStyle = 'green'; ctx.fillRect(10, 10, 150, 100); そこで Node.js では、node-canvas という npm パッケージがよく使われます。これを使うと、Web Canvas API 互換な API を用いて、Node.js
Prisma で本物のDBMSを使って自動テストを書く - mizdra's blog
DBMS に依存するロジックのテストを書く時、主に2つの手法があると思います。 Repository 層などを mock する Service 層のテストをする時は、その下位の Repository 層を mock して、DBMS に依存しない形にしてからテストする レイヤードなアプリケーションで適用できる手法 テスト実行時も DBMS を裏で動かして、それを使う 本番と同じスキーマを持つ DBMS に対して、実際に insert したり select してテストする DBMS は docker-compose upとかで事前に立ち上げておく 双方にそれぞれ良さがあって、プロダクトによってどっちでやるか変わってくると思います。 この記事では 2 の手法を Prisma でどうやるかについて紹介します。 前提 実際のテストコードの例 テストヘルパーを作る 別解: ヘルパーを自動生成する je
遠い未来の話をする理由、それは自信を持って前に進むため - mizdra's blog
id:mizdra は時々仕事で「今の時点で結論を出す必要はない、遠い未来の話」をすることがあります。1年後に考えれば良いことを、今考える、とかです。それをするのは何故か、という話を今日はします。 長期プロジェクトを段階的に進めていくには、不安が付き物 現在 id:mizdra はレガシーな Web アプリケーションへの Next.js の導入を仕事でやっています。新規実装部分から少しずつ Next.js を導入していて、段階的に Next.js 化を進めています。全部一気に Next.js 化するとなると、「レガシーな技術スタックでやってたアレは Next.js/React でどうやるの?」という問いが絶え間なく発生して全く前に進めなくなります。しかしスコープを小さくすれば、少しずつ問いに答えていって、進行できます。途中で方針転換もしやすいし、最初の機能をリリースするまでの時間も短くなり
リリースノート自動生成テクニック - mizdra's blog
普段からいくつか趣味で作ったツールやライブラリを npm パッケージとして publish しています。ちょっと工夫していることとして、「できるだけ簡単に npm publish できるようにしておく」というものがあります。npm publish が心理的に、手順的に難しいと、すでに main ブランチに新機能や修正が入っているのに、npm publish されていない、という状況が発生しがちです。新機能や修正をすぐにユーザに送り届けられるよう、npm publish は無思考でできるようになっていると嬉しいです。 その一環として、リリースノート (CHANGELOG) の自動生成というのをやっているので、その紹介をしてみます。本当は 6 月にやっていた Maintainer Month 期間 に間に合わせたかったのですが、とろとろしていたら 7 月になってしまった！ まあ遅れたから公開し
チームに提案をする時は傾聴することが大事 - mizdra's blog
「こういう取り組みをチームで始めてみたい」だとか、「新しいコーディング規約を考えてきたので、これを導入してみたい」だとか、「こういうツールを導入してみたい」だとか、チームに対して提案をする場面というのはよくあると思います。実際に提案する際には、以下のような 4 つのフェーズからなるフローで進めることが多いと思います。 提案の概要をまとめた資料 (提案書) を作成する 何故それをやりたいのか (背景・動機) どんなことをやりたいのか、やってみてどんなメリットがあるのか 懸念やデメリット、代替案などはあるか 1の提案書を誰かにレビューしてもらう 意見をもらって、提案書を適時修正するフェーズ 再度レビューに出して、チームから承諾をもらう 提案を実行する で、この 2 についてなのですが、id:mizdra はこのフェーズで傾聴を大事にしています。レビューに出したら、色々な人からフィードバックコメ
見つけた GitHub の Issue を片っ端から subscribe している - mizdra's blog
あるライブラリを使っていてバグっぽい挙動に遭遇した時、ほぼ必ず当該ライブラリの Issue を検索するようにしている。加えて、見つけた Issue の subscribe ボタンを押して、https://github.com/notifications に通知がいくようにしている。バグ遭遇時以外にも、何らかの理由で Issue に到達した時にその Issue を subscribe してる。 ハマったバグの Issue を見つけた時 欲しい機能の feature reuqest の Issue を見つけた時 例: Docker for Mac の VirtioFS 対応の Issue その他面白や動向をチェックしたい Issue を見つけた時 例: TS 4.7 のリリース計画について議論している Issue 例: Jest の ESM 対応の Meta Issue 例: ESLint の
npm-scripts を書く時の手癖 - mizdra's blog
かれこれ 5 年くらい趣味開発で npm-scripts を書き続けている。長年書き続けているとノウハウが蓄積されてきて、「こう書くとスッキリする」「迷いがなくなる」「後から拡張したくなった時に、簡単に拡張できる」みたいな書き方が身についてきた。自分の型、あるいは手癖のようなものだと思う。 せっかくなので、id:mizdra の今の npm-scripts を書く時の手癖を書き連ねてみる。 基本形 { "scripts": { "build": "webpack --mode production", "dev": "webpack-dev-server --mode development", "lint": "eslint .", "test": "jest" } } 一番シンプルな npm-scripts を書く時のパターン。以下の 4 つの script を登録している。 buil
Sentry で IP アドレスの収集をやめる - mizdra's blog
@sentry/browser を使うと、ブラウザでエラーが発生した時にそのエラーを Sentry の集計サーバに送信して記録してくれます。送信されたエラーはエラーの種類ごとに Issue という単位にグルーピングされ、Issue ごとに何件発生しているのか、何人のユーザで発生しているのか、過去2週間にどれぐらいのエラー数の増減があったのか、などと簡潔に表示してくれます。便利ですね。セットアップも非常に簡単で、十数行程度のセットアップコードを書くだけで使い始めることができます。 エラーが Issue ごとにグルーピングされている様子。画像は https://docs.sentry.io/product/issues/ から引用。 IP アドレス の収集をやめる ところでこのエラーが発生したユーザ数 (画像の USERS のカラムの部分) なのですが、デフォルトではエラーの送信元の IP ア
ブラウザにおけるメモリリークを解決するために読んでおけると良い資料 - mizdra's blog
最近趣味や仕事の Web アプリケーションでメモリリークに遭遇して、頑張ってメモリリークの原因を突き止めて修正する、ということがあった。その過程でメモリリークについて色々調べて知見が溜まったので、学習資料の紹介という形でアウトプットしてみる *1。 前置き 紹介する記事がかなり偏っていることに注意 冒頭で触れたメモリリークを解決するために読んだ記事をまとめただけなので、内容にそれなりの偏りがある 例えば id:mizdra が遭遇したメモリリークは全てブラウザ上で発生していたものだったので、これから紹介する内容も主にブラウザにおけるメモリリークに焦点を当てたものになる GC がどうメモリをどう解放しているか、何故メモリリークが発生するのかは全てカット 調べれば色々な記事が出てくるので、必要に応じて読んでください 基本的な知識を抑える まずメモリリークとメモリ撹拌の違いを学ぼう どちらも同じ
WebAssembly 開発環境構築の本を公開しました - mizdra's blog
はじめに Rust を用いて WebAssembly の開発環境を構築する手法を紹介する電子書籍を執筆・公開しました. WebAssembly へのコンパイルが可能な言語である Rust を用いて, WebAssembly の開発環境のテンプレートを作成する内容となっています. wasm-dev-book.netlify.com 本のタイトルからは一見すると C/C++ を用いた開発環境の構築も扱うように受け取れますが, 本書では Rust のみしか扱っておりません. ご注意下さい. 書籍の執筆動機 著者が春休み中に WebAssembly を用いて Web アプリケーションを作成する機会があり, 本書はそこで得た知見を纏めたものとなっています *1. 元々大学のサークルで発行した部誌に同じテーマで記事を書いており, 本書ではそれを Web 向けに編集・加筆した内容から構成されています.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
