最近のエントリ

単体テストも簡単に書けます。TanStack RouterのFile-Based Routingは routeTree.gen.ts というファイルを生成するので、そのファイルを参照する RouterProvider コンポーネントを普通にレンダリングすればよし。ただ同コンポーネントは非同期処理を多用しているようで、Testing Libraryのrender関数でレンダリングするとお馴染み?の警告メッセージnot wrapped in act(...)が大量に出力されます。

Warning: An update to MatchInnerImpl inside a test was not wrapped in act(...).

非同期処理が落ち着いてからテストコードが実行されるようにすればよいわけですから、render関数をwaitFor関数でラップすれば出なくなります。次のように関数化しておくと便利でしょう。


import { RouterProvider, createRouter } from '@tanstack/react-router'
import { render, waitFor } from '@testing-library/react'
import { routeTree } from './routeTree.gen'
const setup = async () => {
  await waitFor(() => {
    render(<RouterProvider router={createRouter({ routeTree })} />)
  })
}

これで新作アプリ開発の課題をひとつ解決。まだまだ先は長い……

近代の負の遺産が - KORG Gadget新曲"Scars aching violently at twilight"公開

公開: 2024-10-13

――今も人々を深く傷つける。

Scars aching violently at twilight(Processing study)

KORG Gadgetでの新作、"Scars aching violently at twilight"を公開しました。お聴きいただければ幸いです。

すべての権力者はただちに民衆への暴力行使を停止せよ。

ブラウザライブコーディングアプリ"live tone(PoC)"v0.3.0リリース

公開: 2024-10-05

Tone.jsを利用したブラウザライブコーディングアプリ"live tone(PoC)"のv0.3.0をリリースしました。

https://github.com/DBC-Works/live-tone/releases/tag/v0.3.0

今回の目玉はコード共有機能の実装。アクセスURLを発行できるWebSocketサーバーを使えるなら(私はフリープランのあるAzure Web PubSubを使いました)、URLを発行して"WebSocket server URL"にペースト、識別用のタグも指定してからの"Connect"ボタン押下でWebSocketサーバーに接続します。接続中は"Share"ボタンを押下するたびに自分のコードを同じく接続している他のユーザーに送信、他のユーザーの送信したコードも随時受信します。コードを受信するとそのユーザーの指定したタグ名のタブが増え、そのタブの選択で受信コードを閲覧できます(読み取り専用です)。"Run"ボタンを押下すればすべてのコードを同時に実行=再生します。

技術的にむずかしいことはまったくしていませんが、実際にできるようにしてみるとちょっとぐっとくるところがありました。

コードを即座に共有、一度に実行して音を鳴らす環境は私の知る限りではなく(探せばどこかにあるに違いありませんが)、この方向性を推し進めていくと新しい可能性が開けそうな予感はたしかにあります。しかしそのためには考えなければならないことが山のようにあることもまた実装していて痛感したところでした。あまり便利でないかたちでリリースしたのはそのあたりを考え始めるときりがなさそうで、あくまでProof of Concept、概念実証に留めようと思ったからでもあります。

最大の課題がTone.jsのAPIにあることはまちがいなく、普通の開発向けで冗長かつ自由度の高いそのAPIをライブコーディング用に無理に使い続けるメリットはありません。

うっかりしていて試してみるまで気づかなかったのですが、同じくらい大きな課題としてはセキュアな実行の確保があります。他人のコードが実行できるということはつまり悪意のあるコードも実行できてしまうわけで、広く使ってもらうためにはその対策は必須。v0.3.0ではコードのバリデーション処理を実装して使えない機能をブラックリスト方式でチェックしていますが、このチェックが十分であるという保証はブラウザ上で動作させるコードではおそらく永遠に得られないでしょう。

上記二点から、実用に耐えるアプリケーションとするためには専用のドメイン特化言語(DSL)が必要という結論が導かれます。しかしこの専用DSLの定義、そしてそのDSLの実行環境の整備にかかる手間がいかほどのものか、いまの私には見当もつきません。

というわけでlive toneの開発はここでふたたび塩漬けにしようかと思っています。ただちょっと別のアイディアが形になりそうな予感もあるので、今回得た知見はそのときに役立てればと考えているところです。作りかけのアプリ増やしてどうするの?という話はありますが……

他にもWebSocketの使いかたも身に着けたし抽象構文木(AST)の理解も深まったし、得るものの多い開発でした。