OmarchyのIMEを表示したり・切り替えたりするプラグインを公開しました。
Input Methods | Omarchy Plugins
omarchy plugin add https://github.com/komagata/omarchy-input-method.git --enable
日本語だけでなくFcitx5対応のものならなんでも対応です。
Omarchy Meetups · イベントカレンダーができたのをみて、
「デフォルトテーマがTokyo NightなのにTokyoのMeetupが載ってないのはまずい！」
とおもい、Omarchy Tokyo Meetup vol.1（実質２回目）をスケジューリングしました。
Omarchy TOKYO Meetup vol.1 - connpass
開場は前回に続いて、吉祥寺の決済代行プラットフォームのKOMOJUさんのオフィスをお借りしました。（感謝）
前回（2025年10月）は10人集めるのもやっとだったんですが、今回はQuattroのリリースで注目度アップ！予想以上の申し込みで枠を30人に増やしたのと、LT枠も急遽新設しました。
関連：Omarchy Tokyo Meetup vol.0をやります - 駒形電産
日本のコミュニティもみんなで盛り上げたいですね😃
DMG-01（初代GameBoy）風のOmarchyテーマが欲しくなってRetroBoyというテーマを作りました。
ライトグレーとえんじ色にオリーブ色は初代のドットマトリクスディスプレイオマージュです🤭
$ omarchy theme install https://github.com/komagata/retroboy
OmarchyのテーマTokyo Night, Kanagawaをみて、「俺の住んでるのはKanagawaじゃねえ、Kawasakiだ！」ということで1年ぐらい前にOmarchy用のテーマのKawasaki Foundryを作りました。
omarchyのテーマのKawasaki Foundry作った - 駒形電産
AIの進化がすごいので今のAIでブラッシュアップしたくなっていじっていました。
川崎の工場地帯をモチーフにしたテーマなんだけど、鋳造所というより製油所だよねということで名前もKawasaki Refineryにして別のテーマとして作りました。
$ omarchy theme install https://github.com/komagata/omarchy-kawasaki-refinery-theme
工場マニアのためのテーマのようになった🤔
アケコンを作ったんですが、3Dプリンター製なのでちょっと軽すぎる。格闘ゲームにはもっと重いほうが安定するので何かオモリを入れたいなと思ってました。
ChatGPTに相談したところ、車用の「貼り付け式ホイールバランスウェイト」 が良いとのこと。
買ってみたらまさにドンピシャ！
5gとか10gごとにわかれていつつ、両面テープでつながってるので使う分だけハサミで切ればOK。
これは良いものを知りました。みなさんも何か「オモリをつけたいな」と思ったら「ホイールバランスウェイト」で検索してみてください😁
オモリをつけるためにネジ式の蓋を開けて締め直してたらバキッと音がしてネジがついてる部分だけ抜けてしまいました。
普段だったら絶望するところを3Dプリンタ製なのでシュッとその部分だけ再印刷して問題無しでした。さらに気になってた部分のデータをちょっと修正してじゃっかん使いやすくなりました。修理容易性も自作の良いところですな。
TL;DR
Scale-to-zero can make review apps, staging environments, demos, and low-traffic internal tools much cheaper to keep around. I extended the existing draft in kamal-proxy#197 and tested it with a real Rails application on a standard 2 GB Ubuntu VPS.
- The Rails container used roughly 200–315 MiB while running and 0 B while stopped.
- The next request woke Rails and received a valid response in about 3.15 seconds.
- Large POST bodies, 20 concurrent wake requests, proxy restarts, failures, and deploys while sleeping were tested successfully.
- The implementation is now available as draft PRs for kamal-proxy and Kamal. It is not part of an official release.
- The initial design uses opt-in direct Docker socket access while keeping container operations behind an interface so a restricted host-side service can be added later.
The rest of this article explains the motivation, test results, problems found on real Docker, and how to reproduce the experiment.
Why I wanted scale-to-zero
Many teams run applications that need to remain available but receive traffic only occasionally: review apps, staging environments, internal tools, demos, and customer-specific applications.
Keeping every Rails container running all the time is expensive. Each one can sit there using a few hundred megabytes of memory even when nobody has accessed it for days. Kubernetes or a PaaS can solve parts of this problem, but they may add much more cost and operational complexity than these small applications justify.
For this kind of workload, a cold-start delay of a few seconds is often a reasonable tradeoff. What I wanted was the old Passenger-style behavior: stop an application after it has been idle for a while, then start it again when the next request arrives.
I have the same problem in a more specific setting. I run a programming school called FJORD BOOT CAMP. Our students build Rails applications as graduation projects, and I would like to keep those applications online after they graduate. They are useful as portfolios and as a record of what each student made, but most receive almost no traffic. Paying for a separate PaaS instance for every old project does not make much sense.
Kamal already makes it easy to run many applications on one server, and kamal-proxy already knows which container belongs to each host. So scale-to-zero in kamal-proxy felt like a natural experiment.
Starting from an existing draft
I found basecamp/kamal-proxy#197, a draft implementation by @martijnenco, and its corresponding Kamal change, basecamp/kamal#1800. The basic design was already there:
- stop a write container after an idle timeout
- start it on the next request
- hold the request until the health check succeeds
- persist the sleeping state in the existing kamal-proxy state file
I used that work as the starting point instead of creating another unrelated implementation. I then fixed the concurrency and lifecycle problems I found, added tests, and tried it against real Docker and a real Rails application.
This work is still experimental and is not part of an official Kamal or kamal-proxy release. The biggest architectural question is still open: should kamal-proxy have direct access to the Docker socket, or should container start/stop operations be delegated to another service?
The direct socket approach is wonderfully simple, but mounting /var/run/docker.sock gives the proxy effectively host-level control over Docker. That is a serious security tradeoff, not a harmless configuration detail.
What happened on a real VPS
I tested it on a fairly ordinary 2 GB Ubuntu 24.04 VPS with no swap. The server happens to be hosted by Sakura Internet in Japan, but nothing in the test depended on that provider. It used Docker Engine 29.1.3 and Docker API 1.52.
The first real test immediately found something the unit tests had missed. The original tiny Docker client used API v1.41 in its URLs, but this Docker daemon required at least v1.44. The daemon rejected every start and stop request. I changed the client to query Docker's unversioned /version endpoint once and use the API version reported by the daemon.
I also verified that kamal-proxy could continue running as its non-root user. Kamal mounts the Docker socket only when idle mode is enabled and adds the socket's numeric group ID to the proxy container. This matters because the Docker group ID on the host is not guaranteed to match a group baked into the image.
The low-level validation covered more than a happy-path GET request:
- a 65,536-byte chunked POST body survived a cold wake unchanged
- 20 concurrent GET and POST requests caused exactly one Docker start
- a wake timeout returned 503 and a later request could retry successfully
- a Docker start failure returned 503 and did not permanently break the service
- restarting kamal-proxy while the application was sleeping preserved the state
- deploying a new target while the old target was sleeping did not wake the stale container
- in-flight requests, WebSockets, and streaming responses prevent idle shutdown until they finish
Then I deployed a real Rails application called Calltodo. It uses Rails, Puma, SQLite, and Solid Queue. Here are the useful numbers from the final runs:
| Measurement | Result |
|---|---|
Rails boot until /up became healthy |
3.36 seconds |
| Settled Rails container memory | 205.6 MiB |
| Memory after a normal request | 298.0 MiB |
| Memory after 40 requests, 10 concurrent | 314.4 MiB |
| Memory while the Rails container was stopped | 0 B |
| Cold wake through kamal-proxy | 3.15 seconds |
| kamal-proxy memory | about 4–5 MiB |
I also ran three independent Calltodo services, each with its own container and SQLite volume. Together they used about 606 MiB while idle-but-running. After scale-to-zero, all three application containers reported 0 B. Waking only one service left the other two stopped. Waking all three at the same time completed in roughly 3.00–3.23 seconds, with one Docker start per container.
On this particular 2 GB server, three simultaneously active instances look like a sensible initial limit. The useful part is that many more applications can be installed as long as most of them are asleep. The real capacity limit becomes simultaneous wake-ups rather than the total number of deployed projects.
Of course, stopping a web container also stops anything running inside it. An application with an always-on job worker, scheduled work, WebSockets that must stay connected, or another background requirement needs a different arrangement or must leave idle mode disabled. Scale-to-zero is explicitly opt-in.
Trying the experimental implementation
The implementation and review are tracked in two draft PRs:
For reproducible testing, these are the exact revisions described below:
Both PRs are drafts. The feature remains experimental and is available for testing and review.
First, build the experimental kamal-proxy image and push it to a registry your VPS can access:
git clone https://github.com/komagata/kamal-proxy.git
cd kamal-proxy
git checkout c1587540a592a11bff2b4636a2693cf929fe8553
docker build -t YOUR_DOCKERHUB_USER/kamal-proxy:scale-to-zero-c158754 .
docker push YOUR_DOCKERHUB_USER/kamal-proxy:scale-to-zero-c158754
In the Rails application's Gemfile, use the matching experimental Kamal revision:
gem "kamal",
git: "https://github.com/komagata/kamal.git",
ref: "5064ede15fa7d4bed0c0917e23f61fe6f53564cf"
Run bundle update kamal, then configure the proxy in config/deploy.yml:
proxy:
host: app.example.com
ssl: true
idle:
timeout: 300
wake_timeout: 30
run:
repository: YOUR_DOCKERHUB_USER/kamal-proxy
version: scale-to-zero-c158754
timeout and wake_timeout are seconds. Enabling proxy.idle makes this Kamal branch mount /var/run/docker.sock, add its numeric group ID to the proxy container, and pass the idle settings to kamal-proxy. If rootless Docker or a nonstandard socket is in use, set proxy.run.docker_socket explicitly.
After updating the proxy image, deploy normally:
bundle exec kamal proxy reboot
bundle exec kamal deploy
Start with a disposable environment, a generous wake timeout, and an application whose health check is reliable. Do not put this straight into an important production server. To disable the feature, remove proxy.idle, switch back to an official Kamal and kamal-proxy release, reboot the proxy, and manually start any application container that is currently sleeping before the switch.
The design and upstream direction are being discussed in basecamp/kamal-proxy Discussion #222. Test results from other environments—especially review apps—would be much more useful than another parallel implementation.
For my use case, the result is already pretty exciting: a Rails application that consumed 200–315 MiB while nobody was using it now consumes nothing, then comes back in about three seconds. That is exactly the tradeoff I wanted.
OSSがなくなるか、少なくとも大きく衰退するのではないかという危機感を持っています。
AIがOSSを不可視化する
生成AIはOSSを利用者から見えなくしていく。
これまでは利用者自身がOSSを探してREADMEを読み、作者やプロジェクトを知ったうえで利用していた。便利だと思えば感謝を伝えたり貢献したりすることもあった。
しかしVibe CodingによってAIが必要なソフトウェアを選び、組み合わせ、改変するようになると、利用者は元になったOSSの名前すら知らなくてよくなる。
OSS自体は使われ続けても、誰がどんな思想で作ったのか、どれほど役に立ったのかは見えなくなる。結果として作者への感謝や評価、支援、貢献も減っていく。
オーダーメイドソフトがOSSを不要にする
- Software Gets Personal: The Makers | by Fabien Girardin | Personal Software | Medium
- Welcome to the personal software revolution | The Verge
生成AIによって一人ひとりの用途や好みに合ったオーダーメイドのソフトウェアを簡単に作れるようになった。
既存のOSSを探して使い方を覚え、自分に合わない部分を我慢するより、最初から自分専用のものを作るほうが早い。
そうなれば多くの人が同じソフトウェアを共有する必要は薄れ、OSSの存在価値も小さくなる。
ソフトウェアは増えるがOSSは減る。
何が困るの？
僕はOSS文化そのものが大好きなので、なくなると非常に困る。
ただ一般の人から見れば「それって困ることなの？」と思うかもしれない。
しかしこれは単に僕が寂しいというだけではなく、社会全体にとっても良くないことだと思う。
共有地の悲劇
一人ひとりにとってはOSSを探して使うより、AIで自分専用のソフトウェアを作るほうが早くて便利かもしれない。
しかしみんながその選択をすると、改善やバグ修正、設計上の知見が共有されなくなる。社会全体で同じものを何度も作ることになり、品質を共同で検証できる共通基盤も育たない。ソフトウェア技術の蓄積も弱くなる。
一人ひとりにとって合理的な選択でも、その積み重ねによって誰もが利用できる共有資産が失われていく。
これがAI時代のOSSにおける「共有地の悲劇」ではないだろうか。
悲劇を避けるには
共有地の悲劇に対しては、利用者の善意だけに頼るのではなく、資源を守るための仕組みを作るのが一般的だ。
たとえば漁場なら漁業組合や政府が魚を捕ってよい時期や量を決める。利用者同士でルールを作って監視し、ときには違反に罰則を設ける。
漁場から利益を得る人が、その維持にも責任を持つようにする。
どうすればいいのか
OSSでも同じような考え方が必要になるのかもしれない。
AIや企業がOSSから大きな利益を得るなら、その一部がOSSの維持に戻る仕組みを作る。AIがどのOSSを利用したのか分かるようにする。企業や政府、業界団体が基金を作り、共有資産として支える。AIによって生まれた改善を、元のOSSへ戻しやすくする仕組みや標準を用意する。
もちろん漁場とOSSは同じではない。魚は捕れば減るが、ソフトウェアはコピーしても減らない。
減っていくのは作る人の意欲や改善を共有する習慣、コミュニティの活力だ。
それでも共有地を利用する人が、その維持にも参加する仕組みを作るという考え方は参考になる。
AI時代のOSSにも、漁業組合のように共有資産を共同で守る新しい制度や運動が必要になるのかもしれない。
部品や道具をちまちま集めてきて時間かかったけど、自作アケコンがやったとできた。嬉しい〜😭
散らかり机。
かなりギリギリのサイズで中に収めるのに苦労しました。無理やり詰め込んでパンパンです。格闘ゲーム用にはもっと大きいほうが安定するのでシューティングやレトロゲーム用にしようかな。
3Dプリントとか、塗装とか、ラズパイPICOとか色々と苦戦しましたがとっても勉強になりました。
使ったパーツ
基盤
ケーブル類
レバー
ボタン
ケース
次は･･･
なんとかできましたが、色々改善したい点があるので次のを作りたい。
- ピンヘッダが真横に出てる形だけど上面に出てる形の方が収まりがいい
- マットな仕上げにしたが、ツルツル仕上げもやってみたい
- 既存の3Dデータを使ったが、自分でデザインしたモデルで作りたい
- 格闘ゲーム用にもっとデカくて重りとかを入れて安定したのを作りたい
さっさとスト6始めたほうがいいと思います。
Bambu Lab A2L買った！
去年末のAmazonブラックフライデーに定番のA1 miniを買って使ってたんだけど、僕の印刷したい大きめのデータが軒並み印刷できないのと、ブロブ発生からの直そうとして破壊してしまっていてしばらく印刷できてませんでした。
A1を買おうと思ってBambu Labのサイトを見に行ったら2日後に次のモデルが出るらしいということを知って新モデルのA2Lを買いました。
デカくてめっちゃカッコいい😭
A1の256mmでも十分だったのにさらにデカい330mm×320mm×325mmは最高です。またブロブ発生を検知する機能がついたらしく、それでA1 miniを破壊した僕にとってはうってつけ。
A1 miniで使ってたAMS liteもそのまま使えるということで快適さに日々感動しております。
蛇足
A1 miniはほとんどのパーツがバラで買えるみたいなので、直すべきか、ジャンクとしてメルカリにでも出すべきか、捨てるべきか…。
Android用のシンプルなテキストエディター、TweekTextを作った。
Androidゲーム機で設定ファイルを編集したい
RG RotateみたいなAndroidゲーム機を使っていると、ちょっとした設定ファイルを編集したくなることがある。XMLとかINIとかYAMLとかJSONとか、そういうやつ。
別にプログラムを書きたいわけではない。ただファイルを開いて、ちょっと直して、保存したいだけ。
しかし、Androidでそういう用途にちょうどいい無料・広告なしのプレーンなエディターが見つからなかったので作りました。
TweekText
TweekTextはAndroid 12以上で動く、シンプルなプレーンテキストエディターです。
- Android標準のファイルピッカーで開く・保存
- UTF-8
- 既存ファイルの改行コードを維持
- 検索・置換
- XML / INI / YAML / JSON などの設定ファイル向けのシンタックスカラー
- 無料
- 広告なし
インストール方法
Google Playではまだ公開していない。
GitHub ReleaseにAPKを置いてあるので、そこから直接ダウンロードしてインストールする方式。