Uzumibi 0.5 をリリースした
リリースしたよ。
変えたところをいくつか。
router 、 * でマッチ可能にした
class App < Uzumibi::Router get '/hello' do |req, res| ... end get '/*' do |req, res| # catchallな処理を書く puts req.params[:*] #=> catchallしたslugが入ってる end end
こうですね。ただ、そういえばSinatraは *.jpg とか *.* もできると気づいた。こっからっす！
ServiceWorker/WebWorkerを使って、ブラウザの中だけでRubyのルーティングにアクセスできるようにした
何言いよんねって感じの日本語になってしまった。
今、 uzumibi new -t serviceworker hoge みたいなコマンドを打つとServiceWorkerのプロジェクトが生成される。
make wasm && make serve するとWebサーバが立ち上がる。ブラウザでアクセスすると、Uzumibiアプリに対してリクエストを投げるためのフォームが表示されるので、色々操作するとリクエストが飛んでレスポンスが帰ってくる。404もわかる。
このUzumibiアプリが ServiceWorker のなかで動いているという塩梅。
RailsでやっているこれをUzumibiでやってみたという感じで、 lib/app.rb にあるDSLでルーティングを追加して make wasm しなおせば反映される*1
ただ、ServiceWorker固有の制限（スーパーリロードすると動作しないとか）が面倒だなと思って*2、fetch() リクエストをただの WebWorker に送ってUzumibiからレスポンスを返すような実装も作った。それが webworker テンプレート。WebWorkerはただの非同期実行なので、ServiceWorkerでできるワーカの保持やfetch()の自動乗っ取りなどをしてくれないけど、「別途サーバを起動せずにRubyでAPIを用意する」みたいな用途はWebWorkerが合ってるかも。用途に応じて使い分けてください。
とはいえブラウザ標準技術は勉強したばかりで何もわからずなのです...。
今度、動的に Uzumibi App をServiceWorkerにデプロイするようなサンプルを作ってみたいところ。
newコマンドの受け入れテストをrunnでCIにした
uzumibi new コマンドからの開発の流れは、基本的に以下のようなことを想定している。
- プロジェクトのテンプレートを作る
- wasmをビルドする
- サーバを立ち上げる
- ブラウザなどでIt works! が出るのを確認する
uzumibi new で作られたファイルは何もしなくてもこれが動いて欲しいが、それなりの数サポートしているプラットフォームがあり、毎回手動で確認するのはアッ、ウッだった。
k1LoWさんが作っている runn は完全にこういうことの自動化にピッタリそうなので、AIの助けを借りながらCIに組み込んでみた。
Uzumibi-cli、PRとマージでrunnベースの受け入れテストが走るようになった。テンプレートがうっかり壊れる不安がなくなった〜https://t.co/DJsMUrfr5X
— Uchio Kondo💥 (@udzura) 2026年2月26日
始めは記法が難しかったがClaude Codeさんがググってくれたので徐々に理解できるようになった。
runn の良いところは、一つは上記の「サーバを立ち上げる」操作がバックグラウンド化できる（さらに、終了時の後始末も自動でやってくれる）点、もう一つは cdp ランナーがファーストクラスでサポートされている点だなと感じている。
例えば、 WebWorker テンプレートの場合こういう操作が想定されており、その性質上何かが表示されるだけではなく、「ブラウザでちゃんと動くか」が重要になる。
- プロジェクトのテンプレートを作る
- wasmをビルドする
- サーバを立ち上げる
- ブラウザでフォームから
/へリクエストを送る - 結果が Status: 200 になるのを確認する
cdpを使えるため、ブラウザからfetchを送って結果を確認するという操作も自動化できる。まるでUzumibiのcliを検査するために作られたかのようなツールだなと感じている。
今後、例えば Cloudflare テンプレートでプロジェクトを作ったあと Durable Object を使ったコードを起動し、実際動くか試す...。みたいなテストも自動化できるのでは？と思っており、品質面で夢が広がる。
というかrunn、絶対仕事でも使おうと思った。肌感Rubyコミュニティの人にはあまり知られていなくて不思議。
という感じでUzumibiの方もじわじわ欲しい機能を作っているところ。
余談 of 余談: AI時代の個人OSS開発者の気持ち
Uzumibiにせよmruby/edgeにせよ、「今年の段階でここまでできるとは...」みたいな気持ちで夢みたい。
なんというか、前職とかの経験で、ミドルから下のソフトウェアはこう書くべきだよねとか、ちゃんと使えるOSSにするにはこういうのが必要だよね...（例えば、CI環境、丁寧な動作確認などQA力、基本的なユースケースのカバー、エッジケースへの対応とそれに対応した自動テスト、パフォーマンスとの向き合い姿勢、あとはドキュメント、ドキュメント、サンプルコード、ドキュメントなどなど）みたいなのはわかってきたんだけど、実際問題趣味プロダクトでそれらを全部やる時間はなかった。
ところが2026年、ソフトウェアとしての設計や方向性がぶれていなければ、そういう周辺の開発はAIに任せることができるようになった。
例えば mruby/edge は長らく基本的な標準ライブラリが全然なかったので、ことあるごとに「Contributor募集！」と言っていた。しかし僕の人望の問題で出現しなかった。
そこである時に、えいやとAIに指示し、このメソッドを実装してくれ！ テストも書いてくれ！ と実装させ、Rubyらしさが一気に増した。もちろん書かれたコードは全部見て確認したのだが。本当です。
これは元ネタがRubyなのでさせることができた面はありつつも、それでもとんでもない時間短縮になった。
また、ブラウザで実行できるPlaygroundも先日用意できた。
これは、 mruby-compiler2 はsetjmpなどの利用箇所があるとはいえ、Emscriptenベースならブラウザで動かせるしmruby/edgeと統合できるねと思いつき、RustでEmscripten連携何もわからんなと思いつつAIに聞きながら作らせた。これについては肌感2割ぐらいは自分で書いた。
多分自分で調べたら1ヶ月以上集中する感じになったと思う（wasm32-unknown-emscriptenの事例あんまないし）。が、 2026-02-09 00:50 +0900 にfirst commitしていて 2026-02-10 00:21 +0900 のコミットでブラウザでコードを送り込んで動くようになってるので、動かすまでに 2日 * 2時間かけたぐらいじゃないかな。
このように、ある程度利用者のいるオープンソースプロダクトなら、自分で調べて小さいspikeから始めなくても、AIが全体的に通るコードを書いてそれを読んで理解すれば良い、というふうになった。
さて、福岡市エンジニアカフェさんの厚意で、僕が主催している勉強会があるんですが、そこで雑感などを話そうかなと思っている。
RubyKaigi 2026 でも話すらしい
> Your proposal for RubyKaigi 2026 has been accepted
— Uchio Kondo💥 (@udzura) 2026年2月16日
AI使いこなし術を話します！ 嘘です。2024年からの進歩とか、こういうのに使えるよとか、あとはVMを作った感想とかいまAIを以てしてもぶつかってる壁と展望を話せるといいかな〜。
今年は、なんかmrubyのVMを作ってる人が複数人話すっぽいので楽しみすぎる。
