株式会社はてなに入社しました
9 年目に入ります。自分が先頭となってものを作ってるかどうかがやはり楽しさの源泉だなぁ。 このときの「ものづくり」は「私が考える望ましい方向への変化」と言い換えられるけど、具体的なアクションを取るのが自分であることは手放せない。
まだ触り始めて1ヶ月ぐらい。困りが発生する程度には使ってきたとは思う。
主に Laravel コミュニティで管理されている OSS。ひと言で言うとフロントエンドをモダンに書けるようになるアダプタ……かなぁ。GitHub でも 7000 star 集めているぐらい。ちょうど先週 v3.0.0 が出ましたね。元気に開発されています。
概要は僕もこの後説明するけど、作者のブログ記事 を見るのが一番イメージ沸くと思う。
Inertia.js は、古き良き Web アプリケーションフレームワークの View 層のみをモダンな UI フレームワークに差し替えられるもの、という理解をしている。決定的なのは Routing をサーバが持つこと、レスポンスをサーバが返しているかのような感覚で書けることだろう。
具体例は 公式サイトのファーストビュー が十分に分かりやすい。
いつもの Controller で、最後に Inertia::render。描画するコンポーネント (Users) と props (users) を渡している。
<?php # UserController.php class UsersController { public function index() { $users = User::query() ->active() ->orderBy('name') ->get(['id', 'name', 'email']); return Inertia::render('Users', [ 'users' => $users, ]); } }
View 側はいつもの Vue で、props を受け取っている。
<!-- Users.vue --> <script setup lang="ts"> import { Link } from '@inertiajs/vue3' defineProps<{ users: User[] }>() </script> <template> <div v-for="user in users" :key="user.id"> <Link :href="`/users/${user.id}`"> {{ user.name }} </Link> <p>{{ user.email }}</p> </div> </template>
MPA の概念のまま、サーバから props を View に渡すところを受け持っているのが Inertia.js。フロントエンドは Vue, React, Svelte に対応しています。
ここまでだと react-rails で render component: 'Users', props: { users: users } したのと同じでは、と思うかもしれない。
Inertia.js の体験が良いのは、サーバ側のアダプタであるだけでなく、「フロントエンドのフレームワーク」でもある点が大きい。
クライアントでは <Link> コンポーネントを使って遷移する。Link をクリックすると、XHR して SPA 遷移する。
render :inertia がリクエストの方法に応じて出し分けるようになっていて、
<div id="app" data-page='{"component":"...","props":{...}, ...}'> という HTML を render し、component と props を渡す *1JSON が返ってきたときにその component を render するのはフロントエンド側の Inertia.js 側が受け持っている。そしてこの仕組みは X-Inertia ヘッダの有無によってサーバが自動で render し分けている。シンプル。
Rails に長く触れてきた人には「Turbolinks のツラみを解消している」と言えば伝わるだろうか。PJAX を推し進めて、JSON を返し分けるようにしたことで、UI フレームワークとの間をもっと上手く取り持っている。
Inertia.js はサーバ側の規約と、クライアント側のフレームワークなんです。
フロントエンドは routing を持たず、ただサーバにリクエストを投げる。
ページ遷移をするときは
import { Link } from "@inertiajs/react"; <Link href="/">Home</Link>;
で遷移する。これはサーバに fetch で request を投げ、サーバが response となる { component, props } を返して、クライアントはそれに従って描画する。
Flash 表示をしたければいつも通りに Flash に詰めたら、クライアント側でその Flash が描画される。
Form もサーバにクライアントサイドから POST される。サーバはいつも通り扱うだけでいい。validation についても以下のようにいつも通りに書くだけ。
class UsersController def create user = User.new(user_params) # いつもの感じで validation して if user.save redirect_to users_url, notice: "作成しました" else # 失敗したら errors を詰めて form に返す redirect_to new_user_url, inertia: { errors: user.errors } end end
これで Form 側では props に errors が入っているし、Form の state はクライアント側で維持されている。フロントエンドのフレームワークであるというのが効いていて、ページ遷移として POST しているのではなくクライアントサイドで request を投げているので、response を受け取ったときの動きが上手く統合されている。
deferred props という仕組みがあるのも面白い。重い処理は deferred にして page は先に render してしまい、クライアント側から追加で取りに行く。これをサーバ側の指定のみで書くことができる。
render inertia: "users/index", props: { users: User.all, stats: inertia.defer { HeavyQuery.run } }
「component 名と props をサーバから渡す」から想像できるよりも、何を描画するか、どう描画するかの主権はずっとサーバ側にあると感じるんじゃないかな。これが一番の特徴だろう。
API + Frontend や、Next.js と比べたいって声は当然あると思う。
「モノリスである」「主権はサーバにあり page 単位で考える」が大きな違いと感じている。
例えば session はサーバ側でいつものように管理するし、データの fetch は page 単位 (＝controller が常に起点)。バリデーションも認可もサーバ側でいつもの感じで書く。本当にいつも通りで最高。
co-location の書き味では GraphQL や RSC に大きく劣るだろう。欲しいデータをクライアント側から指定することはできない。page 単位で props が渡されるのを持ち回さないといけない。*2
API 境界がない (props を動的に受け渡しているだけだし、どんな props を受け渡すのかの静的定義は用意されていない) というのも違いになり得ると思う。が、後述するように明らかにツラすぎるのでここはまず定義することになる。
Inertia.js を採用するときの決め手は、サーバを API サーバとしてではなくページ遷移を中心として捉えるかどうかだと思う。 あくまでサーバが主で、クライアントは View と割り切れるチームだとちょうどいい。クライアントサイドでアプリケーションを構築するもの、サーバはデータを提供する API、と考えている人が多いチームだと厳しい。
フロントエンド専属チームを用意しない人数規模に最適だと思っていて、サーバ起点の設計を維持しながら、モダンフロントエンドフレームワークも組み込みたいときには強く選択肢に挙がると感じた。
Pjax/Hotwire/htmx との違いについては、サーバは HTML 断片ではなく props を渡すのでモダンフロントエンドと同居できる、が一番の違い。次に Hotwire というか Turbo Frames とは「HTML 断片ではなく page 全体を返す」という違いがある。部分更新ではないという意味では Turbo Drive に近いんだけど、かなりレンダリングに介入できるので Turbo Drive よりフロントエンドを扱いやすい。
フロントエンドに型が無いと書きづらいのは、これはさすがに当然そうです。文化がそうなっている。
型が無くても開発できるのは DB の型を知っているからというのはあって、フロントエンドには DB をそのまま露出するわけにもいかないので型定義がここで途切れる。露出するコンポーネント (DB からフロントエンドに Serializer 層で変換したもの) の型は定義すべき。
自分では OpenAPI Spec を書く (committee gem を使った validation はできないんだけれど) という選択肢を採った。将来的に API サーバに転生する未来はありそうだし、Spec を書いておいて損は無いだろう。 *3
逆に Serializer 層から型定義を生成するのは https://github.com/skryukov/typelizer を使うといいんじゃないか。私は使ったことないのでオススメ度合いも微妙なところなんだけれど。
routes をサーバに持つ、ということでフロントエンド側で request path を組み立てる仕組みはデフォルトでは用意されていないんだけど、これもさすがに無いと生きるのがツラい。
サーバ側の routes を SSoT とした URL 組み立て (＝named routes) をフロントエンドでも使える仕組みが必要になる。幾つか選択肢があるけど私は js-routes gem を使いました。
https://inertiajs.com/docs/v3/advanced/server-side-rendering
みたいな感じ。
JSON を返す X-Inertia request に対しては SSR されないし、する必要も無いというのは非常に自然で好き。
MPA として考えたら描画に必要なものだけなので特に差が無いんじゃないか。サーバで HTML をレンダリングしているという発想に戻せば困らない。
なんだけど、当然サイドバーを常に毎回描画し直す必要無いよねとかはあって、そういうのもちゃんと用意されているので工夫しましょう。*4
https://inertiajs.com/docs/ は各ページに「Copy page」ボタンがあり、クリックすると markdown がクリップボードに入る。
https://inertiajs.com/docs/llms.txt の内容ですね。
これは Rails の人向け。不安を減らす理由の一つになるんじゃないか。
(日本語訳: Rails: Inertia.jsでRailsのJavaScript開発にシンプルさを取り戻そう（翻訳）｜TechRacho by BPS株式会社)
inertia-rails 自体の積極開発もそうだけど、alba-inertia や typelizer も開発していて、意思が見えるので乗っかりやすい。
Inertia.js はサーバ側は規約 (なので Laravel 以外にも Rails や Django やらなんやかんやがある)。フロントエンドは Pjax をかなり推し進めたもの。
あまりにもいつも通り書けるからビックリすると思う。Rails の 7 つのアクションをそのまま使っていて構わない。これでいいんだよ。
「画面を見れば DB 設計と RESTful URL がイメージ付く」ぐらいまで訓練されてしまった Rails 戦士にとって、Inertia.js を使ったアプリケーション開発は、いつも通りのサーバサイドを書きながらモダンフロントエンドを導入できるいい選択肢です。
データストアというかインフラ費が安くないと継続運用できないので、色んな (とはいえある程度メンテコストの低い) データストアを試しています。以前は SQLite3 + Litestream + S3 を試していました。
PostgreSQL 互換の分散 DB です。マルチリージョンでのアクティブ・アクティブ構成ができる自動シャーディングされるデータストアで、イメージとしては Spanner みたいなヤツですね。
公式ドキュメント に書いている以上にたくさん違います。(私が見ていた頃 (半年ぐらい前) からドキュメントだいぶ増量されている！)
書いてあるものとして
postgres database しか使えないTRUNCATE が無い
DELETE FROM や DROP TABLE を使えSERIAL 型が無いCREATE INDEX が無い
CREATE INDEX ASYNC があるA transaction can modify up to 3,000 rows, regardless of the number of secondary indexes
The 3,000-row limit applies to all DML statements (
INSERT,UPDATE,DELETE)
他にも ALTER TABLE は制限がキツくて色々動かない。
ERROR: unsupported ALTER TABLE ALTER COLUMN ... DROP NOT NULL statement
ERROR: unsupported ALTER TABLE DROP COLUMN statement
DROP COLUMN できない！！ので、新しいスキーマでテーブルを作って、データを移して、RENAME TABLE するのがデフォルトかなーって所感です。
データを移そうとしたらこれもまた制限に引っかかったので、試行錯誤するのには本当に向いていないなと思います。オペレーションは慣れたら行けそうとも思う。実際そんなに困ってない。
ERROR: transaction row limit exceededERROR: transaction size limit 10mb exceededDSQL の先人としては以下のブログがありそうです。
幾つか違いはあるものの概ね postgres なので postgresql_adapter を拡張します。
特に困るものとしては
CREATE INDEX が無くて CREATE INDEX ASYNC であるで、軽く探したらあったのでありがたく使わせて貰っています。
特に primary_keys は自分で対応を思いつけなかったので助かりました。
あと公式のサンプル。
異常に安い。
まず無料枠がある。
https://aws.amazon.com/rds/aurora/dsql/pricing/#Free_tier
Each month, your first 100,000 DPUs and 1 GB of storage are free and automatically applied to your monthly bill.
DPU は多少しっかり使うと (毎時データをゴリッと読み書きするような Job 動かすとか) お金が掛かりますが、そうでないリクエスト数の少ないサービスなら無料なんじゃないか。
そして従量課金です。
私は普段は 無料〜$0.1 で、割とゴリゴリと使った月でも $5 とかで暮らしています。RDS や Aurora で postgres を立てるとこうはいかないので、少ないリクエストで動いている限りは従量課金は最高。
分散 DB の良いところ (マルチマスタを実現する技術) はまったく気にしていなくて 1 node として使っている目的外利用だろうから、今後どこかで値段が上がってウワーってなる気はしている。
ほとんどを TOHO シネマズ 二条 (自宅最寄り) と MOVIX 京都 (職場最寄りのシネコン) で見ている。T・ジョイ京都、イオンシネマ京都桂川、アップリンク京都、出町座はそれぞれ 1-2 回ずつぐらい。京都は映画館が多くてメチャクチャ過ごしやすい。
44 本かー。去年が 43 本、一昨年が 46 本なので、このぐらいで安定かな。予告編を見ると見に行かなきゃって気持ちになるので割と継続的に行くことになっている。
一番見て良かったなぁって思ったのはベスト・キッド：レジェンズだなー。これはもうこの作品自体がシリーズの集大成なのでほぼアベンジャーズです。
その後色々と調べたり映像見たりしたのはトワイライト・ウォリアーズ。九龍城砦つながりで GetBackers -奪還屋- を読み返したりもした。
多分私のまわりは見てないんだけどオススメしたかったのはロマンティック・キラー。
羅小黒戦記2はもっと話題になってくれ。秒速5センチメートル(実写)は API 納品する職業に就いた貴樹のシーンをたっぷり見られるのが良かったです。地獄の黙示録は今まで見たことがなかったので、劇場で見られて良かった。ダマガールは 2 年以上待っていたのでついに配給されて本当に良かったんだけど、どうしても「Kendama World Cup の映像をもっと見たい」って思ってしまった。アバターはいつも通りだけどいつもより良かった気がするな。ぜひ本物の黒で見てくれ。
あれ、去年も一昨年も書いてなかったな。
去年の 12 月に引っ越したが、引っ越しを契機に買ったものはあまり無い。レイアウトが変わったので、ベッドのサイドテーブルとしてニトリの チェントロ2 25DBR と、ウォールラックとして IMIEE 突っ張りラック を買った。それぞれ物を置く場所として妥当に活躍していると思う。
電子レンジが急に壊れたので買い換えることになった。象印マホービンが電子レンジ出してるの知ってました？私は知らなかったので面白いかなと思って ES-GW26 を買った。(1ヶ月後に ES-GX26 が出て型落ちになるのは知ってたけど、買い換える必要があったんだから仕方ない)
あたためる時間を秒じゃなくて温度で指定するのはナルホドねとなった。
耳はイヤーカフ型の Shokz OpenDots ONE を買った。 イヤーカフ型の良品として、既に HUAWEI FreeClip を持っていたが、手が滑って買い足した。耳を挟む力は FreeClip よりかなり強めなので、耳から外れて飛んでいくことはなさそう。代わりに丸一日着けているとちょっと耳が痛いし、少し重い。アプリから Dolby Audio を ON にすると Google Meet でも全員いい声になって面白かった。来年に向けては HUAWEI FreeClip 2 を支援済みなので、この辺りがメイン耳になるのだろう。
年 1 ぐらいで買い足している 7-8 インチタブレットでは HEADWOLF FPad 7 を買った。だいたい落として割るたびに買っていて、今回は Alldocube iPlay 50 mini Pro からの買い換え。買った直後に Alldocube iPlay 70 mini Ultra が出たのでちょっと失敗したと思っている。使い道は本やマンガを持ち歩くのと Slack/Twitter と、稀に動画を見るぐらいなんだけど、たまーに音出して動画見ようとしたときにスピーカーが片側にしか無いのは多少残念。
今年はモバイルバッテリーや充電器、USB-C をマグネットにする変換アダプタ等を CIO で揃えた。
あと面白として Jackery ポータブル電源 1000 New と のんべえ横丁 NBE-1 を買いました。2026-01-11 に 京都嵐山耐寒開運リレーマラソン に参加することになっているので、寒い中で温まるグッズを買っておく必要がある。絶対走りたくない、助けてくれ。
ガジェットはもちろんヘビーユースしているが、他もいくつか挙げておこう。
テンピュールのスリープマスク は日が出た後に寝るときに便利。ゆるふわPodcast EP281 2024年買ってよかったもの を聞いてコンバージョンした。1年経った今もまだ使っていて、本当に良かった。
![テンピュール(Tempur) スリープマスク アイマスク 睡眠用光をしっかり遮断し快眠旅行/出張にも 軽量 優しくフィット 圧迫感を軽減 睡眠グッズ フリーサイズ サイズ調節可能 2年保証 低反発 [日本正規品] 83300320](https://m.media-amazon.com/images/I/31mQwsjATWL._SL500_.jpg "テンピュール(Tempur) スリープマスク アイマスク 睡眠用光をしっかり遮断し快眠旅行/出張にも 軽量 優しくフィット 圧迫感を軽減 睡眠グッズ フリーサイズ サイズ調節可能 2年保証 低反発 [日本正規品] 83300320")
IKEUCHI ORGANIC のバスタオル を京都の店舗で買った。Podcast IKEUCHI ORGANIC と 坂ノ途中 のなんでやってんねやろ？ を聞いているので、買うかーと思って。聞き覚えのある声で益田さんが応対してくれたのは最高。
ローソン販売「ゼルダの伝説 ハイラルの紋章」タンブラーとショルダーバッグは RubyKaigi で移動中に買ったのでよく覚えている。ちょうどこのサイズのカバンが欲しかったんだよね。
あと日常使いのカバンが 北陸Ruby会議01 の移動中に壊れたので Nordace Siena Pro 15 を買った。これは誕生日プレゼントとして妻に買って貰った。移動中に被っている (色は違う) のを何度か見掛けている。
あ。Nintendo Switch 2 は普通に遊んでます。C ボタンは一度も使ってないっていうかそもそも他人が必要なゲームはやらないのでアレなんだけど。初回に買えてしまった責任としてちゃんと使っている。
ある日 Slack で雑談していて、
僕の考えた最強の< >ツール なんか作りたいよね。なにかないか。
って流れになった。定番どころで、OS、コンパイラ、ブラウザをまず想像したけど、そう言えばずっとファイラー作りたかったんだよなぁと思い出した。たぶん 15 年ぐらいずっと欲しいって言ってたと思う。
Windows を使っていた頃は あふｗ ユーザーだったので、あの体験が懐かしいなぁと思いながら暮らす日々でした。*1
2 画面ファイラーの良さは省略します。言うまでもなく最高なので。
やるかーと思って「double_drive」ってプロジェクト名を決めた。あとは AI と壁打ちしながら作ったのがコレです。
curses を生っぽく使うのかなと考えていたけど、少し調べてみたら TUI な枠を描ける RubyGems や CPAN module がいくつかあったので、せっかくだし使ってみています。
ガワが出来たら中身書くのは簡単ですね。毎日ドッグフーディングしながら欲しいコマンドをどんどん足していくのを楽しんでいる。
ごく普通の 2 画面ファイラーです。
自分好みのキーバインドや挙動にできるのは最高で、選択も確認ダイアログも出さずにいきなり c で反対側ペインにコピーしているし、テキストファイルのプレビューでは bat をそのまま起動しています。
アーカイブファイル (zip とか) の中に潜れるようにした瞬間からグッと使い勝手が良くなりました。Mac の Finder が苦手なところなので、それはそう。
他に自分好みの機能としては、例えば x でそのディレクトリをカレントにしたシェルを開くようにしている。この実装は system('tmux', 'new-window', '-c', $current_dir); としていて、tmux は基本立ち上げっぱなしなので、この方が嬉しい。e で vim を立ち上げるときも同じく tmux の window にしている。こういう細かいところに手が届くのは最高。
bundle gem double_drive と打った後、Claude Code を立ち上げて
新しい gem を作ります。TUI アプリケーション (ファイルマネージャ) です。まずは gemspec を埋めましょう。 https://github.com/onk/double_drive に push するつもりです
⏺ gemspecを更新しました。以下の変更を行いました：
- summary: "A dual-pane terminal-based file manager" - デュアルペインのTUIファイルマネージャという要約
- description: より詳しい説明を追加
- homepage: GitHubリポジトリのURL (https://github.com/onk/double_drive)
- metadata:
これでgemspecの基本情報が埋まりました。RubyGems.orgに公開する準備が整っています。
⏺ コミットしました！double_drive という名前から推測しました😄
変更内容：
人間味があって非常に良い。
YAPC::Fukuoka の前からボチボチ触っていたのだけれど、YAPC の後に気持ちが乗っていたので「Perl で作るか」と思って作り直した。
やりたい気持ちの根っこは「Perl 5.42の最新機能はどこまで AI で書けるのか」という疑問の解消です。
package を封印して全て class 構文で書いてみたり、1, 0 を使わずに全て builtin boolean で書いてみたり。
Perl の TUI ライブラリとして、Tickit に乗っかってみた。自分でメインループを回さなくても勝手に非同期に描画されるので、Ruby のときの tty gem とは書き味が違う。callback を多用することになった。
また、確認ダイアログを出して結果を受ける、みたいなのを書こうとして、callback が嫌になって Future::AsyncAwait を使うことにしたのも面白ポイントです。Perl でも async/await を書けるぞ！ 本人が実装について語ってるブログ が面白かったので読んでくれ。
全てがインスタンス作ってメソッド呼び出しになるんだよな。それはそうなんだけど。
元々 Perl では関数を import して右から左に書いていく (こういう書き方をするからパイプライン演算子が欲しくなるのだが) コードをよく書いていたと思う。
my $content = path($file)->slurp_utf8; my $lines = [ map { chomp; $_ } split /\n/, $content ];
こういうのが結構減って、全てが class のインスタンスへのメソッド呼び出しに変わっていくなぁ、というのは面白い気づきだった。いや別に今まで通りに書けばいいんだけど、目の前にオブジェクトがあるとメソッドにしたくなる力が働くんだよね。
あと class を使って書くと綺麗にカプセル化されてしまっていて、Perl の bless で作られたオブジェクト指向でよく扱っていた内臓を直接触るかのようなメタプログラミングがすべて封じられている。めちゃくちゃテスト書きづらい……。
akr さんの APIデザインケーススタディ を読んでくれ、という感じなんだけど。
こんなに楽して書いていいんですか、となることが多いね。FileUtils も Open3 も便利……。
TUI ライブラリが全角幅に対応していないことが多いこと多いこと。Pull Request いっぱい出すことになるし、いやしかし描画は確実に遅くなるので自分がメンテナだったとしても入れるか悩むだろうし難しいなぁって思うから出すのも悩むし、困る。
あと Mac でファイルパスを扱っているので NFD/NFC 正規化問題も踏んでる。
Sixel かなぁ、iTerm2 にして iTerm Image Protocol かなぁ、Kitty にして kitty graphics protocol かなぁ、と考えて、Kitty にしました。
ターミナル上の任意の場所に急に画像を出せるの、自分で使っていても一瞬ビックリするし便利で面白い。
何ら問題ないですね。class 構文もサブルーチンシグネチャも try-catch も builtin boolean も元気に使いこなしてくれる。
boolean は慣れてなくて最初のコードでは絶対 1 を返してくるし、ファイルの末尾に 1; も付けてくるし、try-catch 使わずに eval してくるので、手放しってわけではない。都度「v5.42 って言ったよね」と言うことで自分好みのコードを書かせている。
class と signature は本当に問題なく使ってくれる。
Claude (Sonnet 4.5 でも Haiku 4.5 でも) でも Codex (gpt-5.1-codex-max) でも、Copilot (Gemini 3 Pro) でも、Perl の扱いに関してはあまり差は感じてないなー。
ファイラーを作るとあのカオスだった Downloads ディレクトリや .Trash ディレクトリが掃除できました。すごい成果だ。
毎日ドッグフーディングできる (機能を思い付いて改善できる) 遊び場があると楽しいですね。
https://github.com/onk/double-drive_perl
すっかり忘れてた orz
*1:そこまで本気で探してもいなかったので mc や ranger 等は使ってなかった
函館でも登壇、広島は前夜祭登壇、京都で登壇、と割とずっと登壇機会をいただいている。
今回の資料は以下。
今回はワークショップ枠がある、ということで、じゃあ弊社の講義を (資料は普段から公開してるし) そのまま実施しよう、というプロポーザルでした。せっかく Perl の名を冠した YAPC なんだから Perl のトークも楽しんで聞いて欲しい！その前提を即席養成講座で叩き込むぞ！という場です。
1 時間まるまる言語仕様について話してみたけど、目的は達成できたかなー？
それぞれのカンファレンスには、前提として押さえておくとより楽しめる要素があると感じている。
辺りを知っていると、会期中に出る話題がなぜ注目されているのかが分かってより楽しめると思う。
で、YAPC だと「Perl の昔と今」が知っておくべき前提知識だと思っていて、最近のコンテキストをインストールするのも目的に入れました。
特に Announcing Perl 7 辺りから加速している、よりよいデフォルト値に移行していく流れですね。
この後色々あって、デフォルトを変えると非互換が大きいとして use v5.42; を書く流れになっている。バージョン宣言を書くことで、例えば v5.36 からは間接オブジェクト記法が無効になっているし、v5.42 ではスマートマッチも無効になる。逆に有効になるものだと signatures や try が特に特徴的で、普通のことを普通に書けるようにする流れがある。この流れを頭に入れて、その上で色んなトークを聞いて欲しかった。
id:kfly8 の Zenn の本 とも似たモチベーションかもなぁ。
普通のことは普通に書けるのは入口として前提として、更に記号や暗黙の $_ の利用が多いのは逆にゴルフに向いているし全能感が出て楽しいよね。
1日目に急遽発表された「踊り場」。いわゆる「カンファレンスの廊下」の延長としての枠ですね。廊下っぽい会話を作りたい！という 
id:Pasta-K の熱意で生まれた枠だと認識しています。
その踊り場で、私は「Day 1 最速振り返り」という枠を担当しました。ランチタイムなので、ある程度人が集まるのが確定していたという、立地条件で成功が決まっている枠でした。
スピーカーがそこそこ集まるだろうから、スピーカーに自分のトークの肝を説明してもらおう。スピーカーが居なかったらトークを聞いた人にマイクを渡して、どんなトークだったか、一番印象に残ったのはどこだったか、等を聞けば成立するだろう、という読み。
一応公開されているスライドは集めて読んで、その時間帯のツイートも一通り見てから司会に当たったんだけど、「めっちゃツイート見てるんですね」って言われたのは面白かったです。そんなまるでツイ廃みたいな。
ここだけのひみつ：20 セッションぐらいだから 1 枠 5 分程度で回したら全セッション網羅できるな、という計算違いをしていた
id:moznion の「OSS開発者なら学生参加者いっぱい集められる説」は学生と OSS 開発者との座談会になって非常に良いコンテンツだった。興味を持つリポジトリが無い人に、自分が飽きているリポジトリを譲ってメンテして貰うマッチングサービスは実際面白いんじゃないか。受け取っても大半が燃え尽きそうなので半年後とかに引き継ぎチェックを入れたいが。
id:rokuokun の「教科書では知れない令和最新 Perl ワード解説バトル」は、
id:dankogai を呼んだのが勝因でしたね。
@dankogai Perlスペシャリストがめっちゃ発話できるイベントを #yapc踊り場 でやってるんで今すぐ来てください
— moznion (@moznion) November 15, 2025
弾さん来た！！！！ #yapcjapan #yapcjapan踊り場 pic.twitter.com/1l1HFrVODc
— moznion (@moznion) November 15, 2025
あと id:kfly8 や 
id:charsbar が答えるメンバーになっている、非常に豪華な場だった。
id:rokuokun の準備も上手くて、前日の 2025年秋のPerl を見て分かんなかった単語を「これ何ですか！」と聞いていくスライドだったので、そうそう、廊下ではそういう質問して欲しいんだよ〜〜って思いながら答えてました。
当日スタッフが全然足りない〜〜って話を社の Slack (コアスタッフが何名か居る) で噂を聞いて、しゃーないなと手を上げた。たぶん YAPC では初スタッフ業。
前日のノベルティ詰め作業は楽しかったですね。
当日の受付は、電車の到着ごとに 30 人ずつ程度のバッチが発生していたけど、難なく捌き切れたと思う。
あとはお昼にランチへの誘導したり、人が足りないところにアサインされる感じで回っていました。
私が話を聞きたい外タレは Paul Evans です。夢を言っておくとオードリータンの話は聞きたいですねぇ（言うだけはタダ）
最近はあんまり開発ど真ん中のトークをしていないので、来年は何かしら作った話を持って行きたいなー。頑張ります。
