ロマン構成が動いたので紹介します。 コード: https://github.com/mizchi/absurd-sql-example-with-typeorm デモ: https://heuristic-perlman-94f8f4.netlify.app tldr Steam の某クリッカーゲームをやってたら放置ゲーでも作りたい気分になってきた。 複雑なデータを管理するならブラウザ内に本物の sqlite を持ってきたい sqlite は持ってこれたけど TS の中で 生 SQL 書くのがだるかった(補完支援がない)ので ORM でラップしたい Typeorm + absurd-sql の構成を試したら色々大変だったけど動いた つまりブラウザでこのコードが動く。 // ... @Entity() class User { @PrimaryGeneratedColumn() id: nu

TypeScriptの話です。default exportを使うことが有害であるかのような言説に異議を唱えるためにこの記事を書きました。 あらかじめ断っておきますが、この記事はTypeScriptを使っているプロジェクトのモジュール構成に関する話です。npmに上げられているようなNode.jsパッケージ間でのimport/exportはまた別のエコシステムが関わってくる話なので、分けて考えてください。Denoにおけるimport/exportに関しては、この記事での議論がそのまま通用します。 基本的にdefault exportのみを使うべき 筆者の考えでは、named exportの方が、あなたのプロジェクトに対する害が大きいです。むしろ、「基本的にdefault exportのみを使う」ことを考えた方が良いと思います。それは以下のような理由からです。 named exportを積極的に

ビルド済みの依存がない 巨大な js を import するとき、バンドラーによる解析フェーズを飛ばしたいことがあります。巨大なファイルを別にビルドして、アプリケーションとしてその利用者になるときなどですね。単体で動く巨大なモジュールとして、 typescript や prettier が挙げられます。 というわけで、 webpack だと noparse オプションで解析をスキップできるのですが、 vite / rollup だとそれがないので無理やり実現するプラグインを作りました。 気が向いたら npm に投げますが、別に設定ファイルに直接書いてもいいぐらいの分量なので, vite.config.ts を置いときます。(vite に設定ファイルの ts 対応が入ってます) // vite.config.ts import type { Plugin } from "rollup"; i

依存を解析しつつのインクリメンタルビルド、各コンパイラについてたりついてなかったりするんですが、どのビルド環境にもほしいですよね。 真面目にやるんだったら bazel が鉄板みたいなんですが、基本的に超大規模向けでエコシステムのいろんな都合でセットアップが非常にだるいです。後付の導入も結構だるいです。 Bazel - a fast, scalable, multi-language and extensible build system" - Bazel というわけで、今回は自分が欲しい機能、「ソースのハッシュが過去のものと違う場合にビルドを実行」という機能に特化して作りました。逆にいえば他はなにもないです。依存解析も環境ごとの最適化もないです。 npm が入ってれば npm i -g bincr or npx bincr ... で実行可能です。特に node の機能を前提にしてないので

yarn v3 が出ました。詳しい解説は譲るとして、esbuild integration や パフォーマンス向上が目玉です。 Yarn 3.0 🚀🤖 Performances, ESBuild, Better Patches, ... - DEV Community 流石に v1 はもう古いが、 v2 からの独自路線は受け付けがたい…という立場なのですが(yarn オリジナル作者の sebmck も難色を示しています)、今回は yarn 特有の機能をできるだけ避けて、できるだけ npm や pnpm 等と互換な部分だけで yarn v3 を使います。なので pnp も使いません。eslint や vscode の typescript 等でハマりどころが多すぎます。 ゼロインストールも否定派です。git blob objects のサイズが爆発して仕事にならなくなったことがあります。

TL;DR VS Code 前提になってしまいますが、VS Code Remote Containers 拡張最強です、という話。実際にどういう風に作れば良いかは参考リポジトリ作ったので見て下さい。 はじめに 背景ぼかしのような推論結果を使ってカメラ画像にフィルタを入れる処理を書くとき、今だと選択肢は大きく分けて 2 つあります。 tfjs を使う Wasm 経由で tflite やその他ライブラリを使う この記事では後者の Wasm を使う方に注目して、その開発環境について記載します。 先行例 w-okadaさんのリポジトリには複数の Wasm を使った事例が紹介されています。 例を挙げるとTFLite Wasm for Google Meet SegmentationやTFLite Wasm for ESPCNなどが Wasm です。 これらのビルド環境はどうなっているかというと、Do

というのを使っていて思ったのでレポを書いていきます。 mabl とは - 基本的な機能 ざっくり言うと E2E テストをお手軽にメンテできるツールです。 こんな感じでポチポチ画面を操作していくと、それで実行したアクション(ボタンやリンクをクリックするなど)を自動で記録してくれて、E2E のテストを作成することが出来ます。 コードを書かずに　E2E　テストをサクッと作れちゃうのが魅力な訳ですが、それだけではありません。そんなすごいところを紹介していこうと思います。 mabl のここがすごい Auto Healing 何やら回復魔法みたいな感じでかっこいいですが、何かというと E2E テストがコケるようになった時に自動で修復してくれる機能です。 例えばボタンの位置が変わってしまっても、同じ文脈であろうボタンを自動で探して修復したりしてくれます。 E2E での辛さといえば、やはりテストのメンテナ

※ただし IE は除く 問題 今までのフロントエンドの悩みの一つに、 publicPath の設定がありました。これはchunkを含むビルドした際に、chunk を解決するホストを明示的に指定する必要がある、というものです。 例えば、 https://cdn.example.test/assets/module.js に静的ファイルを配置する際、 publicPath として https://cdn.example.test/assets/ を指定する、という必要がありました。これはレガシーブラウザ環境だと module.js が自分自身がどのようなパスとして実行されているからわからず、相対パスのファイルのパスを知る方法がなかったのでビルド時に指定する必要があったわけです。 解決方法 現在、ESM なら import.meta.url、 <script src="..."></script

主張 現代では、 npm に publish するものを除けば TypeScript をコンパイルして配布する必要はほぼないと考えています。 TypeScript のコンパイルをしない環境、例えば deno や rome を使うと、コンパイルをするというステップが省くことで開発体験が大きく向上する、という肌感があり、ローカル環境ならこのメリットを優先するべきと考えています。 基本的に、ビルドはフロントエンド/サーバーともに配布前の最後の一回だけでいいはず、というのが自分の主張です。 Rome Toolchain Deno - A secure runtime for JavaScript and TypeScript 理由 現代の npm のお作法に従うと TypeScript に依存したものを npm の registry に置くことは、あまりよくないこととされていますが、モノレポ内や特

AWS Amplify ConsoleでNext.jsのプロジェクトをデプロイすると Serverless Next.js Component のインテグレーションによってAWS Lambda リソースが最大4つ作成される(ソースコードはエクスポートできる) Default Lambda@Edge for Next CloudFront distribution API Lambda@Edge for Next CloudFront distribution Image Lambda@Edge for Next CloudFront distribution Next.js Regeneration Lambda それぞれのAWS Lambdaが行っていることを読み解くとVercelが自社で構成しているシステムの外観が分かるのではないかと思って眺めてみた (CloudFrontのコンソール

axum version0.2.0 is released!! 本日2021-08-24、axum version0.2.0がリリースされました。 この記事のコードを参考にする場合はバージョンによる違いに注意してください。 2021-08-14追記 axum 0.1.2, 0.1.3のリリースによりこの記事の一部の記述は古いものとなりました。 この記事に関わる変更は以下です。 多くのextractorが Deref を実装した axum が hyper::Server をre-exportするようになった extract::UrlParams と extract::UrlParamsMap が非推奨となり、 extract::Path が推奨されるようになった axum 0.1.3対応版のコードは https://github.com/techno-tanoC/axum_sample/tr

対象となる読者 これからFlutterの勉強を始める人 ネットで断片的な情報を拾いながら勉強するのが苦手な人 FlutterというToolkitの根本理解を目指す人 英語が苦手、公式ドキュメントを読むのに挫折した人 対象でない読者 メンター等、周りに勉強の仕方を教えてくれる人がいる人(その人に従うのが一番です) Flutterにはあまり興味ないけどとにかくアプリは作りたい！という考えの人 とにかくアプリ作りたい！アプリの作り方教えて！精神の人 公式ドキュメントの内容やネットの情報を自ら吸収できる人 なぜこの記事を書いたのか Flutter初心者の方が迷子にならないような道しるべが必要だと思ったからです。 僕もFlutterを触り始めて4ヶ月の初心者ですが、まだ4ヶ月しか経っていないからこそ最初に躓いたことや、どういう勉強が役に立ったか記憶が鮮明に残っています。 まだFlutter初心者の目

VueやViteなどの作者として知られる天才Evan You氏がVueとSvelteのサイズについて比較検証を行い、一部で話題になりました。 このスクラップでは、比較検証の内容についてちょっと掘り下げてみていきたいと思っています。いい感じにまとまったらちゃんとした記事にするかもしれません。しないかもしれません。 色々書いていく前に私の立場や考えを明らかにしておきます。 私はSvelteの日本語翻訳をしていてもちろんSvelteを気に入っていますが、Vueも好きで良く使っています。フロントエンドがメインではありませんので、知識が足りないかもしれません。変なところや間違っているところがあったらコメントで指摘してくださると嬉しいです。 フロントエンド界隈のバチバチやり合っている雰囲気はとても良いと思っています。ちゃんとコードを書いてベンチマークをとってそれを公開し、指摘し合ってお互いを高めていっ

Volta とは Voltaとは、JavaScript ツールマネージャーです。 タイトルでは Node.js のバージョン管理としていますが、 npm・yarn のバージョン管理も行うことができます。 公式サイトでは、「The Hassle-Free JavaScript Tool Manager（手間のかからない JavaScript ツールマネージャー）」と紹介されています。 チームの Node.js のバージョン管理を Volta に統一したところ非常に DX が上がり、Volta の恩恵を感じています。 この記事では、開発者の Volta 人口を増やすべく Volta の紹介と使用方法について解説していきたいと思います。 なかなか詳しく解説している日本語のソースはないので、公式ドキュメントを読んで適宜和訳しています。 公式ドキュメントを読むのがめんどくさいという人に読んでいただい

超巨大フロントエンドを分割する基盤を作ろうとしたものの紹介します。 この記事の前提 巨大フロントエンドを分割統治したい SSR は考えない モダンブラウザのみ対応する(IE11 非対応) この記事では single-spa とマイクロフロントエンドの紹介はしません。こちらの記事を読んでください。 マイクロフロントエンド入門 single-spa でマイクロフロントエンドを検証する - mizdev single-spa はアプリケーションのライフサイクルに簡単な規約を導入するもので、おそらく一番使われてるものです。これを基本的に vite と組み合わせて各アプリケーションを構成しますが、 webpack でも同様のことは可能です。 動いてるもの デモ ここで実現したこと 共通ヘッダ 異なる環境でビルドされたコンテンツをルーティングごとに切り替える react-router のアプリと vu

ES2021 に入った WeakRef を実験したらハマったのでメモ WeakRef - JavaScript | MDN WeakRef: JavaScriptに弱参照がやってくる（ついでにFinalizationも） - Qiita tl;dr devtool を開いた状態で console.log すること自体が参照になる WeakRef で取得した参照を console.log すると、それも参照なので、本来開放されるはずでもリソースの開放が行われなくなる 循環参照オブジェクトでも、内部での循環参照に閉じてる限りちゃんと捨てられる(少なくともv8は) 確かめたこと 循環参照のオブジェクトの GC がなされず困っていたので、確認のために色々と実験していた。 まず、循環参照オブジェクトを作る。この Node は再帰的に辿れるように、 parent と children で相互に参照を持

DnD は考えることが多い。大抵のライブラリは特定のユースケースにべったりで、毎回自分で書く羽目になる。 とくに、木構造の DnD をどう表現するかが難しい。特にWeb上でファイラーのようなUIを実装する頻度が高く、その求められる実装が毎回違うので、自分が考えていることを一般化してみる。 この記事はコードをコピペしたら使えるものではなく、あくまで考え方をコードに落としたもの、ということに注意。 今回は前提として、こういうものを作っていた。 DnD の要件 DOM ベースの sortable ライブラリはいっぱいあるが、DOMをマスターデータとして扱うタイプが多く、現代のフレームワークと噛み合わない。可能な限りデータを元に表現して、最後に変更したデータを render するだけとする。 フレームワーク非依存な処理を切り出して、UIを通さずにテストを書いたり、ポータブルに扱えるようにしたい。

エンジニアの間で話題沸騰｢はじめてゲームプログラミング｣ 6月11日に発売され一時トレンドにも載るほど｡ ｢ナビつき！つくってわかる はじめてゲームプログラミング｣｡ ｢ノード｣をつなげてプログラミングしてゲームを作っていきます｡ 例えば｢Lスティックノード｣と｢ヒトノード｣を繋いでLスティック操作ができるようになります｡ チュートリアルでは｢おにごっこゲーム｣や｢マリカ｣みたいなものを作れちゃいます｡ 私ももちろんプレイして実況配信なんてやってみたのですが節々で｢プログラミング学習｣という点で衝撃を受けました｡ 今回はその衝撃を紹介していきたいと思います｡ 約束された｢完成したときの達成感｣ ｢ナビつき！｣というタイトルの通り､チュートリアルが懇切丁寧です｡ 失敗につながるようなメニューは無効化されていますし､しばらく迷って画面上で進捗を出せないでいるとアシストしてくれます｡ ｢完成｣す

概要 本記事では、Next.jsをコンテナをサーバーレスで実行するサービスであるCloud Runで動作する軽量のDocker環境構築について紹介します。 ネットにある様々な記事を見てきましたが、動作目的でDockerイメージが大きくなっており、パフォーマンスとセキュリティに課題がありました。そこでDockerの軽量化および最適化を試みました。 Docker環境 シングルステージビルド（slim） シングルステージビルドしたDockerイメージです。本番環境に必要無いデータを多く含んでいるため、イメージサイズも大きくなっています。構成はシンプルのため、理解しやすいですがパフォーマンス/セキュリティ面には課題があります。 FROM node:14.17.0-slim WORKDIR /app COPY package.json yarn.lock ./ RUN yarn --frozen-l

これは monaco-editor で作られたエディタを操作してるサンプルです。 アイデア 複雑な SPA を同じページ内部で動かそうとすると、主にビルド方法や相対パス周りで問題が発生します。例えば vite と webpack で噛み合わなかったり、monaco-editor のように暗黙の loader を大量に設定する必要がある場合だったり、デプロイされた場所のどういう相対 URL でモジュールを解決するか、です。 このうち、部分的に複雑なコンポーネントを埋め込む場合(例の monaco-editor がそうです)、古の iframe widget のアプローチでこれを解決できるのでは、と考えました。また実際に手元で発生していた問題で、とある画面でコンパイラ一式を埋め込んで rollup のビルド結果をプレビューする、という機能がプロジェクト全体を重くしてしまった、というのがありまし