ひむ日記

本名は設楽です

君は 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

2025年の振り返りと2026年の抱負

はてな

はてなでアルバイトをし始めたのが 2024 年の 11 月ごろだった気がするので働き始めて大体 1 年が経ったことになるが、すごく充実している。
オフィスに行くと無料で飲み物や軽食が貰える上に、高頻度で BBQ や祇園祭、マラソンなどのイベントが起こるのでかなり楽しい。

祇園祭に繰り出すはてな社員たち

良い肉を食べさせてもらったりもした。
blog.sushi.money

仕事

2025 年の初めは Perl はおろか GraphQL も Terraform も何もわからん〜という感じだった気がするが、1 年経って Perl ともかなり仲良くなれた気がする。

コーディングで悩むことはある程度少なくなってきた一方、タスクの工数設定や、期日に間に合わなさそうな時に「まずそうっす」というエスカレーションをあげるタイミングなどは下手くそなので精進していきたい。

また、デザイナーさんやディレクターさんなどとお仕事をする上で、僕がやりやすい仕事の進め方ではなくチーム全体がやりやすい仕事の進め方を考えることを意識していきたい。

それと、タスクに着手した後で「ここの要件が曖昧なので詰めましょう」とディレクターさんに呼びかけることになると、ディレクターさんのコンテキストスイッチが負担になってしまったり最悪手戻りが発生してしまったりするので、要件を伝えられたタイミングで可能な限り曖昧な要件を指摘しきれるようになりたい。

Life is Tech!

自分が受け持っていたメンバーのうち 3 人ほどが 3 月に卒業して晴れて大学生になったのだが、普通に涙がちょちょぎれてしまった。
エモい。

Life is Tech! では、僭越ながら 2 年ほど Unity コースの講師として大学生の方々に対して Unity やゲームプログラミングについてお教えする立場にいるのだが、プライベートでは Unity はおろか C# も最近はあまり触れられておらず Unity の魅力を伝えるべき立場としては不甲斐ない限りなので、本年は最低 1 作品は Unity に関するアウトプットを出したいな、という気持ちでおります。

Unity 講師 in 福岡

サイボウズ・ラボユース

確か 6 月か 7 月ごろにサイボウズ・ラボユースというプロジェクトに採択していただいて、サイボウズ・ラボの中谷さんの下で機械学習に関する研究をさせていただいている。

中谷さんは機械学習以外にもさまざまな領域に精通されていて、未熟な自分に嫌な顔ひとつせずなんでも教えてくれるので、日々学びがあり充実した研究をさせていただいている。

夏合宿の飯たち。すごく美味しい。

積んでいるゲーム

AI コーディングエージェントが流行したのは 2025 年の大きな出来事だった気がするが、おかげさまで僕も大ハマりしてしまい、2025 年はほとんどゲームをする時間を取れなかった*1

暇があると PC を開いてしまうのと、いざゲームをやるぞ、となっても何から手をつけて良いかわからなくなってしまうので、2026 年は積みゲーを管理できるリストなどを作って優先度を決めて消化できる体制を整えたい。

今書いていて思い出したが、高校生の頃からずっと中途半端なところで止まっている「ペルソナ Q」はパパッと消化してしまいたい。

DTM

中田ヤスタカが好きなのと、はてなでは結構 DJ 文化が盛んなこともあり、素朴に DTM に対するモチベが高まっている。
やるならちゃんとやりたいので、音楽理論なども学びたい。

総括

2025 年は AI をはじめとして Web やシステムプログラミング言語など多方面に手を出していたが、それらのインプットをあまりうまくアウトプットできなかった気がしている。

YAPC::Fukuoka 2025 で LT をする機会をいただけたのは嬉しかった一方、色々な方の発表を見て自分の未熟さを思い知るところも多かったので、2026 年はブログも含めより一層アウトプットに力を入れていけると良いな、と考えている。

YAPC::Fukuoka 2025 では吉祥寺.pm や RubyKaigi などさまざまなカンファレンスにお誘いいただいたので、どんどん飛び込んでいきたい。

*1:アークナイツと雀魂は移動中などによくやっていた

Temporal API を用いた RFC 5545 実装の Rust 製 JavaScript ライブラリを作っています

はじめに

本エントリは Life is Tech! Mentors Advent Calendar 2025 の 25 日目の記事です。

開発のきっかけ

僕は大阪金曜スクールで日頃活動しているのですが、先日メンバーの出席や目標の管理を行うための Web サイトをリリースしました。

出席を管理するページ
目標を一覧できるページ

この Web サイトでは、RFC 5545 という標準に則ったデータ構造でスクールの日程を管理しています。

RFC 5545 とは?

datatracker.ietf.org

インターネット上でカレンダーやスケジュールに関する物事を表現するための枠組みを提案したもので、現代においてカレンダー関連の機能を持つアプリケーションや API は大抵これに準拠して実装されています。

カレンダーやスケジュールに関する物事、とは何でしょうか?
例えば僕が住んでいる区域で段ボールごみが出せる日は「第二・第四水曜日」となっていますが、この決まりはカレンダーやスケジュールに関する物事と言えます。

昭和二十三年法律第百七十八号
国民の祝日に関する法律
第三条 「国民の祝日」は、休日とする。
2 「国民の祝日」が日曜日に当たるときは、その日後においてその日に最も近い「国民の祝日」でない日を休日とする。
3 その前日及び翌日が「国民の祝日」である日(「国民の祝日」でない日に限る。)は、休日とする。

国民の祝日に起因する休日は法律で上記のように決まっていますが、このような複雑なイベントもカレンダーやスケジュールに関する物事と言えるでしょう。

RFC 5545 は数多存在するこれらカレンダーやスケジュールに関する物事を可能な限り普遍的に表現可能な枠組みとして提案されているため、その適用範囲の広さと暦の解釈の難しさとが相まって、かなり複雑な枠組みとなっています。

さらに、これをグローバルなアプリケーション・API として実現しようとすると、タイムゾーンサマータイムといった概念によって複雑度が跳ね上がります。

RFC 5545 は様々な言語・フレームワークで実装されていますが、このような事情によって RFC 5545 の定める標準全てに準拠するのを諦めたライブラリも少なくありません。

そのうちの一つが rrule.js という JavaScript ライブラリです。

本ライブラリは長らく JavaScript 環境における RFC 5545 実装を担ってきた歴史あるライブラリなのですが、RFC 5545 の複雑さと JavaScript の Date 型の扱いづらさによって*1プロジェクトが停滞してしまっています。

Furthermore, the RFC is extremely complex, with tons of edge cases, and a full implementation on top of a buggy Date primitive is going to be very expensive to build and to maintain. I would say that's the reason why this project has stalled for years and no replacement has emerged. At the end of the day, somebody (probably a large company) is going to need to sponsor a major effort to implement the RFC and maintain it on an ongoing basis.

https://github.com/jkbrzt/rrule/issues/450#issuecomment-1055853095

さて、例に漏れず僕の運用している Web サイトも rrule.js を採用していたのですが、前述の通りこのライブラリはメンテナンスが継続されていないため、不具合を踏んだ場合は元の実装を wrap するなどの力技で解決するしか手段がありません。
また、JavaScript の Date 型の扱いづらさや暗黙的な挙動にも苦しめられており、課題感を抱えながら日々フロントエンドを書いておりました。

Temporal API

そのような Date 型の問題を解決する新たな時刻管理用の API として Temporal API というものが開発されています。

個人的には長らく「実験的な API」、「未来の技術」という先入観があったのですが、実際はかなり対応が進んでいるようで、すでに Firefox では対応が完了しており、Chrome, Edge も 2026 年の 1/13, 1/15 にリリースされるバージョンでそれぞれ対応されるようです。

Chrome, Edge, Firefox などの主要ブラウザの対応が完了した後は JavaScript における時刻管理は Temporal API が支配的になっていくのではないかな、と期待しています。

Node-API

ところで oxc というプロジェクトをご存知でしょうか?

このプロジェクトは JavaScript 環境の Linter や Formatter などを Rust という言語で書き換えるプロジェクトです。

ここで詳しい話はしませんが、一般に Rust で書いた処理は JavaScript などのインタプリタ (や JIT コンパイラ) で書いた処理よりもパフォーマンスが優れるため、最近はスクリプト言語で書かれた処理を Rust で再実装する行いが流行しています。

さて、Rust で再実装するとは言っても Node.js ランタイムやブラウザが直接 Rust を読めるわけではありません。
ここでは、ネイティブ拡張と呼ばれる技術が用いられています。
これについても詳しい話はしませんが、Perl という言語のネイティブ拡張の話を 令和七年冬、DBD::mysql の quote メソッドを読む - ひむ日記 で書いているので、チラッと読むと雰囲気がわかるかもしれません。
Perl では XS というフォーマットによって開発者が Perl と C の呼び出し規則の違いを吸収する実装をしなくても良い仕組みが提供されていますが、Node.js では XS の役割を Node-API が担うことによってこれが実現されています。

この Node-API は公式には C や C++ 向けの実装が提供されているのですが、Node-API を Rust や Zig に拡張するプロジェクトも有志の OSS によって実現されています。
oxc などの Rust 製 JavaScript ツールは、Node-API という公式の仕組みとそれを Rust に拡張する有志の OSS (NAPI-RS) によって成り立っているのでした。

おわりに

そんな oxc と同じように、僕も Node-API と NAPI-RS の恩恵にあずかりながら Rust 製の高速な RFC 5545 実装を Temporal API 向けに提供する JavaScript ライブラリを作っているよ!という近況報告でした。
https://www.npmjs.com/package/chronical

Temporal API は、時刻を表現するフォーマットとして従来用いられてきた RFC 3339 を更新する標準である RFC 9557 が採用されていたりと、時刻管理の最先端を体験できている感じが面白いですね。
他にも Rust のオブジェクトを bundler に優しい形式で Node.js ランタイムに渡す方法など、いろいろ考え事があって楽しいです。

Star や不具合報告、Pull Request もじゃんじゃんお待ちしていますー!
github.com

お誘い

中高生の皆さんへ

Life is Tech! では楽しくプログラミングを学べる場を提供できるよう尽力しております。
キャンプやスクールで皆さんをお待ちしていますね!
camp.life-is-tech.com
life-is-tech.com

大学生の皆さんへ

僕たちと一緒に働いてみませんか?
一年に一回行われる Leaders という研修イベントに参加すると、技術的な事柄以外にもコミュニケーションやタスクマネジメントも成長できる上に、一緒に働けるようになるみたいですよ!
leaders.life-is-tech.com

*1:その他にもメンテナの方の業務内容の変化や慢性的なメンテナの不足なども要因として挙げられています

令和七年冬、DBD::mysql の quote メソッドを読む

はじめに

本エントリは MySQL Advent Calendar 2025 の 9 日目の記事です。
昨日は @HrsUed さんの wait/io/table/sql/handlerの正体 でした。

本エントリのあらすじとしては、libmysqlclient を用いたデータベースドライバの実装・処理の流れを追うことで MySQL C API を用いたライブラリの開発・使用の勘所を掴みたいというモチベーションのもと、Perl の代表的な MySQL ドライバである DBD::mysql の実行フローを追いながら理解を深めるぞ、というものになります。

いくつかのメソッドの実行フローを眺めようと思っていたのですが、quote だけでほどほどのボリュームになってしまったので、他のメソッドの動作については別のエントリでまた書こうと思います。

DBD::mysql とは?

PerlMySQL データベースを操作するために使用されるデータベースドライバ。
DBI という Perl のデータベースインタフェースに準拠した実装を提供している。

登場人物紹介

Perl アプリケーション

アプリケーション開発者が開発する、MySQL を利用するアプリケーション。
DBD::mysql をデータベースドライバとして用いる。

mysql.pm

DBD::mysql の一部。
mysql.pm にはエントリポイントとなるメソッドが定義されている。
これらは DBI で規定されたメソッドの実装となっているものが多い。

mysql.xs

DBD::mysql の一部。
mysql.xs では、Perl の実装と C の実装とのインタフェースが定義されている。
ここより下の実装は Dynamic Loading によってメモリに読み込まれる (libmysqlclient は Dynamic Linker によって解決される)。

dbdimp.c

DBD::mysql の一部。
dbdimp.c には C 言語での実装が定義されている。
Perl ランタイム側から XS 経由で呼ばれる。

libmysqlclient

C 言語で記述されたクライアントアプリケーションが MySQL Server と通信するために使用される C ベースの API の実装。
MySQL :: MySQL 8.4 C API Developer Guide :: 2 MySQL C API Implementations

quote メソッドの実行フローを追ってみる

DBD::mysql (が準拠する DBI) には $dbh->quote($value, $data_type) というメソッドが定義されている。

これは $value に含まれる特殊な文字をエスケープするなどして、SQL 文中に用いるリテラル値として使えるようにするために使用される。
undef が与えられた場合は "NULL" が出力される。

また、$data_type が与えられた場合は、その情報を基に $value に対して施すクオートの処理内容を決定する。

== Example ==
$dbh->quote("' OR 1=1 --")

== Output ==
'\' OR 1=1 --'

処理は大まかに以下の図に示した流れで進む。

sequenceDiagram
  participant A as Perlアプリケーション
  participant B as mysql.pm
  participant C as mysql.xs
  participant D as dbdimp.c
  participant E as libmysqlclient

  A->>B: call
  activate B
  B->>C: dispatch
  deactivate B
  activate C
  C->>D: call
  deactivate C
  activate D
  D->>E: call
  deactivate D
  activate E
  E->>D: return
  deactivate E
  activate D
  D->>C: return
  deactivate D
  activate C
  C->>A: return
  deactivate C

ここからは、各ステップでどのような処理が行われているかを具体的に読み進めていく。

1. Perl アプリケーション

$dbh->quote() が呼び出される。

2. mysql.pm

mysql.pm に定義されている DBD::mysql::db パッケージには、DBI の要求する quote メソッドが定義されていない。
このとき、DBImysql.xs で定義されている C 言語実装の XSUB を動的に"ディスパッチ"する。

The DBI "dispatches" the method calls to the appropriate driver for actual execution. The DBI is also responsible for the dynamic loading of drivers, error checking and handling, providing default implementations for methods, and many other non-database specific duties.

Architecture of a DBI Application

3. mysql.xs

mysql.xs には quote という C 言語で書かれた関数が定義されており、DBI によって透過的に呼び出される*1
https://github.com/perl5-dbi/DBD-mysql/blob/aead7bede40dd335412efe35f41d35e3144d01dd/mysql.xs#L413-L429

quote は Perl の引数 (dbhstrtype) を受け取り、非同期クエリの実行中チェックなどをした後に dbdimp.c のヘルパー関数 dbd_db_quote() を呼び出し、処理を委譲する。

4. dbdimp.c

mysql.xs から呼び出された dbd_db_quote は引数 (dbhstrtype) を受け取り、以下の順に処理を行なっていく。
https://github.com/perl5-dbi/DBD-mysql/blob/aead7bede40dd335412efe35f41d35e3144d01dd/dbdimp.c#L4586-L4642

a. 渡された文字列 str の有効性を確認し、undef である場合は "NULL" を返す

b. 型情報 type が与えられている場合はその型に対応する sql_type_info_t 構造体を取得し、数値型などのクオートすべきでない型であることが判明した場合は Nullsv を返して処理を切り上げる (この Nullsv は文字列としての "NULL" とは異なるので注意)

c. エスケープ後の文字列を格納するための新しい Perl スカラ値を作成し、メモリを割り当てる

メモリは 元の文字列の長さ * 2 + 3 の長さで割り当てられる。
なぜこうなっているのかと言うと、全ての文字がバックスラッシュでエスケープされる場合に最長で元の長さの 2 倍になる可能性があり、さらに開始の引用符 (')、終了の引用符 (') および C 言語において文字列の終端を表すヌル文字 (\0) が追加されるため最長で 元の文字列の長さ * 2 + 3 になるためだと思われる。

d. libmysqlclient ライブラリの mysql_real_escape_string_quote() を元の文字列を引数として渡した上で呼び出す

5. libmysqlclient

与えられた文字列にエスケープ処理を施し、エンコード済み文字列の長さを返す。
MySQL :: MySQL 8.4 C API Developer Guide :: 5.4.61 mysql_real_escape_string_quote()

6. dbdimp.c (戻り)

libmysqlclient によってエスケープが実行された文字列に対し*2、開始と終了の引用符を書き込みヌル文字 (\0) を追加したものを返す。

7. mysql.xs (戻り)

dbdimp.c によってエスケープされた文字列を Perl ランタイムに渡す際に、Perl の参照カウントを一時的に維持するために、mortal な値としてフラグをつけて返す。

おわりに

Perl ランタイムからぬるっと動的に C の実装が呼び出されている部分はすごく面白かったです。
また、メモリの割り当てや Perl ランタイム側に値を返す事情を考慮した設計は、Perl 以外の言語・フレームワークによるネイティブ拡張にも応用できそうだな、と思いました。

明日は @mita2 さんです!

*1:DBI による XS ドライバメソッドの呼び出しは高度に最適化されており、高速

*2:正確には開始の引用符を書き込んだ後に mysql_real_escape_string_quote() が実行される

YAPC::Fukuoka 2025 探訪記 Day 2

himura467.hatenablog.com
が長くなりすぎてしまったので分割しました。
本エントリは Day 2 のトークの感想をまとめたものです。
Day 1 の感想はこちら

OSS開発者の憂鬱 by Yusuke Wada

speakerdeck.com

世界的な OSS の作者というと華やかなイメージがありますが、その分大変なこともあるんだぜ、ということが語られていました。
Issue や PR に対してリジェクトするためのコミュニケーションはいかにも大変そうだなと思いました。

Minimal Reproduction が大事であるという話はすごく分かるなあ、と思いつつ、不具合の原因究明において Minimal Reproduction を見つける作業が一番大変 (かつ一番やりがいがある) だと思っているので、頑張っていきたいですね。

世界中の著名な方と一緒にご飯を食べて写真を撮っている、という話はめちゃめちゃ羨ましいな〜と思いました。
Hono にはお世話になっているのですが全然貢献できていないので、ひとまず Hono CLI を使うところから貢献していきたいですね。

Perl の生きのこり by わいとん & kobaken

speakerdeck.com

お世話になっている Plack や Carton などが生まれた歴史的経緯がお話しされていてめちゃめちゃ良かったです。
特に PSGI に関しては、元となった PythonWSGI (や ASGI) に興味があって調べていたこともあったので、自分の興味のある分野にも関わりのある歴史が知れてすごく学びになりました。

また、本トーク用に BBS アプリケーションが用意されていてめちゃめちゃ良かったです。
YAPC::Fukuoka BBS - 令和最新版掲示板
Bun, Hono と一緒に Perl が使われているという味わい深い技術スタック
GitHub - kfly8/yapc-fukuoka-bbs

とりあえず id:miyagawa さんがカッコいいことだけはめちゃめちゃ分かったので、YAPC 以後 rebuild.fm を聞くようになりました。
rebuild.fm

OSS開発者なら学生たくさん連れてこれる説 by id:moznion

まんまと連れてこられました。

尊敬する OSS 開発者の皆さんに忌憚のない質問をぶつけました🚀

OSS 開発者の皆さんの座談会のような雰囲気で面白かったです!

転ばぬ先のXS入門 by polamjag

speakerdeck.com

裏番組でしたが、2 日目の 3 次会で id:polamjag さんがトークを再演してくださったのと、個人的に資料を読んだので感想を書きます。

そこまで最近の話ではないのですが、node-canvas というネイティブ拡張付きのライブラリを AWS Lambda 上で動かす際に悩みポイントがあったので、ネイティブ拡張の仕組みを知る絶好の機会だぞ、と思いながら聴いていました。

資料を 2 周した後に DBD::mysql のコードリーディングをしていたのですが、学んだ知識が活きる箇所が幾つかあってテンションが上がりました。

XS 側で管理している SV を Perl ランタイムに戻すときに、その時点では参照カウントを維持しつつ Perl 側でスコープを抜けた時に正しく free されることを保証するために mortal フラグというものが用いられている、というのが個人的なおもしろポイントでした。

教科書では知れない令和最新 Perl ワード解説バトル by id:rokuokun

バトルしました⚔️

bless の話の流れで、die() しても死なず、bless() すると死ぬ Acme::Undead というジョークモジュールを紹介してもらいました。おもろい。

日頃僕は prefork 型の Starlet という PSGI サーバにお世話になっているのですが、「イベントドリブンアーキテクチャを実現する PSGI サーバ実装のおすすめはありますか?」という素朴な質問を質問箱に投げたところ、id:kfly8 さんに Twiggy をお勧めしていただきました。id:miyagawa さんどこにでもいるなあ。


最近は Mojolicious もいいよ、とのこと。
色々試してみます!

id:rokuokun の司会は凄く安定感がありました。見習いたい。

LT

Perl 9 by moznion

トーク概要を読んで、なんだこれは?と思っていました。

手練手管で Perl 9 を実現していて面白かったです。
Plan 9 が出てくるとは思わなかった。id:lufiabb が喜びそうだなと思いました。

Binary "pack" Rebooted in Perl 〜Rubyistの視点から〜 by 近藤うちお

udzura.jp

pack / unpack を 1 割くらい理解しました。
バイナリ読めるようになりたい。

コマンド行から簡単に new してメソッドを試したい、タブ補完もしたい…MouseX::OO_Modulino と関連モジュールのご紹介 by hkoba

hkoba.github.io

お恥ずかしながら Modulino という概念を知らなかったのですが、script と module の両方として機能するファイルのことを指している (合ってますか?) んですね!
スクリプトとして実行する際の補完も実現されているということで、すごく使いやすそうです!

小さなPerlスクリプトから続くOSS by iberianpig

LinuxMac みたいにシャッとスワイプしたい、確かに。
Linux マシンを手に入れたら絶対使います。

ghqの秘密 by 松木 雅幸 / Songmu

www.docswell.com

ghq が「Go Hot 九州」の略であるという公式 (id:motemen) からの声明は衝撃でしたね。


VCS 全然知らないものがたくさんあって面白かったです。

伝統的日本企業のソフトウェアエンジニアになって無双しよう! by 倉井龍太郎

ハローキティさんがひたすらに可愛かった。
JTC に入るとスライドにハローキティさんを起用できるのは強い。
「みんななかよく」大事にしていきたいですね。

キーノート by P山

speakerdeck.com

年収 300 万円の話は教訓として刻みました。
話がすごくお上手で、笑いどころがあり引き込まれる話もあり、すごくいい話でした。
僕も Hacker でありたいな。頑張ります。

YAPC::Fukuoka 2025 探訪記 Day 1

himura467.hatenablog.com
が長くなりすぎてしまったので分割しました。
本エントリは Day 1 のトークの感想をまとめたものです。
Day 2 の感想はこちら

iPhone のマイナンバーカードを使った本人確認の実装 by kgoro

Verify with Wallet API を使って手元のマイナンバーカードで何か遊べないかなという思いがあり、ちょうど実装に触れているトークがあったので聴いてみることに。
結論としては Verify with Wallet API を使うためには利用申請が必要なようで、個人で趣味で用いるのは難しそうでした。

運転免許証やマイナンバーカードをスマートフォンに格納するための技術方式である mdoc を用いて読み書きを行う、という話がなされていましたが、電子保険証などの技術の背景を知ることができてよかったです。

途中 ル方式 という名前が出てきてどういうネーミングなんだ?と思ったのですが、調べたところイロハ順みたいですね。日本らしくて良い。

「正規表現をつくる」をつくる by makenowjust

speakerdeck.com

Perl といえば正規表現、ということで正規表現トークを聞きにきました。

正規表現を作る上で、マッチさせたい文字列を過不足なく表現する正規表現が作れたら最高なのですが、例えばメールアドレスだと RFC に準拠していないメールアドレスが存在したりしてどこまでカバーできる正規表現を作るべきか迷うことがたまにありました。

また、ReDoS 攻撃*1と呼ばれる「正規表現と特定の文字列のマッチをするときに異常な時間がかかってしまう脆弱性を利用した攻撃」に対する耐性も気にしながら正規表現を書く必要があります。

これらの問題にうまく対処しつつ、ユーザが求める正規表現を作ってくれるプログラムを模索しよう、というようなお話でした!

id:makenowjust さんは Kyoto.なんか #6 以来二年ぶりくらいにお会いしましたが、お元気そうで何よりでした!

なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える by 宮下 剛輔

speakerdeck.com

自分は Terraform でリソースを定義する際に Best practices for root modules  |  Terraform  |  Google Cloud Documentation に沿ってモジュールを切り分けて運用しているのですが、時間の流れとともに構成が新しくなるにつれて「現在のモジュールの切り分け方で適切なのか?」という疑問が湧くことが度々ありました。

トークではそのような疑問・違和感を「凝集度」「結合度」という言葉を用いてうまく噛み砕いてくださって、個人的な日頃のもやもやが少し晴れました。

アプリケーションコードでは実装の詳細を隠蔽してインタフェースを提供する設計によりカプセル化疎結合性を担保し、モジュールの中身を理解しなくても利用できる状態を作るのに対し、IaC ではそもそも詳細が関心ごとでありモジュールの中身を理解して使う必要があるため抽象化についての考え方を変える必要がある、というのは確かにな (あんまり考えたことなかったな) と思いました。

そのような難しさとどう向き合うかについても具体的な話がされていましたので、早速うちの Terraform モジュールのリファクタリングを実践してみるぞ!

Amazon ECSデプロイツールecspressoの開発を支える「正しい抽象化」の探求 by 藤原俊一郎

speakerdeck.com

id:sfujiwara さんが開発している ecspresso を例に、設計における適切な抽象化についてお話しされていました。

抽象化の度合いによってインタフェースが吸収しなければならない実装が異なるため開発・メンテナンスする側のコストが大きく変わってくるという話は、実例として提示されていた各種 IaC ツールの差分の違いがすごく分かりやすかったです。

自分が LT で喋ったライブラリGoogle の実装をラップしたものなのですが、元の実装に深く依存している上に微妙に抽象化をしてしまっているので、メンテナンスコストなどを考えると今後困るんだろうな、と身につまされる思いでした。

大規模OSSに一人で立ち向かうには by Sosuke Suzuki

speakerdeck.com

本当にいい話でした。漠然と物事に対するやる気が出ました。

情熱をエミュレートするのが大事というのは本当にそうで、全然興味ない〜やる気出ない〜という時でも、あたかもやる気があるっぽい仕草をするといい感じに脳を騙すことができてパフォーマンスが上がるので、よくやっています。
今もブログを書く情熱をエミュレートしてブログを書いています。

適度に舐めるのも大事!藍染惣右介も「憧れは理解から最も遠い感情」だと言っている。

とりあえず散歩に行こうと思いました。

「バイブス静的解析」でレガシーコードを分析・改善しよう by hitode909

speakerdeck.com

id:hitode909 さんの発表が面白そうだったので見に行きました。

発表内容に関して、素朴に 4 万行のデッドコードを削除できたのはすごいなと思いました。
僕は AI くんをあまり信用できていないため、AI の出した差分は全て目を通さないと安心できず大規模なリファクタリングはそれ相応の時間がかかってしまうのですが、仕組みを整えればやりようがあると知ることができたのは驚きでした。

発表内容以外だと、このトーク会場だけずっと笑いが何処かから漏れているという異様な雰囲気で、これが YAPC か!と実感しました。

Agentに至る道 〜なぜLLMは自動でコードを書けるようになったのか〜 by macopy

speakerdeck.com

現代のエンジニアが愛用している Coding Agent が生まれるまでの歴史が解説されていました。
WebGPT や ReAct など聞いたことがあったようななかったような用語が時系列とともに解説されていて、改めて理解が深まりました。
人間はコードを書くときに Web 検索をするはず、みたいな直感を原体験として研究が進んでいく流れは納得感がありましたね。

後半のライブコーディングも聴衆と一緒に作り上げる感じがすごくよかったですね。

Perl ブートキャンプ by Takafumi ONAKA

speakerdeck.com

裏番組だったため現地で見れていないのですが、気になってしまい資料を読んだので感想を書きます。

流石に現在進行形で Perl を書いていることもあり、大体の話はうんうんと頷きながら読むことができました。
とはいえ Perl がもとはオブジェクト指向言語として作られていなかったために bless と糖衣構文でなんとかしたんだぜ、というような歴史はあまり理解していなかったのでかなり面白かったです。

現代のオブジェクト指向の書き方は最早 Perl に見えない!
カンマ演算子なるほど、全然知らなかった。学びです!

Perl ブートキャンプはインターンの時に受講しているしな、と思って*2 Coding Agent のお話を聞きに行ったのですが、めちゃめちゃ楽しそうなトークだった。録画を見ます!

SREのためのテレメトリー技術の探究 — モニタリングSaaS開発からAIOps・AIインフラまで by yuuk1

speakerdeck.com

SRE として活躍なされた後に、その経験を基にしたアイデアを活かして学術研究の道へ進む、というのは個人的にはすごく理想的な歩みだな〜と感じました。

ログ・メトリクス・トレースの量的な膨大さとそれぞれのデータ形式の違いをどう扱うかが課題であり、SRE ドメインに特化した時系列基盤モデルに期待している、という話はすごく納得感がありました (「データセットを得るのが難しい」、そうですよね...)。

初仕事を親だと思ってしまった

面白い。
初仕事として携わった領域に熱中し続けられる、というのはすごく憧れますね。

LT

プロジェクトの空気を読んで開発してくれるPerlのAIツールがほしい by kobaken

speakerdeck.com

+ をつけてスカラコンテキストで評価されるようにするテクニック、未だに忘れることがあり、ときたまテストを落としています。

間接オブジェクト記法に関して気になった方は以下のブログをチェック!
kfly8.hatenablog.com

Pythonを"理解"しているコーディングエージェントが欲しい!! by nikkie

ftnext.github.io

logging に fstring を用いると表示しないログに対しても評価が走ってしまうのでパフォーマンスが悪い、みたいな話があるんですね。なるほど知らなかった。
気にせず使っていたので気が向いた時に Linter の設定に追加しておこうかなと思いました。

LT でライブコーディング (ライブ AI コーディング) する体験、会場に人数が多い分ワイワイ応援できて楽しかったですね。

認知ではなく良い体験設計を追求する、そのための広告プロダクト開発組織における『Bet AI』とは by ほにゃにゃ / yuki

speakerdeck.com

LT とは思えないスライド量で、AI と属人性に対しての熱意を感じました。
これぞ LT という感じでしたね。

プロダクトにも、チームにも。サイボウズがAIと共に歩む理由 by tasshi

speakerdeck.com

Cybozu さんがどのように AI を活用されているかが分かりやすく紹介されていました!
プレゼンが上手い!

AIが見張り、人がもてなす — 全国400店舗のカラオケBanBanの運営をサポートするAI Agent by 西尾健人

マルチモーダルな情報を用いて異常検知を行うということで、僕の LT の内容と関わる部分があるな、と思いながら聞いていました。
めちゃめちゃ気になるところで終わったので、続きが聴きたくなる LT でした!

*1:文字列が長くなると処理が重くなる正規表現の書き方があるな〜と思ってはいたが、事象の名前は知らなかった

*2:というのと、macopy さんのトークは AI がテーマということもあり、自分の LT の温度感を掴むためにも見ておきたかった

YAPC::Fukuoka 2025 に参加し、「基盤モデルのアーキテクチャを改造してみよう」という LT をしてきました!

はじめに

YAPC::Fukuoka 2025、最高でしたね!!!

実は自分は YAPC 初参加だったのですが、同世代の IT 技術が好きな方々や、父と同世代くらいの IT 技術の黎明期から活躍されている方々とも喋ることができたりとすごく充実した 2 日間でした!
yapcjapan.org

二次会終わり

LT をしてきました

しれっと出していた LT のプロポーザルが幸いにも採択されていたので、初日の LT の一つとして自分が開発している「時系列基盤モデルをマルチモーダル拡張する」ライブラリと、それに関連する活動について発表させていただきました!
speakerdeck.com
どうしても話す内容が 5 分に収まらなかったので直前にコンテンツを削ったのですが、本番では緊張により思いの外早く最後のスライドに辿り着いてしまい、急遽削っていたコンテンツを巻き戻して話し始めるという暴挙に出たりもしました。
なかなかライブ感のある発表をお届けできたのではないでしょうか? (反省)

発表後に id:taiseiue さんに「LT を聞いて時系列基盤モデルに興味が湧きました。早速 Google Colab でプロジェクトを作りました!」と言ってもらえたり id:y_uuki さんにモデルについて具体的な質問をしていただいたりと聴講者の方々が多少なりとも関心を持ってくださったことが分かって、発表者冥利に尽きる思いです。ありがとうございます。

聴いたトークなど

めちゃめちゃ長くなってしまったので、エントリを分けました。

おわりに

YAPC コミュニティの良さを実感できた 2 日間 (+ α) でした。
とともに、まだまだ未熟だなあと改めて実感したので、次回の YAPC::Tokyo 2026 までにさらに精進したい!
とりあえず CPAN Author になりたいのと、Perl に限らずプログラミング言語の気持ちをもう少し理解できるようになりたいですね。

LT の最後に「動的型付け」と「どう敵にカタをつけるか」の両方を表すような文を使って Perl 謎かけを披露しようか迷っていたのですが、何も思いつかなかったので没になりました。
次回登壇する際にはリベンジしたいです。

謝辞

スタッフの皆さん、設営や配信などありがとうございました。
そして忘れ物をしたりとご迷惑をおかけしました、すみません。

カケハシさん、コーヒースポンサーありがとうございました。
京都のおすすめの喫茶店も紹介していただきました。今度寄ろうと思います。

ビアキチさん、美味しいクラフトビールをありがとうございました。
僕はビールが得意な方ではないのですが、フルーティな味わいでスッキリ飲めました。すごく好みです。