かわいい駆動生活。

nixbuildのススメ

Tue, 04 Aug 2026 14:04:11 GMT

## 3行まとめ - nixは羃等性のあるビルドができる - nixには組み込みで羃等性のあるビルドができる特性を活かしてリモートのマシンでビルドを代行できる機能がある - リモートでnixレシピをビルドするマシンを提供するサービスとしてnixbuildが便利 ## Nixのビルドは重い(時もある) Nixはその性質上、基本依存するパッケージを全てビルドします。よく使われるパッケージはnixpkgsなどでcacheが存在しているため、ビルドをスキップできます。しかし、Rustで書かれたパッケージなど依存をキャッシュしていてもビルドが重いパッケージなども往々にして存在します。そんな時に使えるサービスとして[nixbuild](https://nixbuild.net/)が使えます。 ## nixbuildについて Nixには[Remote Builds](https://nix.dev/manual/nix/2.18/advanced-topics/distributed-builds)と呼ばれる仕組みが存在します。このRemote BuildsはNixのビルドを手元ではなく、リモートマシンで実行することにより手元でのビルド負荷を軽減できる仕組みです。 Nixは純粋関数型パッケージマネージャなので、**どのマシンでビルドしても同等の結果を受け取れる**という性質がよく活きている機能ですね。また、nixbuildはマトリックスビルドに対応してるので、darwin向けのビルドもLinux向けのビルドも特別な設定を必要とせず行えるというメリットもあります。 ## 使用方法利用にはメールアドレスとSSH、PayPalのアカウントが必要です。後述しますが、PayPalのアカウントは住所を登録する必要があります。**住所が登録されていない場合サービスが停止されます**。まず以下のサイトにアクセスしアカウントを作成してください。 nixbuildは認証にパスワードではなくメールアドレスを使用するため、サイトにパスワードを設定する必要はありません。(最近こういうサイト増えましたね…ありがたい) アカウントを作成した後は設定画面から公開鍵を登録してください。 nixbuild側の設定が終わった後はNixOS側も設定します。設定方法については[公式ドキュメント](https://docs.nixbuild.net/getting-started/#nix-configuration)に書いてあります。英語ですがこれ読めば多分設定できるはずです。分かりづらい点があったら後日追記します。 ## 料金について毎月24CPU時間のクレジットが付与され、クレジットを使い切ると従量課金で請求が始まります。料金はユーロで請求されるので支払額は為替の影響を受けますが、請求のあった月は800円くらい取られた気がします。毎週NixOSの更新をしてこの額なので結構お安いなと思ってます。また、NixはHashが同一の場合はビルドを行わないので、無駄にビルドをして料金が嵩むといった現象が起こりづらいため、その点も料金が最適化される要因かなと思ってます。 ### 料金の確認方法料金の確認方法ですが、なんと**SSH経由で確認する必要があります**。 **ユーザーを信頼しすぎだろ**…と思いますが慣れると結構使いやすいです。まず以下のコマンドでnixbuildにSSH接続します。対象のアカウントはSSH公開鍵を指定したアカウントとなります。 ```sh ssh -T eu.nixbuild.net ``` よく使いそうなコマンドを以下に書いてみました。 ```sh usage # リソースの使用量を確認する builds list # ビルド結果の一覧を表示する billing info # 料金を確認するためのPayPalページのURLを表示する token create # nixbuildへアクセスするためのAPI Tokenを作成する ``` ## 注意点 ### PayPalの住所は設定した方が良い利用には住所の確認が必要(決済の都合上必要とのこと)なのですが、PayPalのアカウントに設定されているものを参照するため、PayPalに住所が設定さていない場合はしばらくして**サービスが停止されます**。これを会場するにはnixbuild運営に**英語で住所を記載したメールを送信する必要があります**。これがまぁ〜面倒なのでみなさんは登録する前にPayPalに住所を登録しておいてください… ### 機密情報を含むコードは`--builders ''`を指定した方が良い nixbuildはリモートサーバーで実行するという都合上、全てのNixパッケージのビルドがリモートマシンで行われます。つまり**ソースコードを含む情報が問答無用でサーバーへ転送されます**。しかもビルド結果はキャッシュされます。うっかり社内のソースコードを送ってしまった日には社内SEの顔面が真っ青になりますね… ソースコードが送られると書きましたが、厳密にはDerivationを生成するためのClosure[^1]という単位でサーバーへ情報が送信されます。また、いちいち`--builders`オプションを指定したくない場合は以下の環境変数を設定することでビルド時に外部マシンを使用せず全て手元でビルドしたい場合は`export NIX_CONFIG='builders ='`を指定してください。 direnvでは`~/.config/direnv/direnvrc`にbash関数を記述することで複数ディレクトリを対象に環境変数を設定できます。以下はghqを想定して複数プロジェクトに`NIX_CONFIG`を設定する例です。 ```sh load_nix_config() { local ghq_root ghq_root="$(ghq root)" # nixbuildの対象外にするリポジトリ一覧 # サブディレクトリが対象になるのでユーザ名を指定するとユーザー単位で無効化される local repos=( "github.com/user/name" "github.com/userA/" ) for repo in "${repos[@]}"; do repo="${repo%/}" if [[ "$PWD" == "$ghq_root/$repo" || "$PWD" == "$ghq_root/$repo/"* ]]; then export NIX_CONFIG=$'builders = ""' return fi done } # 定義するのは単純なbash関数なので実行する必要がある load_nix_config ``` ## まとめ今回はNixのビルドサービスnixbuidについて紹介しました。このサービス個人的に結構気に入ってるので、日本でも広まって欲しいな〜と思ったのと、これがNixを導入するメリットの一つになってくれれば良いなと思ってます。この記事では触れませんでしたが、nixbuildにはcacheのアップロード先の登録が可能で、cachixと連携ができたします。このあたりを活用すれば、規模の大きめな開発でもより安定してnix cacheを提供できそうで使い道が広がりそうだな〜と思ったりしてます。 [^1]: [Closures - Zero to Nix](https://zero-to-nix.com/concepts/closures/)

iの栖を読んだ

Sun, 02 Aug 2026 15:16:00 GMT

## 総括タイトルに「i」と付くようにわりと8thを意識して作られたコミュなのかなと思った。舞台を「有限性のあるもの」と捉えて、そこに向かって向き合っていくアイドル達の想いが描かれているコミュだった。そういうばあんまり円香が出てくるコミュを読んだことがなかったのだけれど、今回のコミュで株がめちゃくちゃ上がってるし天塵も読むか〜と思ったり。全体感想としてはシャニマスのコミュでは珍しく全部言ってくれたのと、今年のテーマを象徴するコミュだったなと感じた。 8thの後に高山Pが今年のテーマがL∞veであることを話されていたけど、その際に「あらゆるものは有限だが唯一愛だけがは無限」という話をされていて、個人的にはこの「愛」にかかるものの一つとしてライブという体験があると思ってる。ライブは例え同じ人が同じ内容のものをやったとしても、一つとして同じ舞台ではないし公演が終わってしまったらそこで現実から形が消えてしまう。でもライブを見た人の記憶、その時に動かされた心は本物だしその感情はずっと続いていくものだとも思っていて、それが先述した「愛」と呼べるものなのかなと思ってる。今回のコミュでは舞台だけれど、本質はライブと同じで同じ舞台は二度と見れないけれど、それを大切に思う感情、コミュの中では「愛おしさ」と呼ばれているものは舞台が終わったあともずっと続くよねって思ったりした。今回のコミュではその愛おしさや「愛の無限性」を283のアイドルが認識するという点でも大切なコミュなんじゃないかな〜と思ったりした。 sand songもそうだけど、今年のシャニマスのコミュはテーマをストレートに描くものが多くて、すっと頭に入ってくるので良いなぁと。 ## 実況以降はコミュ見ながら実況っぽく追記したやつ。僕が後で読み返す用に残してあるだけなので、正直読む価値そんなにないので読む必要はない… - 初手「シャニマス」な状況になっておぉとなった - アニメの2.5次元舞台とかあると微妙な気持ちになるやつの逆の立場にさせられるの結構苦しいな - っていうか以前にも事務所全員出演するゲームとかCM出してたりするし、その点を踏まえての反応の可能性は多分にありそう - 思えばベリソのゲームもCV全員283だしな - 聞きずらいことをズバっと聞いてくれる円香めちゃくちゃ頼もしい - あさひと一緒に探検する咲耶さんかわいい - この組み合わせ意外だったけどかなり相性良い？ - 何気に「アイドルの役の上に更に役を重ねる」って高度なことやってるよな… - 「連絡してみたら？」ってさりげなく言える円香良い... - 水紅の「聞いた音を模倣する力」ってかなり円香じゃん…！[^1] - 「真珠の栖」のテーマは教えてもらえないって話だし、お前(視聴者)も一緒に考えろってことなんだろうな - 真乃と円香って意外と見ない組み合わせに見えるけど、案外愛憎良いのかも知れないな…！ - 登場人物の名前が「真珠」とか「白檀」とか物の名前なのはやっぱ意味があるんだよな - 何気にキャスティング結構合ってる気がするんだけど(当たり前)それって外の人間からは見えないしな… - でもこのキャスティング283のオタク脳破壊する組み合わせしてるよな - じゅりまなはあります - SNSの反応の解像度がシャニマス〜！すぎる - まぁだからこそ見てて苦しいんですが… - ちゃんと思ってること言ってくれる円香本当に頼もしいな - 演出家のせいでは？→それは本当にそう - 三峰の「任せてよ！」は本当に頼もしくて良い - っていうか咲耶さんは過去に一度ミュージカルやってる[^2]のか…経験者いるのは頼もしいな - 三峰→あさひの呼び方って「あさたん」なんだ - 咲耶「人との繋がりを求めているところに共感できるかな」←おわあああああ！ - 三峰→樹里の呼び方って「じゅりちー」なの！？ - 円香〜！三峰〜！二人ってめっちゃ気が効くよな - 円香の真珠の栖に対する解像度めっちゃ高いじゃん… - テーマの話来たわね - 過去の講演を見ずにイメージ作るの難しそう - 演出家が過去の講演のイメージに影響されて欲しくないから貸さないかも - ↑多分この理由で貸さなかった？(合ってた) - この手のはありのままをやれって言われるのが一番困るやつかもしれない - 「誰が演じても成立してしまう」←めちゃくちゃエッジ鋭いな… - 演出家『「愛しい」と思わせてください』 - おっ8thか？ - やっぱり8thじゃないですか！ - 唐突なウマストロメリア〜 - そろそろ寮生活が終わる←真乃がこの日々を愛しいと思った - シャニマスですね〜 - 「終わり」に対する姿勢の話がここで出てくるのか - ライブもそうだけど、舞台も一度として同じ舞台はないし、その点では有限性のあるものなんだな - sand songを思い出した - 舞台の上の生き様が鮮烈に観客の心を惹いて留まり、「愛」となったらそれはきっと……限りのないものなんだろう - キター！ - 今年のテーマはL∞VEだしなぁ - 円香「……私は、『水紅』が嫌い」 - これやっぱ水紅のこと羨しいって思ってるのかな - 感受性豊かだし思うところはありそう - 最終話のタイトル「∞」だしやっぱ8thですよこれ - 真乃「お手をどうぞ」 - ほわああああ！ - 樹里「お手をどうぞ」 - うわああああああ！ - 無事第一幕終わって良かった - 「愛しい」を伝えられて良かった - テーマは「そばにある限りないもの」だったのか - 愛ですね… - 劇団が解散して二度と同じ舞台ができないけど愛で語り継がれることで誰かの心には残ってると - アイドルを起用したのは舞台と同じ有限性を持つライブをやっているからだったのかな - 最後の真乃が「私が演じた真珠はずっと私の中に残るから」とかそのあたりの話聞いて河野さんと果穂ちゃんの関係性を思いだしたりなど - 何かしら役を演じ続けてる人ってやっぱ演じている役との繋がりとかに出るものだよね〜 [^1]: ノクチル「[愛しき日々](https://www.youtube.com/watch?v=CbE9jUKM-PY)」には円香が透の歌い方に寄せて歌っているパートがあって、慣れないと聞き分けができないくらい似ている [^2]: [騎士団のヴェール](https://idolmaster-official.jp/live_event/283_Order/)

nixbuildが良い感じかも

Sun, 14 Jun 2026 15:11:30 GMT

Twitterを収益化します

Sun, 14 Jun 2026 04:01:48 GMT

6/21 追記:\ この記事を公開した後に収益化の条件を確認したところ、当分は収益化できなさそうでした...ショック！ただ、収益化は条件を達成した後に行う予定ですし、この記事はTwitterアカウントの運営方針を記したものとして残すべきだと思うので公開状態は維持します。 --- 最近Twitterのアカウントを収益化しようとしてるので、この機会にこれまでのTwitter運用とこれからのTwitter運用についてまとめてみます。これまであんまりこの手の話をしてこなかったので良い機会だなと思ったのと、単純に筋を通しておきたいというのが理由です。 ## 収益化の目的と使用用途最近イベントを開催したりしてるのですが、会場費などがかかるのでその工面をどうしようかと話してたら、Twitterの収益化を勧められたので導入してみた、というのが主な理由です。なので月3000円くらい稼げれば満足でいます。実際どのくらい稼げるのか、そもそもサブスクをペイできるのかも未知数ですが... 余ったお金はOSSの寄付に当てようとも考えています。僕は既にGleam等のOSSに寄付をしていますが、寄付金の増額や対象を増やしたりする用途に使いたいなと。個人的にマイナーな言語が好きなので、Twitterで得た収益を還元できたら良いなと思っています。また、収益が多くなった場合は僕の日本酒代にする予定でもいます。あくまでTwitterは趣味であるというスタンスを持っていたいので、あまり用途を縛りたくないというのもあります。収益で買った日本酒の感想ツイートをすれば収益二毛作とかできるんですかね... ## これまでのTwitter運用基本的に以下の方針でTwitterをやっていました。 - 基本ブロックしない - 無理に全てのリプに返信しようとしない - ネガティブな話題を極力ツイートしない ### 基本ブロックしない理由は僕がブロックされるとしょげるからです。ただ、あまりに目に余る言動をしているアカウントやスパムアカウントはブロックします。基本世の中色んな人がいた方がおもろいと思ってるので、それもあって自分の視界に入る人の多様性を減らしたくはないなと思ってるのもあります。あと僕は基本的に3アウト制で動いてるので、3回目に余る言動や行動をした場合ミュートかブロックをするようにしてます。 ### 無理に全てのリプに返信しようとしない以下のスライドはOSSに関する話題ですが、ツイートが多くの人に注目された時(いわゆる「バズった」)に同じ内容のリプが異なる人から大量に届きます。バズったことがある人は分かると思うのですが、これが**結構消耗する**んですよね。なので基本バズりそうなツイートは通知が埋められる前に速攻ミュートしちゃうんですが、後から見返してみて良いと思ったツイートには返信したりしてます。まぁこのムーブが不誠実に見えるかもしれないんですが、そもそも他者にリプをする自由が存在するなら「リプに反応しない自由」も認められるべきなんですよね。なので僕がリプをした時に反応がなくてもあまり気にしないですし、僕の中では十分筋が通った行動をしているという認識ではいます。 ### ネガティブな話題を極力ツイートしないこれは個人的に「極力他者の目に見える範囲でネガティブな感情を出さない」という信条があるので、それをTwitterでもやっています。と言うのも、ネガティブな感情は他者に伝搬しやすい(普段のTwitterを見ればよく分かりますね)からです。あと意図的に避けている話題として以下のものがあります。 - 政治 - 恋愛 - 金特に政治に関しては以前「政治家のアカウントに罵詈雑言をリプしない方が良いと思う」という趣旨のツイートをしたら **†界隈†の人** からフルボッコにされたので、投票報告以外はしないことにしてます。 SNSにおける政治の議論が忌避される現状に関しては思うものもありますが、そもそもTwitterという話題のコンテキストが落ちやすいプラットフォームで公平に議論できるものでもないので、現状しないに越したことはないとも思っています。恋愛に関しては男女論に直行しがちなので避けています。先述したネガティブな話題をしないという話と矛盾するようで申し訳ないのですが、僕は**男女論が嫌い**なので基本この話題はしないものとこの場で明記しておきます。人間というグラデーションのある存在を二元論で語るのは傲慢が過ぎると思います...あと単純におもんない... 金の話も避けてます。 Twitterで燃える話題は基本的に主語がデカいものですが、これは多くの人に関連のある話題だからです。つまり万人が逃れることができない金の話題は多くの人を巻き込み燃える可能性が高いとも言えます。なので意図的に金の話題をすることは避けています。「金、ねぇ〜」くらいの話なら許容範囲なのでするかもしれないですが。 ## これからのTwitter運用基本的に以前と変わらないです。そもそも現状の運用で満足してるので変える理由も特にないです。ただ、収益化をするにあたり自身を縛るものも増やした方が良いかなと思って、「やむを得ない場合を除き上記の運用方針を破らない」という運用の方針を増やしておこうかなと思います。やむを得ない場合というのは、あまりにショキングな話題があって、心の整理のためにネガティブなツイートするとかですね。特に一番避けたいのは、収益を目当てに連日男女論等の燃えやすい話題をツイートするアカウントになることです。 ## 長くなった長くなりましたが、僕は自身のことを根っからのインターネット人(インターネットんちゅ)だと思っているので、そのプライドをもって楽しく行動していきたいって事を言いたいです。これかもインターネット人のTwitterをよろしくお願いします。

Duolingoを150日続けている

Sun, 14 Jun 2026 03:02:13 GMT

Duolingoを150日続けてるので、その感想みたいなのを書いていきます。誕生日の日に「なんかやりたいな」と思ったので始めました。ワーホリとか興味あるし、英語力を高めたいと思ったのも大きい。正直ここまで続けられてるのが不思議なところがある。 1回2分くらいなので、帰りの電車とかでやるようにしてるのだけど、まぁ丁度良い暇潰しにはなるのでありがたい。実際やってみて、英語力がメキメキ付いたかと言われると微妙。ただ、英語への抵抗感が減ったのは効果があったなと。あと街中で聞こえる英語の意味がふわっとだけど分かるようになったのも成長を感じている。実際に会話するレベルに持っていくならシャドーイングとか英会話とかやった方が良いと思ってる。一番変化があったのは、英語に対する解像度の高さみたいなのかあと。例えば英語圏ではポッドキャスト文化が発達しているけど、これは英語という言語の特性によるものが大きいのかな〜とか。日本語という言語は複数の文字を用いて表記するけど、それ故に文章から単語が「浮いて」見える。普段日本語を読む時はその浮いている単語、主に漢字とカタカナを先読みして文章を解釈するという行為を無意識にしている...と個人的には思っている。なので日本語は一文あたりの情報量が結構多いし、それなりに書き手のニュアンスを込めることができる。対して英語は通常一つの文字しか含まないから、日本語を読む方法で読もうとするとかなり目が滑る。それもあって最近はDuolingoで基本文字を読まずに読み上げられた英語を元に解答してる。また、話す方が間の取り方や声の調子で文字より情報を詰められるので、それもあって音声媒体が好まれるのかなと。実は英語はリスニングの方が理解の負担が少ないという事を体感として感じられたのはDuolingoがあってこそだなと思っている。上の話はこのツイートがかなり核心を突いていると思う。

日本の友人へ

最近、日本語は単なる「文字の言語」ではなく、一種の「情報圧縮システム」のように感じるようになりました。

最初は、ひらがな・カタカナ・漢字の混在は単なる「複雑さ」だと思っていました。
しかし今では、それぞれが特定の役割を持った設計構造のように見えます。…
— THECULTURALLINK (@THECULTURALLINK) April 26, 2026

ある程度は成長を感じられてるのでこれからも続ける予定だし、今後は他の方法で英語の学習とかできたらなと。ぶっちゃけ海外行った方が学習の観点からははるかに良いのだけど、すぐに出来るものでもないし今のうちにやれることはやっておきたい。

テックカンファレンスに行こう

Sat, 30 May 2026 15:40:35 GMT

「テックイベントに行こう」の続編的な記事です。 https://comamoca.dev/blog/2025-09-04-go-to-the-event/ ## なんでこんな記事を書いたのかこんなツイートを見かけました。

カンファレンス行くといつも思うが、もっと若い人いっぱい来ても良くないか？

ジュニアとかなんなら大学生とか若くて優秀な人たちがもっと集結したら、また別の形の熱気が生まれそう。
— 市川達大@TECH WORLD ITエンジニア向け動画メディア (@tech_world18) May 29, 2026

これを見て個人的に思ったことを書いていきたいと思います。僕個人としても、もっと若い人[^1]にカンファレンスに来て欲しいのと、カンファレンスに参加するのはなにも参加者だけじゃないということを伝えたかったからです。 **僕はアイマスPなのでカンファレンスのことをエンジニアのライブだと思っている**のですが、運営と登壇者、参加者の愛と工夫でジョーデキ！なカンファレンスを作り上げられた時の達成感は、普段の仕事ではなかなか得られないものだと思っています。この記事を読んでそんなカンファレンスという場に行くことに興味を持ってくれたら嬉しいです。 ## これを書いている人について YAPC福岡とTSKaigi2026にてカンファレンススタッフをやらせて頂いています。今年も色々なカンファレンスにスタッフとして参加する予定です。 YAPCに参加した時の記事 https://comamoca.dev/blog/2025-11-18-yapcfukuoka2025/ TSKaigiの記事はまだ書けてません...書けたら追記します。 ## カンファレンスに参加することについてテックイベントに行った方が良い理由については既に以下の記事で書いていますが、カンファレンスについても同じことが言えます。 https://comamoca.dev/blog/2025-09-04-go-to-the-event/ 異なる点としては、規模が大きいので**この記事で挙げたメリットが拡大した形で受けられます**。それだけでなく遠方の方が来る事も多いので、普段会えない方と会えるのがカンファレンスのメリットだと思います。また、トークもプロポーザルという形で審査することになるので、全体的に質が高いことが多いです。 **つまりメリットしかない**ということになります。 ## 学生がカンファレンスに行くハードルしかし、カンファレンスは学生補助などがあるとは言え、費用の面で参加しづらいところもあると思います。この記事ではその問題を解決できるかもしれない方法を2つ紹介します。 ...というより方法は自明なので、そのメリデメを紹介します。 ## 登壇者として参加する ### メリット **カンファレンスによりますが、登壇者は基本参加費がかかりません**。また、大きいカンファレンスでは登壇者に対して交通費の支援があるため、遠方に住んでいる方も費用面で参加を諦めなくても良くなります。また、登壇することで懇親会でも話しかけられる確立が上がるので、その点も美味しいです。一度登壇が終われば後はゆっくり他のトークを見られるのも良い点ですね。先程書いたように、**カンファレンスはライブ**だと思っていますが、登壇は基本一人なのでなんと**ソロライブ**をすることになります。当然めちゃくちゃ緊張しますし、僕も未だに緊張します。特にデカいトラックで登壇することになると尚更ですね。昨年登壇した時は人が100人くらい居てめちゃくちゃ緊張しました... https://fortee.jp/2025fp-matsuri/proposal/e9df1f36-cf2f-4a85-aa36-4e07ae742a69 僕は普段登壇するとき、オチが着けばその過程は多少変わっても問題ないという精神で話してます。なので途中で話す内容が飛んでも上手いことカバーできれば良しとしています。漫画ドラえもん1話でセワシ君が話してた「途中の歴史が変わっても最終的な出来事は収束する」という例え話のイメージですね。この精神が参考になるか[^2]は分かりませんが、誰かの参考になればと。 ### デメリットプロポーザルを通す必要があるという点がハードルになると思います。これについては、参加したいイベントの特色と過去のトーク内容から、運営が欲しいトークと今自分が出来そうなトークの積集合を考えてプロポーザルを作れば採択される確立が上がると思っています。あと、複数投稿出せる場合は複数出すのもアリだと思います。僕も多い時で2つくらいプロポーザルを出しています。これについては正直経験が必要になるので鶏と卵みたいになってしまいますが、何回も出してみるなどして受かりやすい書き方などを自分なりに研究するのが良いと思います。あと、自身が話せる範囲の内容でプロポーザルを書くのも大事です。理由としては準備の負担がめちゃくちゃ大きくなるからですね...慣れないうちは特に避けた方が良いです。 ## カンファレンススタッフとして参加するウルトラCとして、**カンファレンススタッフとして参加する方法もあります**。登壇者もですが、当然カンファレンススタッフも参加費は基本免除されます。もちろん運営の仕事をする必要がありますし、無料だからというモチベで参加するのは良くないと思っていますが、個人的にはこれはメリットだと感じています。また、遠方に住んでいる方は運営から交通費の補助が出るため、カンファレンスに参加する際の費用をかなり抑えられます。当日会場を歩きながら参加者の方々の顔を見ていると、みんな笑っていてこの場を作れて良かったなと思えますし、スタッフとしてこの場を支えられている事に幾許かの誇りを感じたりします。また、懇親会にて歩き回っていると「お疲れさまです！」とか「今日楽しかったです！」と声をかけてくださる方がいて、それもまた嬉しかったりします。 ### スタッフって2種類あんねんカンファレンススタッフですが、実は2つ種類があります。一つは開催の半年くらい前から準備を行う**コアスタッフ**、もう一つは当日のみスタッフを行う**当日スタッフ**です。当日スタッフも参加費の免除や一部交通費の補助があるので、初めてだけどカンファレンススタッフをやりたい！という方はまず当日スタッフとして参加するのが良いと思います。僕も初めてのカンファレンススタッフは当日スタッフでした。コアスタッフの良い点としては、カンファレンスを一から作りあげていくのでやりがいがあるのと、スタッフの方同士でより関係を深められる点が良いなと感じています。また、事前準備は基本オンラインで行うので、遠方にいて当日は参加できない...という方もカンファレンスを支える一員になれるという魅力もあります。

事前準備とかはリモートですし、事前準備はするけど現地参加しないスタッフさんも普通にいるのでその辺りは特に気にしなくても大丈夫な気がする…！
常に人手不足なので事前準備を手伝ってくださるだけでもめちゃくちゃありがたかったり

逆に僕は事前準備をあんまり手伝えてなくて最近は反省してる… https://t.co/t8y0ySX941
— こまもか🦊 (@Comamoca_) May 30, 2026

### デメリットカンファレンススタッフは当然当日の運営をするので、一日中歩きまわることになります。なのでめちゃくちゃ疲れますし、全部のトークを見ることは出来なかったりします。ただ、配置された場所によってはシフトを入れ変えて、自身が見たいトークを見に行ったりすることもできるので、わりと融通は効かせられると思います。これも先程書いたようにやりがいあってのものなので、個人的には悪くないなと思っています。あと普通に良い運動になります。 ## まとめ & カンファレンス告知タイムという事でまとめです。 - テックカンファレンスに参加するのは良い経験になる - 費用の後面が難しくてもなんとかする方法はある - オフラインでの繋がりは楽しいし、自分を支える大切なものになるよみなさんもぜひテックカンファレンスに参加してみてください！直近では7/11〜7/12、中野セントラルパークカンファレンスにて[関数型まつり](https://2026.fp-matsuri.org/)が開催されます。コアスタッフ募集やプローザルは既に締め切られていますが、関東近郊に住んでいる方は行きやすいと思うのでぜひ参加してみてください！また、11/28〜11/29は東京ビッグサイトにて**YAPC::Tokyo 2026**が開催されます！こちらはプロポーザル募集がまだ始まっていないので、奮ってご応募ください！

YAPC::Tokyo 2026の「トークプロポーザル募集開始お知らせ登録フォーム」を作成しました！

メールアドレスを登録いただくと、後日CfPを開始した際にご連絡いたします。

応募に興味のある方、迷っているけど情報が欲しいという方、ぜひご登録ください！ #yapcjapan https://t.co/hhOV5rNBmb
— yapcjapan (@yapcjapan) May 26, 2026

5/31追記: 関数型まつりにて当日スタッフの募集が始まったそうです。興味のある方はぜひ！ https://blog.fp-matsuri.org/entry/2026/05/31/131337 [^1]: 主に大学生を想定していますが、中学生や高校生が来ても良いと思っています。実際Hono Conf2025では高校生の方がキーノートで登壇しています。現地で見ましたが面白かったし自分も頑張らなきゃなと思いましたね... [^2]: それこそ僕は落語経験があるので、人前で話すことにはそれなりに耐性がある状態での登壇でしたが、普通の人は落語経験がないという問題がある...

大吉祥寺.pmに行けない話

Fri, 08 May 2026 11:15:20 GMT

大吉祥寺.pm、なんと全日IWSFが被っているので参加できそうにない…
— こまもか🦊@シャニマスありがとう (@Comamoca_) April 30, 2026

という状況になったので、提出しようとしたプロポーザルをここで供養するというのがこちらの記事になります。 https://idolmaster-official.jp/live_event/mr_idolworld2026/ ## イベント開催を極限まで自動化する最近[アイマスNight](https://kawaii-driven-life.connpass.com/event/390771/)というイベントを開催したんですが、このイベントの裏テーマに「イベント開催を半自動化する」というのがあります。例えば、GitHub Actionsをフル活用してイベントの開催からconnpassページの作成、開催費用を管理するための帳簿作成などを自動で行うなどです。ミソとしては、テキストデータで全ての情報を管理すればGitのフローに載せられるので、費用の稟議をPR Reviewで行ったりできてより効率化が図れそうだなと考えています。本登壇では、そんな自動化のための実践的な工夫について紹介していきます。 ### 自己評価最近イベント開催ブームなので刺さる人が多いかなと思って選んだのだけど、いかんせん自動化のノウハウが少なすぎるので、もう少し時間を置いても良いかなと思ったりしている。ノウハウ貯めて最適解をテンプレートに落しこめてからの方が良かったりするかも。 ## AIエージェント実行基盤としてのErlang/OTP 昨今、OpenClawのように自律的に行動するが登場するなど、より一層AIエージェントの需要が高まっています。また、AIエージェントを実装するフレームワークも数多く生まれています。それらのフレームワークは並列処理や自動回復など共通した課題を解決していますが、実はそれらの問題は既に別の形で解決されているとしたらどうでしょうか。この登壇では、Erlang/OTPを「AIエージェント実行基盤」として再解釈し、Erlang/OTPとAIエージェントの相性の良さ、現時点での活用方法やエコシステム、既存のライブラリやフレームワークとの優位点について紹介します。 ### 自己評価この話も知り合いに結構話してたりするのだけど、個人的には面白い話だと思ってるのできちぴーで話したい内容だった... 特に現時点で都内にErlnag VMの話をする場所がない(いつか作るつもりだけども)ので、きちぴーは格好の発表場所だと思っていた。僕個人としては、AIエージェントはステートマシンとして解釈しているので、その点からもErlang/OTPはAIエージェントと相性が良いんですよね～って話とか、Elixir製の[jido](https://jido.run/)ってフレームワークの設計思想が面白いって話をしたかった... ## 「意味」はデータに内在しないプログラムとデータの相似性について日々の業務の中で、複数の言語でバイナリデータを扱ったコードを書いた事がある人は多いでしょう。その中で、言語が別なのにも拘わらずバイナリ操作のAPIがほとんど同一であることに気付く方もいると思います。それは偶然の一致ではなく、コンピューターアーキテクチャに由来しているものです。この登壇ではPythonとJavaScript、C言語とアセンブラそれぞれのバイナリ操作の方法を比較し、コンピューターがデータを「処理する」仕組みに迫っていきます。 ### 自己評価これは最近業務をしている時の気付きなのだけど、気付いた時にあまりに脳汁が出すぎて興奮してたし、ライブ前にもこの話をするくらいには気に入っている。きちぴーの「かわるもの、かわらないもの」というテーマとも合うので、出すならこれを本命にする予定だった... この話自体はゆくゆく記事にしようかなと思ってたりはするので、記事書いていきたい。 ## まとめという訳で以上プロポーザルの供養でした。また別のカンファレンスとかでプロポーザルとして出すかもしれないので、機会を伺いつつ採択を狙っていきたい。

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

Wed, 08 Apr 2026 15:33:24 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 18:02:35 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を導入する難易度を大幅に下げられる

Nix home-managerでnvim-treesitterを代替する

Sun, 05 Apr 2026 15:11:30 GMT

### nvim-treesitterがアーカイブされた 2026/4/4 nvim-treesitterがアーカイブされました。 https://github.com/nvim-treesitter/nvim-treesitter 事情についてはこのgistが詳しいです。 https://gist.github.com/delphinus/9b231465a1128ab844029ed52150adc2 nvim-treesitterについて簡単に説明すると、パーサ生成ツールであるtree-sitterをNeovimで使用する際の支援を行うプラグインです。例えば以下の機能を提供しています - パーサーのインストールや更新、削除などの管理 - https://zenn.dev/duglaser/articles/c02d6a937a48df アーカイブは技術的な理由ではないため復活する可能性はありますが、既にNixを導入している方はこの機会に移行してしまうのも良いのかなと思っています。また、Nixを用いるとキャッシュが効くので手元のマシンでパーサーのビルドを行わずに済むというメリットもあります。 ## nixpkgsにはnvim-treesitter向けのビルド成果物がある nixpkgsには既におあつらえ向きのパッケージが用意されているため、これを使います。 pkgs.vimPlugins.nvim-treesitter