ひむ日記

本名は設楽です

My Thoughts on the Bun Rust Rewrite を読んだ

My Thoughts on the Bun Rust Rewrite - Andrew Kelley

I actually don't have any personal criticisms of Jarred. He has different taste than me, he wants different things out of life than me.

と書いてあるのが全てだと思う。
Zig と Rust のどちらが優れているかとか、Bun が良いソフトウェアなのかとかそういう話ではなく、Jarred の目指す価値と Andrew の目指す価値がそもそも違う、という話に尽きる。

Andrew は AI の生成したコードを理解せずに (十分なレビューをせずに) ソフトウェアに取り込むことに激しくストレスを感じるタイプだと思うが、だからこそ長期的な視点で Zig という言語を高いクオリティを担保しつつ提供し続けてられているとも言える。
対して Jarred はサービスのために適切にコストを抑えて開発速度を担保しながら JavaScript ツールチェーンの最先端を拓き続けている。
多少ベクトルは違えど、どちらも自分のソフトウェアのドメインに適した手法で価値を提供し続けている一流のエンジニアであることは疑いようがない。

僕個人としてはどちらかと言うと Andrew に近い考えを持っていて、自分が理解できていないコードが混ざるとモヤッとしてしまうタイプではある。
とはいえ業務で提供するソフトウェアにおいてはコードのクオリティを担保するだけではなく、開発効率やコストのために妥協するべき場面は多い。
例えば実装をミスったら人が死ぬようなソフトウェアを作っている場合はもちろん入念にレビューをする必要があるだろうが、実装をミスっても大したことは起こりませんというような場合はレビューの工数を削減して開発効率に充てたほうが良いケースは往々にしてある。
そういった条件次第では Jarred のような大胆さが必要なのだろうなとは思うので、ケースバイケースで柔軟にエンジニアリングに向き合えるようになりたいものである。

それはそれとして、Zig ユーザが作者の想定通り健全に Zig を扱ってくれることを願うのは現実的ではないんじゃないかな。
BDFL が意思表明をすることに意味がある、という話なのかしら。

何はともあれ話の流れが追いやすくて分かりやすい、いい構成の文章だなと思いました。こういう読ませる文章を書きたいものだね。

SONY α7C II との出会いと別れ、そして再会

出会い

何か長期的に向き合うことができる趣味が欲しいな、ということで今年の2月頭にSONY α7C IIというカメラを購入しました。
レンズと合わせて 30 万円強くらい!ということで元を取るべくたくさん写真を撮っています。

勢いに任せて写真をアップロードするための Web ページを作ったり写真用の Instagram アカウントを開設したりしました (があまり更新できていない)。
よければたまに見に行ってやってください。

別れ

カメラを買ってから一ヶ月ほど、毎日どこに出かけるにもカメラを持ち運ぶ生活をしていました。
ある日朝から夜までカメラを使って帰ってくると「電池がなくなりました」表示になっていたので、いつも通り充電ケーブルに繋いでやったのですが、24 時間くらい充電しても一向に「電池がなくなりました」表示から変わりません。
儚い命だったな〜と思いながら死因を調べていたのですが、Reddit に同様の症状に関する投稿がありました。
https://www.reddit.com/r/SonyAlpha/comments/1g0pn6h/brand_new_a7c_ii_not_charging/
電源を on にした状態でバッテリーを抜き差しするという危険そうな workaround が紹介されていて、ワザップみたいにカメラを破壊する裏技なんだろ、騙されないぞ!と思いながら試してみたところ無事治りました。

再会

ということで無事カメラくんが元気になりました。
ちなみに、ファームウェアをアップデートすることでこの現象の発生を防止することができるようです。同じ機種をお持ちの方はぜひご自身のカメラのバージョンを確かめてみてください。
https://support.d-imaging.sony.co.jp/www/cscs/firm/?mdl=ILCE-7CM2

まだまだ未熟な二人ではございますが、今後とも SONY α7C II とひむらをよろしくお願いいたします。

関ケ原Ruby会議01に参戦仕り候

regional.rubykaigi.org

気づいたら一ヶ月くらい経っていてやばいと思ったので参戦ブログを書きます。

関ケ原Ruby会議01は関ケ原ふれあいセンターで行われました。ホームページが htm 拡張子なのがいい味を出していますね。

私は京都住みなのでこの度は西軍として参戦させていただきました。関西から出陣されている方々はたいてい米原まで電車で行き、そこから JR 奈良線で関ケ原まで、というルートで向かわれていたと思います。
京都 to 米原は JR 琵琶湖線を使うか新幹線を使うかの選択肢があったのですが、自分は朝起きられなかったので新幹線で向かいました。その後米原で偶然 id:rokuokun と出会い、一緒に関ケ原に向かいました。
これは次回開催を見越しての備忘録なのですが、京都は JR 西日本なのに対して関ケ原は JR 東海である (多分?) ようでして、何も考えずに京都から関ケ原まで JR で向かうと関ケ原で改札に弾かれるという罠がありました。新幹線で米原まで向かっていた僕は許されたものの同行していた id:rokuokun が無事改札に引っかかっており、オンラインで駅員さんにトラブルシューティングをしてもらうというおもしろ体験をしていました。

この日は本当にカラッとよく晴れたカメラ日和だったのですが、肝心の僕は愚かにも朝焦って家を出たせいでカメラを忘れてきており、行きの電車でかなり落ち込んでいました。

お昼のピクニックも最高でしたね。関ケ原の飯も美味でした。

また、夜の懇親会で出たケータリングがとんでもなく美味しかったのが印象的でした。
RubyKaigi で喋ることができなかった方々とも喋ることができて全体的にかなり満足度が高かったです。

一つ悔いが残るとしたら関ケ原古戦場記念館に行けなかったことでしょうか!
関ケ原町はすごくいい雰囲気で自然も感じられていい町でした!また行きたい!

RubyKaigi 2026 に参加したぞっ!

自分は大して Ruby に詳しいわけではないのですが、すごく楽しめました。

トーク

mruby on C#: From VM Implementation to Game Scripting by hadashiA

speakerdeck.com

hadashiA さんは Unity/C# の界隈でかなり有名な方なのですが、自分の中で Ruby のイメージはあまりなかったので、事前勉強会の時からどういうお話をされるのか気になっていました。

mruby/cs 面白いですね!Unity でノベルゲーム的なものを作る際とかにはぜひ使いたいです。

hadashiA さんは、後述する Ruby Illuminations で縦ノリしていた姿が印象的でした。一緒にはしゃげて嬉しかったです。

Rapid Start: Faster Internet Connections, with Ruby's Help

speakerdeck.com

QUIC やインターネットについて少し詳しくなれる話があり、Ruby に関係なく普通に面白かったです。
jrf の話も X (formally Twitter) で追っていたのですが、ご自身の作業の効率化にしっかり役立っているというのはいい話だな、と思いました。

Building a Standalone Ruby Programming Environment

speakerdeck.com

組み込み機器と OS の話が聞けて最高!しかし、初日の 15 時くらいに Harucom ボードを買いに行ったら完売ですと言われてしまい悔しい...

Booth で買います。

Surviving Black Friday: 329 billion requests with Falcon!

speakerdeck.com

Web でお金をもらっている身としてすごく興味深いトークでした。

その後 STORES Cafe でスピーカーの Samuel さんとお会いしたのですが、Shopify の CI について雑多に質問したところ、実際に Shopify 社内で使われている CI の様子を見せてもらいながら解説してもらうというほっこりイベントが発生したりしてすごく満足度が高かったです。

A Faster FFI

自分の興味分野とかぶっていたこともあって RubyKaigi 2026 のトークの中でも特に印象に残っています。

GitHub - tenderlove/ffx: FFI transpiler with JIT hints · GitHub

ffx の最適化手法は Ruby 以外にも適用できそうで、普通にインスピレーションを得られて最高でした。
あと、単純に Aaron さんのお話が面白くてすごく楽しめました。

Ruby Releases Ruby

Ruby のリリースフローや、リリースのためのツールなどおもしろ話がいろいろあって楽しかったです。

「読むだけで nobu さんが書いたコードは判別できる」、めちゃめちゃ面白い。

その他

Ruby Committers and the World はめちゃめちゃ良かったです。朝起きて良かった。

Matz のキーノートもめちゃめちゃ良かったです。Matz がコミッターのことを Human Intelligence として見ている、という話が良かった。

イベント

White Seed

Ruby Karaoke

Ruby Illuminations

謝辞

STORES さん、学生支援ありがとうございました。

product.st.inc

RubyKaigi 気になっているけど交通費や宿泊費がネックで手を出せていないよ、という学生の方はぜひ学生支援を使って次回の RubyKaigi に来てください!

White Seed さん、amatsuda さん、クラフトビールありがとうございました。

5 杯強くらい飲んだ気がします。めちゃウマでした。

RubyKaigi スタッフの皆さん、最高に楽しめました。
宮崎も参加します!

ルーズリーフってなんだっけ

「ルーズリーフある?」と聞かれて、何のことだったかパッと思い出せなかった。
バインダー的なものの事かな?と最初に思い浮かんだので、「クリアファイルならいっぱいあるよ〜」と言ったらびっくりされた。
意味空間として近いものが連想されたという意味では、自分はやっぱり LLM 的な脳みそをしているのかもしれない。
それかボケが始まっているのかもしれない。
そしてこれは増田に書くべき話だったかもしれない。

君は motemen になれる


はじめに

本エントリは はてなエンジニア Advent Calendar 2025 の 42 日目の記事です。
昨日は id:mangano-ito2026 年ですね。年末大掃除で見つけた昔作った謎スクリプト "solitarize" を紹介します。 でした。

id:mangano-ito さんは年末にしっかりと大掃除をされていてさすがですね。
id:himura467『僕のヒーローアカデミア』のアニメがめでたく最終回を迎えたということで、年末をヒロアカとともに過ごしておりました。

分かる方は分かるかと思いますが、タイトルもかなりヒロアカに引っ張られています。

アイコン決まらない問題

先日大学の研究室の同期と話していて、社会に出る前にアイコンをユーザーと一対一に対応させる必要があるよね、という話をしました。

僕は 2026 年は Blog や X (旧 Twitter)、GitHub、カンファレンスでの登壇など外部への発信に力を入れる年にしようと意気込んでいるのですが、大半の方はユーザー名よりもアイコンでインターネット上の人を区別している (と思っている) ため、各種プラットフォームにおけるアイコンがバラバラだと同じ人として認識してもらいづらいという問題があります。

実際僕は現在 3 種類くらいのアイコンを使い分けており、かなりわかりづらい人間になってしまっているんじゃないかな、と危惧しています。

左から GitHub, はてな, Facebook

また、自分の写真をアイコンに使う場合は現実の被写体が変化 (老い) することによってアイコンと本人の見た目に食い違いが起こりやすく、混乱を招いてしまう恐れもあります。

先達に倣う

はてなエンジニアのアイコンを見てみると、id:motemen を筆頭に id:rokuokunid:polamjagid:ymse などモザイク調のアイコンを用いている方が何人かいらっしゃいます。

また、id:motemen はその特徴的なアイコンをコンテンツにされているのをよく見かけます。羨ましい。
airreader.hatenablog.com

ということで、誰でも id:motemen 風のアイコンを作成できる Zig ライブラリと Wasm を用いた Web ページを作りました。

Image Motemenizer の遊び方

himura467.github.io

↑のページにアクセスし、「Click to upload or drag and drop」と書いてある領域をクリックして png, jpg, bmp のいずれかのファイルを選択することで画像が id:motemen 風になります。
もちろんドラッグ&ドロップをすることでもファイルを選択できます。

処理は全てブラウザ上で完結している (外部との通信を必要としない) ため、プライベートな画像などでも安心してモザイク処理を行うことができるはずです。

デモ

Horizontal Blocks と Vertical Blocks を変更することで、モザイクの粒度を変更できます。
id:motemen を目指すなら 4x4。id:polamjag なら 16x16。

また、Color Space を変更することでモザイク処理を計算するための色空間を指定できます。
現在は RGB と Oklab の二つの色空間をサポートしています。
Oklab は人間の知覚により近い方法で色の計算を行うことができますが、実際にどのような違いが生まれるのかも是非触って体験してみてください。

変更を加えた画像は「Download Result」と書いてあるボタンからダウンロードできます (現在は png 形式のみサポート)。
png では DEFLATE という圧縮フォーマットが用いられているのですが、これは RLE などと同様に画像に含まれる繰り返しパターンに対して最適化されているため、同じサイズの画像でもモザイク処理をすると有意にファイルサイズを削減する*1ことができます。嬉しいですね。

Image Motemenizer の実装

github.com

実装に Zig を用いているのは、単純に好みです。
Zig でしか実現できない実装などは特になく、Rust などでも同じように実装すれば実現できると思います。

今回実装するにあたって、ImageMagick などの画像処理ライブラリに依存しない Zig ライブラリとして実現することを目標に作りました。
stb を再発明するのは流石にしんどいので唯一 stb にはお世話になっていますが、vendoring しているため依存ゼロの Zig ライブラリとして実現することができました。

Rgb 色空間と Oklab 色空間の座標変換を手で書いたり、画像ファイルを1ピクセルずつ塗っていく体験はなかなか味わい深くて良かったです。

余談ですが、Zig における Wasm のビルドはクロスコンパイルのターゲットを指定することで実現できます*2

Wasm 向けのターゲットとしては wasm32-freestandingwasm32-wasi があるのですが、本ライブラリにおいては wasm32-wasi をターゲットとしてクロスコンパイルを行っています。
もちろん wasm32-freestanding としてビルドできれば最高なのですが、stb が libc に依存している関係で malloc, free, realloc を wrap した実装を Zig 側で書く必要があり、できないことはないと思うんですが少し億劫だったので wasm32-wasi で妥協している、という感じです。
ブラウザ側で特に polyfill などを設定せずとも自分の環境では latest の Chrome, Safari はどちらも元気に動いていますが、何か不具合などあれば対応します。
気が向いたら wasm32-freestanding でビルドするように修正するかもしれません。

おわりに

本ライブラリを用いて生成した id:motemen 風アイコンによって、僕の SNS たちのアイコンの統一が無事進められています。
新アイコンになっても本年も何卒よろしくお願いいたします。

旧 <--> 新

*1:手元の 512x512 ピクセルpng 画像をサイズそのままに 16x16 でモザイク処理を施したところ、276KB -> 9KB になりました

*2:Ref: https://ziglang.org/learn/overview/#cross-compiling-is-a-first-class-use-case