かわいい駆動生活。

nix-portableで開発環境をシングルバイナリにする

Wed, 08 Apr 2026 00:00:00 GMT

VPSで開発環境を構築する方法を調べている時にnix-portableでdevShellをbundleできることを発見したので試してみた。この方法を使うと開発環境を単一バイナリにできる。 ## 概要 [nix bundle](https://nix.dev/manual/nix/2.24/command-ref/new-cli/nix3-bundle)を用いて開発環境を提供するderivationを単一バイナリにbundleする。 mkShellはderivationを提供しないため、devshellの定義には[numtide/devshell](https://github.com/numtide/devshell)を使用する。 ## やり方 - `numtide/devshell`を使用してdevShellを定義したflakeを用意する。この時、`packages`に`pkgs.nix`を含めること。 - `nix bundle --bundler github:DavHau/nix-portable -o devshell .#devShells.{system}.default`でbundleする。 - `{system}`の箇所は`x86_64-linux`など、ターゲットのアーキテクチャに合わせる。 - `./devshell/bin/devshell`に実行ファイルが作成される。これを実行すると開発環境に入れる。詳細はサンプルを参照して欲しい。 https://github.com/Comamoca/sandbox/tree/main/portable-devshell ## 仕組みの説明 NixにはDerivationを単一バイナリにbundleする`nix bundle`というコマンドがあって、このコマンドを使用すると任意のDerivationを単一バイナリにできる。また、nix bundleはbundlerを指定することで任意の方法でbundleすることが可能。 nix-portableはこのbundlerを提供することで、devShellをDerivationと見なし単一バイナリへと変換できる。 nix bundleについては過去に記事を書いたので、そちらも参照して欲しい。 https://comamoca.dev/blog/2025-12-17-build-gleam-erlang-target-to-single-binary-with-nix/ ## これが役に立つ場面インストールできるOSに制限のあるVPSとかで、環境をきれいに保ちつつNixで構築した環境を使う場面とかで役に立ちそうだと思った。単一バイナリなのでDockerより手軽に環境を他者に投げられるので、環境の共有という面でも役に立ちそう。 ## 問題点 - 開発環境に含めるツールが多いほどバンドルサイズが増加する。 - 自作した[サンプル](https://github.com/Comamoca/sandbox/tree/main/portable-devshell)は350MBほどだった。 - bundlerに`github:DavHau/nix-portable#zstd-max`を使用すると圧縮にzstdを使用することもできる。この場合は277MBだった。初回起動に数秒かかるけど、サイズ削れるのでこっちの方が良いのかもしれない。 - devShellの作成に`numtide/devshell`を使用する必要があるため、既存の開発環境から移行するのにコストがかかる。 - [service-flakes](https://github.com/juspay/services-flake)のような高級なserviceを作成するモジュールが使用できない。 - 一応`numtide/devshell`にもserviceを実行する機能はあるが、ただ複数コマンドをwrapするだけなのでservice-flakeと比較して貧弱。

NixでNixとDockerイメージの環境を共通化する

Mon, 06 Apr 2026 00:00:00 GMT

現時点で記事の体裁を整える気力がないので箇条書きのまま公開します。完全版はZennとかに公開するかもです。あとさも実務で使ってるかのような書きっぷりをしていますが、僕は**Nixを実運用で使ったことがないので全部想像となっています。** どなたかこの記事を参考に実運用した方がいたら感想を聞かせて欲しいです。この手法を使っているリポジトリとして以下があるので、参考までにリンクを貼っておきます https://github.com/Comamoca/gleam-by-example --- - nixを使うと再現性のある環境が作れて嬉しい - しかし、全員がnixを使っている訳ではない - 全員がnixを使用するようにするのもコストがかかる - ツールの学習コストを組織で支払うか、個人で支払うか問題 - ただ使うだけも悪くないが、トラブルが発生した際に自己解決できないため一定のリスクがある - リスクを鑑みると全員がNixを扱うようにするのはハードルが高い - Nixの特性上、ストレージと帯域、CPUにRAMとリソースをかなり消費するため、それが気になる人がいる事も予想される - :bram:案件と言われればそう - 自己解決できない人は引き続きDockerを使う運用がバランスが良い - イメージの管理が俗人化する問題はあるが、Nixのメリットと天秤にかけて十分飲める代償と考えている - そもそもそのリスクとコストが払えない環境でNixもといメジャーではない技術を使うべきではない - dockerと並行して環境を管理する必要がある - 2重管理になりコストがかかる - Docker内でNixを実行する方法 - [DevContainer上でNix Flake環境を構築する](https://www.ncaq.net/2026/01/16/14/18/49/) - Dockerのレイヤー上でNixのCacheを管理できないため、調整などを行う際にそこそこの頻度でNix側のフルビルドが走る - Nix側のビルドがDocker側のビルドに上乗せされるため、ビルド時間が長くなりつらい - :bram:すれば解決できるかもしれない - 解決策: Docker Image自体もNixでビルドし、全てNixで管理する - 全ての環境構築をNixの上に載せられるため、Nixの恩恵を受けられる - NixでDocker Imageをビルドすると、Scratchイメージからのビルドが容易 - Scratchイメージを使用してイメージを作成した場合、Nixによって解決された依存関係が静的に配置されるため、事実上のdistrolessと同等になる - [distrolessコンテナイメージの中を覗いて「なんか軽くてセキュアらしい」より理解を深める](https://www.m3tech.blog/entry/2026/04/03/180000) - 依存が固定化されるため「数年越しのDocker Imageが壊れている」問題を解消できる - 実際の手順 - 予めdevShellを定義する - アプリケーションを動かすのに最低限必要な依存を変数として定義しておく - devShellや開発用Docker Imageなど、開発時に必要な依存も別途変数として定義する - それぞれの環境を作成する際にアプリケーションの依存へ追加する形で依存を定義すると依存の管理が楽になる - devDocker Image.pkgs = deps ++ devDocker ImageDepsのような感じ - 開発用のDocker Imageにはshellが含まれていた方が使い勝手が良いが、Scratchから作成した場合は含まれていない - 開発用Docker Imageに必要な依存は別で変数に定義する - pkgs.dockerTools.buildDocker Imageでイメージをビルドする - 具体的な方法は既存の記事を参考にする - nix buildにて、Docker Imageがビルドされる - 従来のnix buildと同様に、result/へビルド済みイメージが出力される - このイメージをdocker load すれば良い - CI - 手元でnix buildする運用も悪くないが、結局手元のマシンでNixを実行しているため先述した問題を完全に解決できていない - Dockerしか使わない人はdockerコマンドを叩くだけで済むようにしたい - GitHub Actionsを用いてDocker Imageをビルド、コンテナレジストリへpushする - Docker Imageがpushできれば良いため、任意のレジストリ(ECR, Cloudflare Containers等)が使えるが、こだわりがない場合はGHCRをオススメする - GHCRはGitHubが提供するコンテナレジストリ。DockerHubより制限が緩くActionsとの相性も良い - (実際のサンプルコード) - レジストリに上げてしまえば利用者はdocker pullをすれば良いため、Nixを実行する必要がなくなる - また、レジストリに上げたことでビルドしたDocker Imageをイメージ名でどこからでも参照できるようになった - devcontainerからも参照が可能 - 別途devcontainerの設定を作成し、イメージにNixでビルドしたイメージを指定することで、VSCode環境ならdocker pullするまでもなく開発環境へアクセスできる - 課題 - Nixではdocker-compose環境を上手く表現できない - service-flakes等はあるが、docker側とは両立できる訳ではない - Nixのみの環境ならservice-flakesに寄せるのが妥当 - 複数のコンテナのオーケストレーションに関してはdocker-composeの方に分がある - 複数コンテナの実行だけは全員docker-composeに寄せるのが良さそう - 内部で使用しているイメージさえNixでビルド出来ていれば安定性は担保できる - いいとこどりが出来る - まとめ - NixはDocker Imageが作成できる - Nixの特性を生かすことでセキュアかつ安定したDocker Imageを作れる - ビルドしたイメージをレジストリにpushする事で、利用者側は環境構築をdockerコマンドで完結できるため、Nixを導入する難易度を大幅に下げられる

アイマスNightやるぞ！

Mon, 23 Mar 2026 00:00:00 GMT

こういうのは勢いと相場が決まっているのでまだ構想段階ですがイベント概要を書いていきます。 ## 動機アイマスの前提を共有した場でしか話せない話をもっと聞きたい、話したいと思ったからです。サブカル好きなITエンジニア向けのイベントとしては既に[エンジニアニメ](https://engineers-anime.connpass.com/)があります。もちろんここでもアイマスの話は何回もされてますし、なんなら来月の4/11(土)開催の[【劇場版】アニメから得た学びを発表会2026](https://fortee.jp/engineers-anime-2026)では[人と人が一緒に歩くために必要なものって、なに？](https://fortee.jp/engineers-anime-2026/proposal/41bde750-9bf8-4770-a6e5-a989a4eec6e8)というタイトルで[アイドルマスターシンデレラガールズ U149](https://idolmaster-official.jp/cinderellagirls/u149_anime/)について話させていただくのですが、よくよく考えるとアイマスって厳密にはアニメでもないし、ゲームかと言われると微妙という立ち位置にいるな...なんて思ったりします。それと、20年分の蓄積があるのでちょっと凝った話をしようとするとコンテキストの共有が難しかったりすることも多いです。そう考えていくとアイマスP向けのエンジニアニメ的なイベントがあっても良いのかな〜と思ってます。あと単純に僕がアイマスの話したいのと、色んなITエンジニアPに知り合いたいってのがあります。 ## イベントのコンセプト以前外部キーNightを見た時に、「外部キーなんてニッチなものでイベントできるならアイマスは余裕じゃない？」と思ったのがきっかけです。なので平日夜あたりに開催するというのが前提になってます。ゆくゆくは土日開催も考えてるけど、土日はライブが被ることも多いので一旦平日でやってみようという感じです。アイマスPじゃない方の参加も全然OKな感じにしながら、アイマスP向けイベントならではなことはやっていきたいなと思ってます。例えば[協賛企業呼び](https://www.setandset.com/archives/imasgyokaiyogo.html#%E5%8D%94%E8%B3%9B%E4%BC%81%E6%A5%AD%E8%AA%AD%E3%81%BF)だとか[いつもの](https://www.setandset.com/archives/imasgyokaiyogo.html#%E3%82%A2%E3%82%A4%E3%83%9E%E3%82%B9%E3%81%A7%E3%81%99%E3%82%88%E3%82%A2%E3%82%A4%E3%83%9E%E3%82%B9)だとかですね。 ## 日時 3/24 追記なんと開催予定日に[RubyKaigi](https://rubykaigi.org/2026/)があるそうなので、開催予定日をちょっとずらそうかなと考えてます。 Ruby界隈はITエンジニアPが多いそうなので被らせるのはもったいないなと... 追記おわり ~~4/20(月)〜4/23(木)~~ 4/27, 4/30〜5/1, 5/11〜5/14、5/18〜5/22あたりのうちどこかで開催したいなと思ってます。 ~~ただ、この週は土日に**THE IDOLM@STER SHINY COLORS ∞th LIVE iと夢**が開催されるので、金曜だけはライブに備えてイベントは避けたいなと考えてます。~~ 開催時刻は19:00〜を考えてます。最近定時が18:00になったのでこの時間帯でも動きやすくなったのは地味に嬉しいかも... ## 場所今から探す感じです。会場募集してます！連絡は[Twitter](https://twitter.com/Comamoca_)のDMか[Discord](https://discord.com/users/comamoca)のDMでお願いします！ --- すごくふんわりしてますが、学マスがきてからアイマスPも増えていると思うこのタイミングでエンジニアPが集まる場を作っていきたいですね！

東京に住み始めて一年が経った

Fri, 20 Mar 2026 00:00:00 GMT

東京歴一年になりそうなので感想とか知見を書いてみる。 ## 一年東京に住んだ感想 - 去年の4月から東京住んでる - 山梨出身なので東京は結構近いし、それより前にもちょくちょく知人の家に泊めてもらってたのであんまり新鮮な感じはなかった - 今は王子(田端のちょっと上、埼玉のちょっと下)に住んでる - まいばすけっととそれ以外のスーパーの2つにアクセスできると、文明的な食生活が出来るのでオススメ - 人多い - 一人暮らしが上手くいってるのはメンタルモデルがソロキャンプだからだと思ってる - 1年継続してソロキャンプを継続している感覚なのでずっと変な感じがしている - 人がとにかく多い - 段々と遊牧民の気持ちが分かってきた - 実際のソロキャンプに比べたら一人暮らしは簡単だけど、大抵の人はソロキャンプ経験ないのでコツを表現するのが難しい - マジで人が多い ## 家具問題 - 寝床はちゃんとしたのを用意したほうが良い - 急に上京が決まったので、始めの1週間は段ボールの上に寝袋置く形で寝てたのだけど、コンクリ造なので底冷えして見事に風邪を引いた - 床からの冷えは予想以上にくるので、スリッパなりマット敷くなりして対策したほうが良い ## 電車問題 - 4月は上京して慣れない人が多いので電車が遅延しまくる - 出社する人は特にだけど、4月の電車は遅延のオンパレードなので気をつけたほうがいい - 10分20分遅れがザラにある - 5月入るとおさまってくる - JRが各駅のピークタイムを出してるので、出社時間を決められるところはそこを避けた時間に乗ると快適に通勤できる - ピークタイムだけの定期券というのも売っていて、割安で買えるのでピークタイムは使わないと確定してるならあり ## 自炊問題 - 毎日自炊してる - 自炊のコツは「諦めること」 - いかに面倒な作業を外部にオフロードするかにかかってると思う - 包丁を極力使わないのも有効な手段 - ただ、カット野菜はコスパが良くないので、煮てあるジャガイモとかそういう場面で使ったほうが調理時間を削減できる - 良い炊飯器買っとくと上手い白米が食べられて精神面でプラスになる - 底が深いタッパーを複数個買って、多めに作った野菜炒めを1週間食べる運用をしている - わりと山梨帰ることが多かったので、作り置きは少なめにしてた - 週を跨ぐ作り置きは基本作らない方針でいる(食べるのに抵抗が出てくるため) - ぶっちゃけ節約できてる実感がないので、本当に食にこだわりが無いなら惣菜でも良いと思ってる - 僕は多分耐えられないのと、単純に作るのが好き(ここに来て母の遺伝が出てきてしまった)なので自炊は続けると思う - 夏はサラダ、冬は鍋作るのが良い - ピルクルのデカいやつ(1L)飲んどくと睡眠の質が結構変わるのでオススメ - 一番効くのはヤク1000だけど、費用対効果考えるとピルクルが良かった - ただし、同程度の効果を得るにはヤクの2倍の量飲む必要があるので、そこは個人の好みに寄りそう - 最も費用対効果の高い主食は米なので、こだわりが無いなら主食は米にするのがオススメ - 米は国産かつ無洗米にすると良い - ケチって外国産の米を買った時一月ほど大変だったので、米はケチらない方がいい ## ゴキブリ問題 - ちゃんと掃除しよう - 特に水回りは最低2週間に一度はやったほうが良い - ゴミ捨ては部屋に溜まると狭くなるしダルいので、前日の夜に出すなりして出し忘れないようにしたほうが良い - ゴキジェットとブラックキャップ買っておけば間違いないはず - ブラックキャップの有効期間は確か半年なので、半年に1回は交換しよう ## 金問題 - 多分みんなエポス入ってると思うのでそれ前提で書く - クレカにこだわりが無いなら支払いをエポスに集約したほうが良い - 始めはUFJ使ってたけど、枠が小さいので旅行等出費が多い時に致命的になることがある - 去年のYAPCで福岡から帰れなくなるところだった - 1年目なら貯金はそこまで考えなくても良いと思っているけど、僕が能天気なだけなので参考にはしない方が良いかもしれない - 毎月ライブ生活とかしてもまぁ大丈夫なので大丈夫でしょう ## 回線問題 - 家の通信回線はJCOM入ってるところ多いと思う - 普通にJCOMで良い - 無料で使えるし、そこまで帯域狭そうな感じもしない - 僕はBIGLOBE契約しちゃったので使ってないけど、折を見て乗り換えたいところ - 携帯回線はKDDI系列が良い - 山梨はドコモが強いけど、東京だと厳しい - 別に山梨でもKDDIは使える - UQの30GB/月のやつを使っているけど、繰り越しが出来るのと、契約が月の終わりだったので毎月60GB使えてる(そこまで使ってない) - 始めはpovoなりでチマチマチャージしながわ使ってみて、自分が普段どのくらいデータ通信使うか見積もってみるのは悪くないと思う ## テックイベント - 行け！とにかく行け - 今からconpass見て明日開催するイベントを検索してすぐ申し込みしろ - とにかく行け - 上京したメリットと家賃の元を取る勢いでイベントに参加しろ - 参加するにあたっての注意点は全部書いたけど、読む前にとりあえずイベント参加を申し込め - さっさと申し込め https://comamoca.dev/blog/2025-09-04-go-to-the-event/ ## 電気消し忘れ問題 - スマートリモコン買って解決した - 物によってはAPIが使えるので、ガチャガチャいじれて楽しい - 最新はopenclawに部屋の照明とかエアコンを操作させてる - 最近はテキストエディタからエアコン操作してみたいと思ってる ## 免許問題 - 更新・住所変更マジで面倒なのでさっさと済ませたほうがいい - 免許センターは鮫洲が回転速度速いのでオススメ

devenvやめたい

Thu, 19 Mar 2026 00:00:00 GMT

devenvを使うのをやめたいと思ってるので、その理由と今後の対応とかを書いてみる。 ## 動機 `nix update`した時に走るビルドのコストが無視できないレベルになったから。それに追加して、devenvのCLIをそこまで使ってなかったので、割に合わないなと感じることが多かったから。 devenvはyamlからflakeを生成して再現可能な環境を作るツールだけど、flake-partsを使うと直接flake.nixから使える。この場合はdevenv CLIを使わずに、直接flakeのinputとして扱う。また、`devenv up`でprocess-composeを使ったサービスの起動ができる。個人的にはこの用途でdevenv CLIを使うことが多かった。あと言語などのバージョンを"0.14.0"みたいに指定できるので、その機能もよく使っていた。ただ、この機能に関してもそこまで必要性を感じなくなってきた。 ## じゃあどうするのか ### サービスの起動 [services-flake](https://github.com/juspay/services-flake)を使う。これはprocess-composeをwrapしたnix moduleで、実はこっちの方が対応しているサービスが多い。サービスを定義して`nix run .#myservice`みたいに実行すればprocess-composeが起動する。 ### バージョン指定 2026/3/19 追記:

悲しいことにNix package versionsは更新が途絶えてます...
今だとhttps://t.co/4YLbyGloPrで調べると良いかと思います

↓ここで紹介している、nix-versionsというツールも良さげです
CLIにてパッケージバージョンごとのNixpkgのリビジョンを検索できますhttps://t.co/71ngM90B1G
— ryu (@ryu_trifolium) March 19, 2026

[@ryu](https://x.com/ryu_trifolium)さんがNix package versionsの更新が停止していることを教えてくださった。ありがとうございます。代替としては[nix-versions](https://github.com/vic/nix-versions)が良さそう。追記終わり直接指定する。ただ、楽をする方法があって、[Nix package versions](https://lazamar.co.uk/nix-versions/)を使う。(nixpkgs ukとかで検索すると出てくる) これは特定のバージョンのパッケージが存在しているnixpkgsのcommit hashを検索するサイト。このサイトでnixpkgsのhashを検索して、そのnixpkgsをinputsに指定、対象のパッケージを呼び出せば良い。 nixpkgsは複数存在しても良いため、この方法を使っても従来のnixpkgsは使用できる。もう一つの方法として、overlayがある。例えばPythonの場合は[nixpkgs-python](https://github.com/cachix/nixpkgs-python)がある。もっといえば、このoverlayはdevenvの内部で使用されている。 overlayを直接使用することで依存が減り、nixのビルド時間も削減しつつdevenvで享受していた利益をほぼそのまま受けられる。 ## まとめ devenvをやめる理由と、devenvを使わずにそれと同じ開発体験を得る方法を書いてきた。既にオレオレNixテンプレートリポジトリ[scaffold](https://github.com/Comamoca/scaffold/)ではdevenvを一部削除している。今後もflake.nixでdevenvを見つけ次第削除していきたい。今回の一件でnix前提で開発ツールを作る際はRustのビルド時間が結構重くのしかかってくると感じたので、もし僕が開発ツール作る際はGoかPythonを使っていこうかなと思ったりしている。

あの日の話

Wed, 11 Mar 2026 00:00:00 GMT

毎年この日になると当時のことを考えているので、今年はちゃんと文字にしておこうと思う。 ## 震災当時震災にあったのは幼稚園が終わって帰宅して、おやつを食べる前のことだった。当時はアナログ放送から地デジへの移行期間で、家のテレビはまだブラウン管だった。アナログ放送からデジタル放送への移行期間中だったので、ただでさえ狭い4:3の画面が、移行を促すメッセージでもっと狭くなっていたのが懐かしい。当時は専業主婦だった母と、幼稚園が終わった後おやつを食べながら相棒を見るのが日課だった。その日もおやつを準備していたところに緊急地震速報が鳴って、すぐにグラッと揺れが来た。テーブルが近くにあったので、母と一緒にその下に潜り込んだ。震度4。思えばそれ以上の揺れにあったことは今もない。母が取り乱していたのが印象的だった。その半面、自分は妙に冷静だった。というより、不思議なほど現実感がまったくなかった。ブラウン管に映る、黒い波に覆われていく海岸沿いの映像を見ても、よくできたCGとしか思えなかった。現実感こそなかったものの、震災の前後で日本に漂う空気が明らかに変わったように感じる。震災前は学校で鉄腕ダッシュやイッテQの話をしてゲラゲラ笑っていたのに、震災後はとてもそういう空気じゃなくなった。自粛ムードと計画停電、周囲の大人たちのピリつきもあったと思う。 15年経ってそれなりに薄まったけれど、今でもこの時期になると、空は晴れてるのに心なしかどんよりしているような、あの空気感をどこかで感じている。 ## 修学旅行コロナで沖縄行きがおじゃんになって、代わりに岩手に行くことになった。正直「岩手か……」とあまり乗り気ではなかった。行ってみた感想として岩手県はとても良かったし、東北の他の県にも行ってみたくなった。ただバスで山梨〜岩手間はしんどかった。6時間程度バスに揺られてたのだけど、これはほぼ山梨〜京都間と同じ距離。次があるなら新幹線か飛行機にしたい。その修学旅行で、津波の被害にあった校舎を見学することになった。泥と砂だらけの教室に入ったとき、ふと足元に落ちている教科書が目に入った。泥だらけのまま落ちていた。それが、自分たちが普段使っているものと同じ教科書だと気づいたとき、これまで「スクリーン越しでの出来事」としか捉えられなかった震災が、初めて実際に起こった出来事なんだなと、12年越しに現実として受け止められた気がした。 ## 15年経ったあれから15年経った。実感のブラウン管は液晶テレビになったし、デジタル放送への移行もした。ネット接続はADSLからフレッツ光になったし、住む家も場所も変わった。当時年長さんだった僕は社会人になって働いてるし、当時赤ちゃんだった人は高校生になって家の前を通学している。 15年も経つと記憶も薄れる。それでも、あれから毎年この日になると、あの海を望む校舎で見た、泥だらけの教科書のことを思い出す。

開発環境現状確認 2026

Mon, 23 Feb 2026 00:00:00 GMT

![](/img/2026-02-09-020328.png) 普段作業している机。最近の記事やらプログラムやらはここか実家のリビングで生まれている。 ## 物理 ### 机： IKEAのデカいやつ実家の頃から使っているIKEAのデカい机(竹製)を使っている。幅が150cm位あるのでデカいディスプレイと本を置けてなかなか便利。引っ越しの際に机の下にしまう用のキャビネット(これもIKEA)も貰ったのだけど、相性が良くて便利に使っている。 ### ノートPC: DynaBook 学校で貰ったやつを後生大事に使っている。メモリ16GBとSSD1TBを増設してRAM28 SSD1TBにしている。Nixはストレージを食う事で有名だけれど、この構成で困ったことは現状ないため、Nix使うときはストレージを1TB用意するのがオススメ。 ### キーボード: HHKB Studio 移動することが多いので、ジョイスティックのあるモデルを買った。実際マウスなしでも問題なくなったので外での作業がやりやすくなった。ただ、キーボードがノートPCより重いため、持ち運んでると若干虚無になる。個人的にキーリマッパーの役割はキーボードが担うべきだと思っているので、HHKBにはかなり満足している。 ### ディスプレイ: EIZO アキヨドで買った。デカいのと解像度が高いので作業がしやすくて助かっている。長時間見ても目の疲れがたまりづらいのも良い。ディスプレイの下にアクスタとフィギュアを置いていて、ディスプレイが邪魔になりつつあるのでモニターアームを買いたいところ。 ### スマートリモコン: Nature Remo 3 上京してわりとすぐに買った気がする。部屋の電気を付けっぱなしで寝落ちすることが多く、睡眠の質が悪くなっていることに悩んでいたことが切っ掛けで購入した。勝手に電気を消したり、朝暖房とか冷房を付けるようにしているのだけど、そこそこ生活の質が上がって満足している。あと、実家帰った時に「あれ、エアコン消したっけ...」と不安に苛まれることがなくなった。 ### アクスタ/ぬいぐるみ/同人誌実家の頃はあんまりおっぴろげられなかったけど、一人暮らしするようになってから堂々と机に置いている。直接作業効率が上がっているわけではないけれど癒し効果があるらしいのでよし。 ### 炊飯器: 虎印の良い感じな炊飯器上京の折に購入した。まぁ白米は美味く炊けた方が良いよな、ということでちょっと値段が高めのものを使っている。これもあってか、基本的に毎日自炊をして生活出来ている...僕の中で美味いメシが食えることは人生において結構優先度が高いので、高めの炊飯器買って良かったなと。上京してすぐの頃帰省したら、炊飯器が家と同じモデルになってたのはちょっと面白かった。7年くらい使ってたのでちょうど良いタイミングだったのかなと。 ## ソフトウェア ### OS: NixOS 1年くらい継続して使用している。動作が比較的安定しているのと、ロールバックが容易な点が気に入っている。 ### エディタ: Neovim/Emacs 去年辺りからCommom Lisp書くためにEmacsを触り始めた。今ではメインの作業をEmacsでやるようになっている。この時期にNixを使い始めたこともあって、Emacsの設定自体Nixが前提となっている。 flake.nix等軽微な設定ファイルの修整にはVimを使うことが多い。 ### DE: Sway/Niri マルチディスプレイにおいてniriが安定しないのでSwayと併用している。最近はちょっとずつNiriが安定してきているので、だんだんNiriに軸足を移していこうかなと。 Niriは横スクロール方のタイル型WMで、無限に幅のあるディスプレイを使っているような感覚で作業が行えるのが唯一無二だなと思ってるけど、このタイプのUIを持ったDEは他にも存在しているらしい。普段はブラウザとターミナル、Emacsを別のワークスペースで起動して、ブラウザを見る度に都度ワークスペースを切り替える運用をしている。ウィンドウのワークスペース間の移動自体はショートカット一つで済むので大したコストじゃない。 ### ターミナル: Foot https://codeberg.org/dnkl/foot ターミナルはFootを使用している。元はIME用[^1]だったのだけど、今は全てのターミナルでFootを採用している。このターミナルの優れているところは兎に角起動が速いところで、それもあってIME用として採用していた。作業用のターミナルにはkitty使っていたのだけど、tmuxの導入をした際にタブ機能がターミナルに必要ないことに気が付いたので、それを機にFootへと移行した。現状機能不足になることもなく、満足して使えている。そもそもターミナルはCUIで作業を行う場所であって、昨今のターミナルが持っているようなモダンな機能はあんまり必要ないんじゃないかなと思っている。個人的にはurxvtくらいまで軽量化したいけど、一から自作するのは面倒なのでlibghosttyとか使っていつか自作できたらなと思ったり思わなかったり。 ### ターミナルマルチプレクサ: tmux 実はここ最近まで使ってなかったのだけれど、claude codeが流行ってるのもあって使い始めた。特に設定はやってなくて、ghqでリポジトリ開いたら対応したパスでtmuxウィンドウが開くのと、C-tでpaneが開くようになってるくらい。なんならprefixなしで操作できるようにしている。個人的にこのあたりの設定には特に興味がないので、まぁ概ね満足できている。 ### テーマ: catppucin かれこれ数年はこのテーマを使用している。サポートしているエディタやツールが多いので設定が楽で良い。ブートローダのテーマまでサポートしているので一貫性を保てるのも良い。フレーバーはずっとmochaを使っている。ベースの背景色が一番目に優しいのと、色の取り合わせが一番好みに近いと思っている。 ### 本人確認基盤: Keyoxide Keybaseからログイン出来なくなったので移行した。始めは取っつきづらさがあったが、基本gpgしか使わないため、長期的に見た際の運用負荷はこちらのほうが少なそうだなと感じた。また、アカウントという概念が薄いので、秘密鍵さえしっかり管理すれば、Keybaseのようにアカウントから締め出されてしまうことが少ないと感じている。このあたりの扱いはNostrと同じ感じなのでその点も馴染みやすさに繋がっていると感じている。 proof周りの作業方法で手間取ったので、後で手順をまとめたい。特にGPG鍵のnote機能を使用して本人確認を行うのは、普段GPGを直接触ってこなかったから始めは上手く馴染めなかった… [^1]: [Vim を IME として使いこなす](https://zenn.dev/vim_jp/articles/14ab6ea83f711a)

Hono Hackathonに行ってきた

Thu, 12 Feb 2026 00:00:00 GMT

Hono Hackathonお疲れ様でした！！ #honohackathon pic.twitter.com/5PPKu1Y1C8
— Yusuke Wada (@yusukebe) February 11, 2026

Hono Hackathonに行ってきたのでその感想を書いていく。今回のハッカソンはアプリケーションを作るというより、Honoとその周辺ライブラリの開発に着目したイベントとなっていて、参加者は実際にHonoとその周辺ライブラリにPRを作成した。始めにyusukebeさんが今回のイベントの説明と今日捌きたいissueを挙げて、参加者はそれらのissueのうち担当したいものを選んで取り組むという形で行われた。 PRを作成したらその場でyusukebeさんによるレビューが行なわれて、確認が終わったらその場でmergeされていた。こういうオフラインならではのスピート感はなかなか見られないので面白いなと思ったりした。 ## 実際に作成したPR 実際に作成したPRは以下。(テスト書き忘れたので後で追加する) https://github.com/honojs/honox/pull/357 このPRはHonoXプロジェクトを本番ビルドした際に、islandではないコンポーネントに包まれたislandコンポーネントがハイドレーションされないという問題を修正するPRになっている。 issueはこちら https://github.com/honojs/honox/issues/355 僕の方は、HonoX関連のissueに取り組むと決めたは良いものの、どのissueが良いか見極めきれずしばらくissueを物色していた。ここで結構時間使っちゃったので、次回がある時は予めアタリは付けといた方が良かったなと。 HonoXのissue担当した人は3人いたのだけど、担当するissueがバッティングしないよう、ある程度取り組むissueに目処が付いた段階で他の2人に声をかけて、担当issueの擦り合せをした。実際の作業について、まずissueにあるような問題が再現するかローカルにプロジェクトを作成して実際に動作を確認した。問題が再現したので原因を探るべく、ソースコードを読んでいった。この時にClaude Codeが結構役立ったので、ありがたいな～と思ったり。問題は本番環境かつisland関係なので、そのあたりのコードに原因があるのだろうとアタリを付けつつコードを読んでいった結果、`walkDependencyTree`という関数においてパス解決の際に使用する基準となるファイルが異っていることを発見した。 forkしたHonoXをローカルにcloneして、該当箇所を修正、問題を再現させたプロジェクトにて修正したHonoXを読み込ませて再度動作確認を行ったら問題が修正したのを確認できた。今回は`package.json`にて`file:`を使って修正したライブラリの指定を行ったのだけど、正直これが正解だと思えてないので、問題を特定するための最小構成プロジェクトの作成だったり、修正したパッケージの動作確認とかについて懇親会で聞けば良かったなと若干の後悔がある... ## 開発環境開発自体はEmacsでやろうとしたのだけど、最近Emacsでコードを書くと重くなる現象に悩まされてた[^1]のでNeovimで行った。 Neovimで開発するにあたって、LSPとGit、コーディングエージェントまわりの設定をしておいた方が良いなと思ったので、その調整とかをやっていた。多分これに1.5時間くらい使ってたので、家でやっとけば良かったなと幾許かの後悔がある。とはいえこういう時の設定が一番捗るんですよね...

honoxのバグ直しながらneovimの設定いじってるけど、こういう時の設定いじりが一番捗るんだよな
— こまもか🦊@シャニ∞th両日 (@Comamoca_) February 11, 2026

導入したプラグインは以下。 - [snacks.nvim](https://github.com/folke/snacks.nvim) - [neogit](https://github.com/NeogitOrg/neogit) - [nvim-aibo](https://github.com/lambdalisue/nvim-aibo) snacks.nvimはNeovim界隈で有名なfolkeさん作のプラグイン集で、mini.nvimに近いプラグイン。僕はpickerとscratch bufferだけ使ってたけど、他の機能も便利そうなので使ってみたい。 neogitはEmacsのmagit likeなGitクライアントで、Emacsではmagitをよく使ってたので導入してみた。操作感がmagitそのままだったのでこれからも使っていきたいところ。 aiboは周囲が良いと言っているのを聞きつつも触れてなかったので導入。バッファにClaude Codeが表示されて、insert modeに入ると画面下部にポップアップが表示される。このポップアップに文字を入力して`:wq`するとClaude Codeに入力が渡される仕組み。入力以外の操作は従来のバッファと同じなので、普段から慣れてる操作を一通り行なえる。使った感触はめちゃくちゃ良くて、Neovimとコーディングエージェントを融合させる手段として一番良いのではないかと思っている。 ## まとめ今回は小さい変更とはいえ始めてHono関連のリポジトリにPR投げれて良かった。 HonoX自体はリリース初期に触って以降あまり見れていなかったのだけど、今回PRを投げるために色々触って浦島状態だったのと、実用性が上がっていると感じたので今後機会があったらまたいじってみたい。あとNeovimの設定も結構捗ったのも嬉しい誤算だった。コントリビューター向けのハッカソンイベントは今回参加してみて得られるものが多かったので、Honoに限らず今後もっと増えてくれれば良いなと。 [^1]: 恐らく描画まわりだと思うのだけれど、原因は未だに分かっていない...

SSGがしんどくなってきたかも

Wed, 04 Feb 2026 00:00:00 GMT

念のため言っておくと、これはLumeが悪いというよりJS系のSSGもといSSGという形態の限界、あるいは自身の求める機能に似わなくなってきたからだと思っている。 --- このブログは[Lume](https://lume.land/)で構築していて、かれこれ2年くらい運用している。 Lumeの前はAstroで作っていて、その時作ったデザインをJSXそのままに移行して使っている。 Lumeに移行した理由は、正直Astro程機能がなくても良いなと感じたのと、Denoが好きだったから。 Astroから移行を考えてた時は、ビルド時間が今後伸びることも考えていたので、HugoだったりZolaだったりも検討したのだけど、JSXで作ったページデザインを移植するのがめんどくさそうでJSに絞って探していた。その時の結論としては、「まぁSSGがつらくなったらその時に考えよう」だったのだけど、最近になってついにその時が来たなと感じている。現状、このブログのビルドには5分程度かかっていて、うち3分程度がLumeのビルドになっている。なんでこんなにビルド時間がかかっているのかと言うと、単純に記事数が多いのとgzipやbrotli圧縮等の最適化、あとはOGPの生成なんかも都度行ってるからで、現状600程度のファイルを生成している。極めつけに、ローカルで起動すると毎ビルドに3分程度かかっていて、開発や記事のプレビューに待たされえることが多く、普通に開発体験が悪いと感じる機会が多くなってきた。ビルド時間については依存をキャッシュするなどして1分程度縮められはしたけれど、肝心の生成しているファイル数の数は減らないので、そこを上手いこと削る必要はあるかなと思っている。削れそうなファイルについては目星が付いていて、gzipやbrotliについては、Cloudflare側で生成できそうなのでそちら側に任せてLumeでは無効化、あとOGPについても動的な生成に切り替えれば多少は生成するファイルも少なくなるかなと。どうしてもビルド時間が長くなる場合は一度[Lume CMS](https://lume.land/cms/)に移行して、アクセス毎にページを生成する方向にしようとは考えているけれど、多分Deno Deployでデプロイすることになるし、hackyな自作プラグインを突っ込んだりしてるので正常に動いてくれるかは不明... あと、このブログの検索機能はPagefindっていうSSG向けの検索エンジンを使用してるのだけど、これがCloudflareのRocker Loaderを有効にすると壊れる問題があったりする。これは自作の記事検索APIを作って、GleamベースのUIを埋め込む形でリプレースすることを考えてる。なのでPagefindからは移行する予定だけど、置き土産としてCloudflareで発生する不具合については調査してPR投げても良いかなと。まぁ最悪の場合はJSXを捨てて、GleamベースのSPAアプリケーションに書きなおそうかなと思ってるし、ゆくゆくはそうなる可能性が高いかもしれない。 SSG自体、パフォーマンスと引き換えにデプロイ時に負担がのしかかってくるので、記事が増え続ける限りビルド時間の問題は解決しないだろうな〜式年遷宮は多分するけど、どうやるか、どれを使うかは色々考えていきたい。一応検索機能については先行して実装しそうなので色々考えがあって、[DuckDB FTS](https://duckdb.org/docs/stable/guides/sql_features/full_text_search)ベースの検索システムになる可能性が高そう。 FTSってのはFull Text Search(全文検索)の略で、DuckDBはC++で書かれたOLAP向けのDB。 FTSだしOLAP関係ないじゃん、とは思ったけど、DuckDB自体に前々から興味があったので、この際触ってみるのも良さそう。全文検索にあたって避けられない形態素解析は、個人的に気に入っているgoyaをベースにしたいと思ってる。 goyaはRustベースの形態素解析器なのだけど、シンプルで使いやすいのでなにかと使うことが多い。全体の流れとして、GH Actionsで記事のインデックスを生成してDuckDB向けのバイナリを生成してR2へアップロード、フロントではインデックスを落してきた後、検索ワードをフロント側のgoyaで分かち書きしてクエリをかける方向を考えている。 goyaはRust製ということもあってwasmも提供しているため、CLIからもブラウザからも使いやすいのが良い。検索APIについては自作Web FWの[hinoto](https://github.com/Comamoca/hinoto)を使って構築しようと考えている。そもそもhinoto自体Cloudflare workersを前提として設計したし、作るだけじゃなくてドッグフーディングして改善のサイクルを回したいと思っていたので丁度良いと思っている。現時点ではR2向けのインテグレーションが作れてないので、まずはそこから作っていくことになりそう。とまぁこんな感じで久々にブログに手を入れようかなとか考えてるけど、やっぱこういうの考えるのは楽しいな〜って思うので、楽しみながら式年遷宮やっていきたい。

Niriで外部ディスプレイを繋ぐとクラッシュする問題

Thu, 22 Jan 2026 00:00:00 GMT

あけましておめでとうございます！今年もよろしくお願いします。 --- 最近はNiriっていうイカしたDEを使っているのだけど、これが外部ディスプレイを繋ぐとクラッシュして外部ディスプレイに何も映らなくなった。症状はこんな感じ。 - HDMIケーブルを抜き差しすると画面が映らなくなる。 - wdisplays確認するとモニター自体は認識されている。 - マウスカーソルは映らないモニターにも移動できる。 Claude Codeシバいて色々試行錯誤したのだけど、僕の環境だと以下の2つを設定したらとりあえず動作が安定した。 - ユーザーをvideoユーザーグループに入れる - no-csdを無効化した(ウィンドウ名の表示を消したりしてると有効化されている可能性がある) 関連するissueとかもあって深掘りしてみても良いのだけど、とりあえず安定動作が先決なのでワークアラウンドだけ書いてみる。追加で情報があったらここに追記していくかも。参考まで、にClaude Codeに書かせたレポートも貼ってみる。 https://gist.github.com/Comamoca/2baa860a7245448688b3e40b8c01d0c5