今日は YAPC::Fukuoka 2025 の２日目です

YAPC::Fukuoka の２日目です。昨日と同様にメモだけ残しておきます。

ある編集者のこれまでとこれから —— 開発者コミュニティと歩んだ四半世紀 / inao さん

• 踊り場に来てください
• What is most personal is most general
  • 個人的なことを描き切った方が、世界に届く
• 運が良かった、環境に恵まれた、人に恵まれた
• 工学部を退学し農学部へ。読書、川下り
• 出版社の現場を経験したかった
  • 4/1 に来てと言われて行ったら、日曜日で誰もいなかった
• WEB+DB Press の初期から
• YAPC の半分は WEB+DB Press でできている
• YARPC 日本で最初の LT
• Perl Hackers Hub 2010-2023年
  • 著者探しのために監修者さん
• 全角を駆使した編集記号「inao記法」
• markdown2inao.pl / md2inao
• WEB+DB Pressは Perl でできている
• GitHub Kaigi
  • Github の方以外は WEB+DB Press の著者さん
• 入社当時は WEB+DB Press は「なぞなぞにしか見えなかった」
  • 「自分が面白い、理解できれば、みなさんも」
• LifeHacks PRESS がヒットした
• Vol. 32 でリニューアル
  • Ajax の時期 / Web 2.0
  • 17本連載スタート
  • これが非常にうまくいったのが成功の要因
  • 編集者 2.0
• 含まれるもの、含まれないもの、中心、は何か
  • Webアプリケーション開発のためのプログラミング情報誌
  • インフラ、開発、境界があいまいになった時期
  • 境界ではなく、中心を意識
• 自分は対象読者ではない
  • 「知りたい」駆動
  • 知りたければ書いてもらえばよい
• 「知りたい」→「役に立ちたい」
  • 声を掛けられ、うっかり転職
  • 転職しなかった会社の待遇の方が圧倒的に良かった
• t-wada さんに相談
  • 「ゼロから立ち上げの方が転職のストーリーとしては良い」「応援してもらえる」（待遇は低いが）
• 発刊されなかった137号も依頼済だった
  • 辞意を伝えたところで役員会で休刊になった
  • 続けられる基盤はできていたはず
• DevRel の社外メンター 941 さん
• 「開発者をつなぐ」
  • 境界を考える必要はない
  • 採用に関するミッションは持っていない
  • 「つなぐ」ことだけを考える。それが採用などにつながる
• 編集者として動く≒DevRel
• 会社の変更
  • 「編集者」の地位の上昇
  • 外部の評判を利用する / WEB DB Press に助けられた
• テックブログ
  • 前職と同じような動き（原稿料は発生しない）
• イベント
  • 雑誌の目次と同じような作り方
• タイトルのつけ方→良さを生かす
• アイデアと企画
  • 企画につなげるという意識を持って、習慣化する
  • 一週間過ごすと、１～３つは浮かぶはず
  • 思ったような反響を得られなくても、気にしない
    • 「俺は悪くない、世界は悪い」→もう一度挑戦
  • 及第点くらいの企画→放置
    • 寝かせるのが大事
• 松山で会い鯛
  • 鯛縛りはありなのか
  • 「鯛の被り物を買い鯛」
  • 「釣り船」「タイ焼き」「テーマソング」は没
  • 「今会い鯛、すぐ会い鯛」は伝わらず
• 企画の判断基準
  • びびってる、びびってない
    • 「マックでダイエットコーラを頼むのはビビってる」
    • 「時を超えた創造の原則」はビビってない
• 編集者とは？
  • DevRel でも「編集者」と言っている
  • 何についても一番詳しくない
  • 集めて編む者
  • Developer's best friend
    • 経験がないことに挑む開発者に伴奏する
  • いなお＝犬
• 組織に大きな変革をもたらすのは、最初の数年
• 編集者は 100～200人（国内）
  • 20年やり続けるコンピュータ情報誌の編集者は皆無
  • この経験を生かした何か。職業人生 *Q). キャリアへの不安や居心地の悪さは？
  • A). ない。それで今までやってきた
• Q). inao さん自身が記事は書きたくない？
  • A). 自分から伝えたいということはない。読むのは好き
• Q). 現職でメディアを立ち上げる？
  • A). エンジニアが希望すれば。今は「編集者」ではないキャリアを歩んでいるので
• Q). ビビってると感じた時の突破方法
  • A). 別の案を考える。デザイナさんに「どっちがビビってないか」
  • A). 今日はビビっているけど、違う意味でのビビり
  • A). ビビってるんすか？とは聞く

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

• 令和最新版 Perl BBS
  • https://yapc-fukuoka-bbs.kobaken.co/
  • キリ番ゲット
• CGI 1990 年
  • リクエストを受けた時だけリソースを利用（今時）
  • 書籍がたくさん出ていた
• mod_perl
  • WAF の出始め。ルーティング、DB、テンプレ、認証認可
  • Catalyst, Jifty, RoR
  • WEB サーバ、 Apache, lighttpd、 nginx
  • フレームワークとサーバの乱立 n×n
• 2009 年 PSGI/Plack
  • PSGI を満たせば入れ替え可能
  • 秩序を保って、多様性
  • 変化を促すのに、ルールを入れる、のが面白い
• 2005 年
  • デプロイで壊れる、自分の環境では再現しない
  • 様々な問題が発見され、言語化
  • パッケージ管理、 CI 、設計の進化、アクセシビリティ
  • 現代でも向き合っている問題
• 2011 年 Carton
  • Bundler / Go Modules / Cargo のようなもの
  • cpanm ではバージョン管理はできていなかった
  • @miyagawa ロックスター。今のあたりまえを作った人
• 複雑化する環境に「Perl」はどう対応？
  • ES: use strict, class構文、 let/const （イミュータブル）
  • 変化のための痛みは止むを得ないのか
  • 高い候補互換性「bugward-compatibility」バグに依存している挙動も壊さない
• OOP
  • bless 、 Moose
  • builtin class
    • 単一継承
    • 中身を触れられない
• 2010 年に keyword plugin が仕込まれた
  • Object::Pad で PoC ができた
  • builtin class として組み込み
  • Perl 自身に手を入れる必要がない
• とほほさん「OSS のサポート期間が短い」
  • 2～3年は年寄りには短い
• 2007 年 iPhone
  • UI/UX の変化
  • ガラケーの手法が厳しい。フロントエンドバックエンドが分離
  • jQuery は今も動くのがすごいところ
• 「課題」をコミュニティで話す
  • コンテキストが異なる人で話すと、抽象化される
• LLM
  • 古い書き方をする→古い書き方でも動くのは Perl の利点
• PEVANS: Perl をよくするには使い倒して、そんな無茶するよりいい方法があると言わせるといい
  • 機能を限界まで使うのはいいこと。新たな課題が見える
• 旧（９）世代の話
  • 「価値を届ける」のは変わりがない
• Q). Sledge は重要では
  • A). ごめんなさい。 mod_perl はカバーしきれなかった（謝罪）
• Q). 新しい書き方を進める良い理由は？
  • A). try/catch ハマりどころがない。諸学者の人にハマって欲しくない
  • A). 新しい人に学んでほしいのか。移行コストをかけたいのか
• Q). 古い書き方を AI に書かせる
  • A). 新しい知識が混乱する。コンテキストを絞るのが大事。新しい書き方のみをコンテキストにしたり
  • A). ドキュメントを整えていくのはやっていきたい。コンテキストをきれいに。

JavaScript🦏はPerl🐪の子孫である / dankogai さん

• JavaScript は書いたことがある人は多いが、 Perl を書いたことがある人は少ない
• Speaking JavaScript 書籍
  • ES5 の時代
  • Perl の影響が受けたことが書かれてる
• JS と Perl、 Python
  • Perl は語彙も挙動も類似
  • e.g.) 存在しない添え字を配列に指定した場合
  • Ruby は push も append も実装している
• Unicode
  • JS は Java 風（15bit）
  • Perl はバイト列の時代が長かった
    • Unicode の 1 文字をキャプチャできない
    • 2001 年に苦労をして UTF-8 で実装された
    • Python のへま→ビルドオプションによって文字列の長さが変わる
  • JS は UTF-32 と UTF-16 を併用
    • for (const chr of str) {}
• 国旗は code point を二つ使っている
  • Perl には \X があり、１表示文字にマッチする
  • JS にはまだない Intl.Segmenter を使う
• JS はスクリプト言語
• もともと Perl のカンファレンスだったはず
  • 悪いことではなく、 Perl コミュニティは正しいことをしてきた
  • LT も文字列の扱いも我々が正しかった
• Q). なぜ正しく UTF-8 を選択できたのか？
  • A). 後出しじゃんけんで勝てた
• Q). Perl は JS になれたのか？
  • A). ブラウザで動くのはなかなか

転ばぬ先のXS入門 / polamjag さん

• List::Util::min XS で書かれている
• 「インストールがコケる」が主要の問題
• Makefile.PL ExtUtils::MakeMaker
• Build.PL Module::Build Module::Build::Tiny
• Minilla Dist::Zilla
• App::cpm
  • fetch configure install
  • configure で Makefile.PL 作成、 install で実行
• XS
  • インターフェース記述ファイルフォーマット
  • XS はプログラミング言語
  • xsubpp で C へトランスパイル
  • ExtUtils::ParseXS
• Perl ランタイムは C で書かれている
  • 共有ライブラリ、静的ライブラリとリンク
  • Perl は静的リンクも可能
• ネイティブライブラリのラッパー
  • DBD::myaql, Perl, XS, libmysql-client
  • XS は Perl ランタイムと同じ土俵に上げられる
• 余談「ネイティブ拡張」という言葉は誰が使っている？
  • ruby の ビルド時のメッセージ説
• Perl ではツールやライブラリごとに共有ライブラリの指定方法がマチマチ
  • Makefile.PL がなんでもできてしまうため
  • e.g. mysql_config コマンド
• https://wiki.archlinux.jp/index.php/Perl_%E3%83%91%E3%83%83%E3%82%B1%E3%83%BC%E3%82%B8%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3 がわかりやすい
• perlxs perlapi perl****
  • perlguts Perll API のイントロダクション
  • いろんなドキュメントが多くて大変
  • 実践あるのみ
• Cpanel::JSON::XS DBD::mysql `Inline::Ruby
• encode_json を grep すると二つ出てくる
  • MODULE = Cpanel::JSON::XS PACKAGE = Cpanel::JSON::XS
  • これより前は C プログラム（ POD の未除去）
  • それより下が XS でエントリポイント
• XSUB: Perl 上での関数定義の単位
  • ALIAS 別名
  • PPCODE 以下が実装
  • PUTBACK / SPAGAIN / XPUSHs
• SV
  • PB IB RV
• AV HV
• スタックの操作が必要となる
  • 引数をスタックから取得
  • 戻り値をスタックに積む
  • perlinterp, perlgts, perlsub, perlffunc, perlcall などにスタックの話が出てくる
• PUTBACK / SPAGAIN
  • スタックを Perl ランタイムに書き込む
• pTHX_ マルチスレッド用のマクロ
  • sv_2mortal NEWSV
• aTHx_ 受け取ったものを渡すときに使うマクロ
• Perl を壊さないような変数操作などは xsubpp や C マクロに隠蔽されている
• *.c ファイルを見ると xsubpp の実行結果も見られる
• dbd_st_fetch `dbd_st_execute の二つを DBD 側で用意する
• dTTHX DBI のしきたりの初期化処理
• mysql_st_internal_execute41
  • mysqll_ で始まるものはほぼ mysql の関数
• Low-Level Inline::Ruby
  • my_rb_eval という機能がある
  • PREFIX = my_
  • PREINIT typemap に邪魔されない引数定義
  • rb2pl
  • rbrescue2 try catch
  • Ruby と Perl の値の変換ロジックは勉強になる
• 氷山の一角
• slu_sv_value amagic_call
• 別海
  • FFI など
  • AI が使えるかも
• Q). GC は自動？
  • A). 自分でやることもあるし、マクロが自然とやってくれることもある

やり方は一つだけじゃない、正解だけを目指さず寄り道やその先まで自分流に楽しむ趣味プログラミングの探求 / sugyan さん

• 「すっかりみんな年をとりましたね」
• 業務以外の時間にコードを書く
  • その時に興味があることを自由に
• AI がコードを書くのに？
  • 楽しいから書く
• 面白さ
  • 計算機の能力を引き出す
  • 動く
  • TMTOWTDI
• Adent of Code とは
  • Eric Wastl
  • 12 月に毎年 25 日出題される
  • 2019 年から参加（日本人は少ない）
• part1 と part2 がある
  • 入力は1つで、問題が変わる
  • 入力がユーザごとに異なる（友達に聞けない）
  • parse が面倒なものも多い（協議プログラミング的ではない）
  • 回答のみを提出する（答えが合うことが大事）
  • 多くの場合は part1/part2 で部品が使いまわせる
• e.g. 入力の整数値を仕様通りに実装するとブロック崩しができ、そのスコアを応える問題
• Reddit で解放の共有
  • https://github.com/sugyan/adventofcode
• e.g. 同じ文字の大文字小文字が連続しているときに取り除く
  • スタックを用意して1文字ずつ読み、マッチしたら pop 、それ以外なら push
  • s/(.)(?!\1)(?i)\1//
• e.g. 二次元座標の問題
  • Python の複素数 1 + 2j を使うと便利
• e.g. 点列が動いて、突然クリスマスツリーになる問題
  • いつクリスマスツリーが出るのか
  • AI が解くのは難しそう
  • png ファイルにして、 png ファイルが小さくなったのが答え（すごい）
• e.g. 壁が落ちてきて、いつ経路到達ができなくなるのか
  • BFS とか二分探索とか逆順で探索とか Widest path prolem とか
  • 可視化すると迷路になっていて面白い
• 今年は 12 日間になるらしい
• Advent Code を生成 AI に解かせるのは？
  • 人間が楽しむためのもの。友達をジムに行かせて運動になる？
• ペントミノ
  • 解放が多い
  • 子供のために買った→プログラミングで解く
  • 子供はすぐ飽きた
• バックトラック
  • 12! 5億通り
• Bitboard
  • ビット演算が使える
• 解けた
  • 高速化、 WASM 化
  • X 型(回転可能)を先に置くのがポイント
  • 6x10を70ms (速い)
• だんご屋の暇つぶし（子供のパズル）
  • パズルオーディション最優秀賞
  • ハノイの塔の亜種
  • 16 手の問題が最長
• フロントエンドもできると可視化ができて便利
• 解きたい問題、書きたい/読みたいコードは無限にある
• Q). 時間は？
  • A). 無理せず時間が取れるときに
• Q). パズルとビジュアライズの不具合の切り分けは？
  • A). ビジュアライズはおまけなので、同時にはやらない
• Q). パソコンを持ち歩くのは大変では？
  • A). 最近は外に出ていない

LT

Perl 9 / moznion さん

• Perl1 ～ Perl7
• Perl9 new
• Perl11 もあった
• Perl6 を上下さかさまにすればよい
  • Text::UpSideDown
• Plan 9 で Perl が動けばいいのでは
• /sys/src/cmd/perl/5.004/ が動く
  • perlplan9
  • 動くバージョンを探すのが大変
• 「連打するといずれ通るので頑張れ」
• Perl 4 + Perl 5 = Perl 9
  • Perl 4 は今ビルドできない
  • むずくてあきらめた
• Perl 4 を目を細めると Perl 9 ...?

Binary "pack" Rebooted in Perl 〜Rubyistの視点から〜 / udzura さん

• Perlと言えば・・・ Rubyですよね
• pack unpack
• バイナリパースや FFI
• フォーマット文字列を暗記するのが大変
  • CSLQZ* を覚える
• 1989 に pack/unpack 導入
  • Ruby には 1.0 の段階からある
• Ruby の利用しているメモリを Perl で覗くデモ

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

• モジュリーノ×オブジェクト指向＝探索的なプログラム開発に便利
  • ライブラリファイルが実行プログラムを兼ねさせる
  • Python の __main__
• OO Modulino
  • --foo=abc funcA みたいなのをコマンドライン引数として渡したい
  • TAB 補完もしたい
• MouseX::OO_Modulino
  • shebang を書く
  • ->cli_run(...) unless caller で判定可能
• 「ゴーン！」

小さなPerlスクリプトから続くOSS / nukumaro22 さん

• Linux にはジェスチャの選択肢がなかった（2012年）
• mac ぽくスライドしたい
• ログが出ている。指の本数、座標
• Perl スクリプト。デバグログが入力
• xSwipe 448 stars
• Synaptics ドライバでも動く、 perl は入っている
• OS アップデートでデバグログが消えた
  • libinput 対応
  • Ruby で xSqipe の再実装
  • fusuma 3.8K stars 3500行
  • fluentd 的なアーキテクチャ
• タッチパッド、ポインティングスティックは修飾キー
• 道具がより手がなじむようにするのは最高

ghqの秘密 / songmu さん

• Go Hot 九州
• もともと go get の挙動を模した
  • Mercurial Bazaar Subveirion にも対応していた
  • ghq も同様
• いろんなリポジトリをとるテストがある
  • git
  • svn (Code Repos)
  • CVS (列挙のみ)
  • git-svn
  • mercurial
  • Bazaar
  • Fossi (SQLite)
  • Darcs (Haskell)
  • Pijul (Rust)
  • Piper (以下は未サポート)
  • Perforce
  • Sapling (sl)
  • Jujutu

伝統的日本企業のソフトウェアエンジニアになって無双しよう！ / kurain さん

• 1960 年、797 名
• toC サービスをやっている
• 内政組織がない
  • 大量アクセス
  • リリースできない
  • 協力会社多すぎ問題
• 速く安定した開発
• Charaforio 、アプリデータ分析の内製化、新規開発、認知拡大
• 伝統的日本企業
  • セキュリティチェックシート
  • GitHub Codespaces アクセス禁止、貸与モバイル以外利用禁止
  • SaaS の禁止
• 物販とライセンス
  • セキュリティは大事
• 企業理念「みんななかよく」
  • 相談すればみんなやさしいので問題は解決する
• 今後はノベルティにも期待・・・！

ベストトーク LT / カヤックさん

• 鎌倉にサウナ、OKINAWA うんこミュージアム
  • 何やっているかよくわからない会社
• 面白法人は「みんな面白いんでしょ？」
  • オモハラ
• 自分たちが面白がる、面白い人と言われる、周囲の人を面白く
  • ストレートに面白い、逆に面白い、一周回って面白い
  • 演習力で振り落とされているから
  • 逆に求心力が働いている人が残る
  • 「なるほど」と思った人は騙されやすいタイプ
• ストレートに、誰かの人生を面白い
  • 真ん中を目指すのは難しい

Stay Hacker ～九州で生まれ、Perlに出会い、コミュニティで育つ～ / P山さん

• 旅先でタクシー捕まらない問題
  • GO株式会社
• KKD 勘、経験、度胸
• 2013 年 電力会社の ISP のサーバエンジニア
  • Postfix
  • 委託先が本物の自動化 「.pl」
  • プログラミングへの感銘
• ラクダ本を頭から読む
  • 仕事では使えず、伸び悩む
• モダン Perl 入門
  • 「デザインパターン」
• 習作が必要
  • フットサルの練習日程調整
  • Rails （ Perl での WEB に自信がなかった）
• 定期異動→保守
• オンライン面接「ある数字が素数かを判断」
  • 奇数を判定するプログラムを書いてしまった！
• 「計算量」の話がわからず
  • 雰囲気で触ったことのない Redis 発言
• 希望年収を低くすることで入れてもらえた
  • 「胡散臭くて最後まで迷った」
  • 420 万くらいにしてくれると思って 300 万と書いたら 300 万になった
• エンジニア評価制度
  • カンファレンスやコミュニティの活動が推奨された
• builderscon Tokyo でトークをさせてもらえた
  • 集客できなくて悔しい
• WEB+DB PRESS & Software Design
  • テクニカルライティングについて学んだ
• YAPC
  • YAPC::Fukuoka 2017 HAKATA
  • YAPC::Tokyo 2019
• 「九」州 良いコミュニティ
  • PHPカンファレンス福岡
  • 福岡 Rubyist 会議 / fukuoka.rb
  • Fukuoka.go
• 空港が近い→全国様々なカンファレンス
  • アウトプットを評価してくる場は、幸運
• 「熱」
  • 良くしたい
  • 言語、役職、職種の壁がない
• 「怠惰」「短気」「放漫」
  • 技術力で解決する人
  • 技術力が高いとコミュニケーソン能力も高い
• Hacker の仕事はプログラムを書くことではなく課題を解決すること
  • AI に奪われるものではない
• アイデアが浮かんだ後、コードを書き始めると写経になる
  • AI によって解消される
• AI によって変わらないと思うこと
  • やるやつはやるしやらないやつはやらない
• Hacker であり続けるために
  • いい課題、研鑽を続ける、事例から学ぶ
• Hack し続ける
  • 怠惰、短気、傲慢
  • 「手段」は変わる。「目的」は変わらない
• これをどう使うか、考え続けるのが Hacker

クロージング

• ドタバタでした
• ベスト LT 賞
  • GO 「運転手ごとの癖を学習して迎車したりしている」
  • moznion さん 「今日の日のためにやってきてそうだった」「ふざけたトークだったが、エッセンスは詰め込んだ」
  • 2+3万円九州グルメのカタログギフト
• ベストトーク賞
  • カヤック「スイッチ2は自前で買いました」
  • Sosuke Suzuki san / 「別のカンファレンスで話す予定だった」
  • 明太子,しゃぶしゃぶ、PaperWhite、Switch2
• 48 人のスタッフ、 419 人の参加者
• Ending ムービー
• 記念撮影
• 2015 年 YAPC::Asia
  • YAPC JJapan で 10 年
  • 全国各地でいろんな出会い
  • YAPC::Asia の場に戻る→ Tokyo Big Site 2026年11月28日、29日
  • 「YAPC::Asia と同じスタイルを再現する」

今日は YAPC::Fukuoka 2025 １日目です

YAPC::Fukuoka 2025 に来ております。一応ブログを書いた方が喜ばれると思いますので、拝聴したセッションの自分用のメモだけ置いておきます。

オープニング

• ヘルプページ（非公開）見てね
• 同時配信あり
• Slido を使う
• 飲食禁止、コーヒーNG
  • 蓋つきペットボトルの水とお茶のみ
• ベストトーク投票
• @yapcjapan #yapcjapan #yapcjapanA #yapcjapanB #yapcjapanC #yapcjapanD #yapcjapan踊り場
• 踊り場・・・大学生を集めた企画？

HTTP Message Signatures ― HTTPクライアントの身の証を立てる / @argrath さん

• Structured Field Value Data
  • ヘッダに構造化データ
  • integer decimal, string, token ,byte-sequence, boolean, date, display-string
• ASCII、ほぼネストはできない。制限をかけている
• パラメータ: セミコロンで付加情報
• 既存のヘッダとの互換
• 課題: クライアントは何者かを証明したい
  • 本当に本物からのリクエスト？
  • IP アドレス/User Agent では不十分
• HTTP Message に署名する
  • ヘッダが変わることは許容したい
  • 一部のヘッダの未署名する→どのヘッダに署名したか
• 例: Mastodon
  • Signature-Input/Signature
• Signature-Input
  • 署名するフィールドのリスト、 created、key（公開鍵）
  • 派生要素（ヘッダではないもの）は @ が接頭辞となる
• body については、 Content-Digest にハッシュ値が入り、このヘッダを署名
• フィールドを並べた文字列を署名
• Q). TLS ではダメ？
  • A). 特定の相手とやり取りするなら良い。相手は不明だがリクエストの出元を保証して欲しいとき
• Q). 仕様になって嬉しい
  • A). ですよね

Introducing RFC9111 / k1LoW さん

• 参考文献「web配信の技術」
• 今日の HTTP キャッシュの話
  • 共有キャッシュ
  • ゲートウェイ寄り
• RC7234 → RFC9111
• Envoy (RFC7234), mod_cache(RFC2616), Fastly (RFC9111), Akamai/Cloudflare(RFC7234)
• 3 年経つが未だに RFC7234 が参照されている
  • 破壊的変更が少ない、厳密な記述に変更、独自実装がすでに溢れている
• github.com/2manymws
  • 特殊な用途のミドルウェアを廃止
  • rp/rl/mm
• なぜ RFC9111 なのか
  • RFC7234 ではなくても受け入れられそう
  • そもそもすでに廃止されている
• キャッシュ・格納と参照
• 格納
  • どのレスポンスをキャッシュするのか
  • Cache-Control ヘッダ
    • no-store でも must-nderstand であれば、キャッシュしてよい
  • Expires ヘッダ
• 利用
  • Fresh : そのまま再利用可能
  • Stale : 鮮度寿命が切れている
    • オリジンサーバーへの検証結果によっては利用可能
• ディレクティブに競合があれば、より厳しいほうを使う
• public private は格納のみに影響する
• Tests for HTTP Caches
  • RFC9111 のテストチャート
  • ローカルでも利用可能
  • 厳しい（58.1%）
• Q). 画像調整サーバもRFC9111は気にするべき？
  • A). CDN の挙動が大事
• A). 複数オリジンでのキャッシュのためにライブラリを作る必要があった

AIコーディングの弱点、やっぱりプログラミングは人間が(も)勉強しよう

• LLM、 Transformer
• Attention is All You Need → 単語がどの単語を注目しているか
• Transformer は Attention と NW を多層にしたもの
• 言語モデルは金をかければかけるほど性能が上がる（GPT-3）
  • 億単位のお金をかける根拠
• チャットに対応するチューニング（GPT-3.5）
• 専門家モデルを複数、必要なモデルだけを使ってリソースを削減（GPT-4）
• Function CCalling/Tool Use : LLMから外部関数を呼び出す
  • MCP リモートで可能な Function Calling
• 考察過程を入れる（o1）
  • 深い層で出てきた知識を、浅い層に渡すために再投入
• reasoning を並列（一番いいものを回答） (o3)
• LLM の計算 Llama3-8B
  • ロジカルではなく、トークンの出現確率が計算が進むほど増える。
  • 3 桁の数までは1トークン
• 「教師」を超えることはない→機会が教師なら人類を超える
• ユニットテストが欠けない＝学習ができない＝苦手
• AI の弱点、コンテキスト処理能力、知らないことが多い
  • 長いコンテキストが苦手 / せいぜい 30K トークンくらい / プロジェクト全体を一度に見られない
  • コンテキストの汚れに弱い→同じ失敗が続く
• コンテキストエンジニアリングが大事→きれいにコンパクトに
• 知らないこと→実際にどう動くか、開発過程、ファイル以上の大きな単位
• プログラミング
  • 機能、性能、使いやすさ、安全性
  • AI が得意なのは機能だけ
• 実行のための機能→関数型、構成のための機能→OOP
• プログラムの最適化
  • 処理の重複の排除
  • キャッシュ
• 多胎の活用
• 単一責務→変更の発生源をまとめる。クラス利用者の責務
• 非機能要件は人間が頑張りましょう！

---

「データ無い！腹立つ！推測する！」から「データ無い！腹立つ！データを作る」へ / moznion さん

• サービスと「名前」
• 機械は「セブンイレブン」を理解しない
  • 「セブン」「ブンイレ」でもわかる
  • LLM ならわかるのでは
• 人間が見てもわからないものは機械もわからない
  • 「マツヤ」「コスモス」
• データはなくても困らない→困るのは必要になってから
  • 可能性が狭まる
• データがない、何もわからない、どういうデータが必要かわからない、の悪循環
• データがあるだけではダメで、使えるように整理してないと駄目
• 「AIでよくね？」
• 決定論的に計算できるものを LLM に計算すべきではない
• 「大本おのデのデータ」は今後価値を持つ
• 「何に使うのか」からデータを考える
• データを作るための「生データ」
  • あるのか、どこにあるのか、形式や構造
  • まずはここから
  • システムがデータを生む、 WEB を使う、買う
• ドメイン知識がないとデータを作るのは難しい
• 「辞書」を作る
  • 名称情報から「ラベル」をつける
• DuckDB が高機能で性能が良い、組み込み
• Gabage In, garbage Out →前処理できれいにする
• 人間に適したワークフロー→スプレッドシート
• データの後処理→テスト、ベンチマーカー
• SQLite のダンプは他の DB へ読み込ませやすい
• データ作りにもソフトウェア開発のベストプラクティスを使える
• LLM に Assist Tool を生成させる
• 人力を諦めない
• 孤独
  • 品質が高いデータができる
  • 超人以外は無理
  • ポシャりやすい
• 「なんの役に立つのか」
  • データづくりとシステム作りのフェーズはわけない
  • データをシステムに投入しながら
• 100% のデータというものはない
  • 小さな労力で、高い効果
  • 継続的に育てる
• データセットは作って終わりではない
  • データがどう使われいるか
  • 目的外利用→使いまわせるのは良いデータ
• チームを作る
  • ガイドラインを作る
• データを買ってビジネスを進めながら、自分たちで作ることもできる
• 1. 前処理の陳腐化はどうする？
  2. 1. ベンチマークの悪化から気がつけるとよい

なぜThrottleではなくDebounceだったのか？ 700並列リクエストと戦うサーバーサイド実装のすべて / yoshiori さん

• テスト結果の収集
  • AI でまとめる。原因、再現性、などなど
  • テストの分散→平均的に同じ時間で終わるように
• 700 並列でテストを実行するお客さん
  • ジョブキューでは意味がない
  • 処理を間引く Throttle や Debounce
• Debounce
  • データが集まるまで、待つ仕組み
  • タイマーをデータが来るたびにリセットする
• 没になった案
  • Rate Limit 、や缶バッチ、スケールアップ・アウト、ジョブキュー
  • クローズ処理はまとめられる
• Throttle より Debounce の方がより待機してよりまとめられる
  • クライアント技術→直列
  • クライアントもサーバーサイドも複数台ある
• Redis を使った実装
  • UUID を書き込み、変わっていなければ終わったと判断
  • Redis をロック代わりにした
• レースコンディション
  • atomiv に値を確認して一致したら削除する必要
  • LUA スクリプトを書くと解決
• Debounce は delay 時間の調整がキモ
  • 長過ぎると遅延
  • 短すぎるとまとめられない
• 二つの要件
  • まとめて実行したい
  • 早く届けたい
• 速報値と確定値に分ける
  • 速報値は即時実行
  • 確定値は長い delay で debounce
• delay を徐々に調整
  • UUID の代わりに、前回のリクエストの時間を保存
  • 実装よりコメントが大きくなった

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

• AI のコード生成の問題
  • 妥当性、プロジェクト固有の問題
• Vibe coding : AI で勢いよく開発
• バイブス静的開発
  • 人間が解釈できるものに留める
  • 自分たちのコードベースだけを正規表現で
• 議員性は許容
• use だけではなく、様々な依存
  • 文字列を生成していることもある
• ツールを AI に作らせる
  • 依存関係も出力してもらう
• 20 PE で 4 万行の削除
• use 済テストの品質改善
  • 正規表現→ PPI →正規表現へ
• Q). PPR は？→遅い
• 1. どんなタイミングで？
  2. 1. 消す暇がないから AI で、というのがきっかけ
  3. AI が余計なファイルを見ない、という利点もある
• 1. AI が誤った時の対処法
  2. 1. 反省させて、プロンプトを作ってもらうとよい

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

• Attention is All You Need
• GPT, GPT-2, GPT-3
  • すごく制度の良い予測変換器
• Instruct GPT (2022)
  • ChatGPT
• Evaluating Large Language Models Trained on Code (2021)
  • docstring によってコードを書かせる
  • docstring や処理が複雑だと精度が落ちる
  • LLM が内部に持つ知識にのみ依存する 「圧縮された検索知識」
• 一発勝負で生成するのはうまくいかない
  • 人間はそうしていない
  • 必要なファイルを読めない（コンテキストの中間にあるものはうまく使えない）
  • RAG も一発勝負（同じ課題）
  • HotpotQA - マルチホップ（検索が複数必要なタスク）
• web GPT
  • LLM がツールを捜査するコマンドを発行
• ReAct : Though, Action, Observation
  • Action の前に Though セクションがあるのがミソ
  • Few-Shot いくつか例を見せる
• Reflexion, InterCode (2023)
  • エラーをフィードバックする
• AI ベンチマーク
  • AI に難しそうな課題を設定し、解決する
  • HumanEval, APPS (2021)
  • SWE-Bench (2023)
    • github よりテストコードのある issue/PR を抽出したもの
    • Claude 2 でも 2% しか解けなかった
  • 2024 SWE-Agent
    • 今っぽいエージェント
  • 現在の SWE Bench の解決率は 70% ほど
    • コード生成がお金になることが判明
    • AI も開発に参加
• ライブコーディング

企画 LT

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

• + がないと is が解釈できない問題 → 5.42
• 1; は要らない
• AI は古い記法を使う
• Perl TODAY という本(無料)を書いた
• Hono CLI アプローチ
• AI 向けの perldoc を開発中

Pythonを"理解"しているコーディングエージェントが欲しい！！ / ftnext さん

• Calude は速くて安い。使わざるを得ない
• Python のことわかってないよね
• f-string と % の使い分けができない
• Ruff を使った指摘。フックを設定
• デモ
• サブエージェントの出番？

基盤モデルのアーキテクチャを改造してみよう - 時系列基盤モデルのマルチモーダル拡張事例の紹介 / himuhimu467 さん

• 生徒の離脱予測
• 膨大な時系列を学んだモデル
• 新規のドメインでもほどほどの予測
• 離脱予測＝離脱を防止したい
• 出席傾向が落ちると、回復しない
• 出席傾向が落ちるタイミングを知りたい→時系列モデルだけでは無理
• 振り返りのテキストデータも入力。マルチモーダル
• Fusion Module でマルチモーダルがうまくいくか決まる→ここをチューニングしていく

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

• AI で広告事業を考える
• CS の人力回答を AI で
  • プロンプトの自動化
  • ドメイン知識を持っている人が輝く
• 「本当にこれで大丈夫なのか」
• Bet AI
• Perl

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

• AI は一人で使うツールになっている
• kintone × AI : チームで活用する AI
• AI に質問するだけで必要な情報に
• アプリ作成 AI とレビュー AI

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

• POSレジが高機能
• レガシーシステム
  • 日次、ドキュメントしかない
• お客様によりよいサービスを
  • 定常業務を AI でなくし、お客様に還元
• 店長 AI 、エリアマネージャー AI 、ブロックマネージャー AI
  • 部屋のアサイン、料金作成、バイトサポート

クロージング

• わすれもの
• オープニング　再放送
• ベスト企画 LT 賞
  • ftnext さん　「Claude の応援ありがとうございました」
• 記念写真（今日しか来れないスタッフがいる）

BROMPTON Front Light 500LM が落下した

国道１号の三田付近を気持ちよく走行中に、突然ガチャンと言う音がした。何も落ちるようなものを装着していなかったので不思議だったのだが、一応停車して音がした地点に戻ってみると、フロントライトが落ちている。たまたま早朝で車が居なかったから良かったものの、後続車が居たら参事であった。

このライトは CHPT3v4 と同時に買ったライトで、BROMPTON が販売はしているが、実体は CATEYE の AMPP500 である。

回収したフロントライトを見てみると、ライトにブラケットスペーサーを装着するための爪とネジ受けの両方が折れてしまっている。御覧の通り、ブラケットスペーサーのほうは無傷である。こんな壊れ方がありうるのか・・・？？

破損した AMPP500

普段から川沿いの道を走るので振動が多い環境とは言えるかもしれないが、それにしてもこの壊れ方は信じがたい。夜間走行中にこんな折れ方をされると、本当にお手上げである。何もできる対策がない。フロントライトのバックアッププランも、きちんと考えた方が良いのかもしれない。

ふくしま復興ライド120

今年はレインボーライドよりもしっかり走れるイベントに出たいなあと思って検索したところ、ツール・ド・ふくしまのサイクリング部門として 120Km のライドがあり、ミニベロでも参加できそうなので申し込んだ。

福島には去年行った が、自転車で走るのに大変良い場所だったので、これだと即決。ホテルは 前回と同じ いわき駅の B4T にしたのだが、今年はキャビンではなくシングルにした。キャビンの安さは魅力的だったが、去年、ノマドスペースでひどい目にあったり、空調が調整できなかったりで大変だった。シングルは高いだけあって、非常に快適に過ごすことができた。キャビンと同様にひどく狭いが、配置は考えられていて特に過ごしにくさはなかった。

ふくしま復興ライド120のコースは獲得標高が 2,000Km 近くあったが、特に問題なく走り切ることができた。ただし、周りはロードバイクばかりで、どんどん置いて行かれる（笑）。制限時間内にはゴールできたので、良しとしよう。ゴールはもうほとんど人が居なくて、出店も片付け始めていて寂しい雰囲気だった。

youtu.be

ゴール後は自走で帰ろうと決めていたのだが、コースは結構迷った。国道 6 号は交通量が多いので避けたかったのだが、じゃあどうするか。 ride with GPS のヒートマップで人が通ってそうな部分を選ぶのだが、帰りが夜になるとあまり人気がないところは選びたくない。結局、日が暮れる前には帰れたのだが、引いたコースは街灯がないところばかりだったので、夜だと危なかったかもしれない。

やっぱり福島は良い。また走りに行きたい。

Windows に gemini-cli をインストール

Releases · coreybutler/nvm-windows · GitHub の nvm-setup.exe を実行する。 C ドライブ直下に C:\nvm4w\nodejs などを作りたくなかったら、 D:\local\nvm D:\local\nodejs など適当にアレンジする。 D:\local はあらかじめ作っておくこと。

nvm ls available nvm install 22.19.0 nvm use 22.19.0 などする。

npm install -g @google/gemini-cli でインストール。

gemini と打ってしばらく（ 1 ～ 2 分？）待つと初期設定が始まるので、よしなに。

第21回Mt.富士ヒルクライム

サークルの方に声をかけられた縁で、富士ヒルに参加した。

fujihc.jp

Youtube ではよく見る憧れのイベントに、まさか自分が参加するとは思っていなかった。動画も撮って公開はしたが、のんびり一人旅でカメラを回すのとは違い十分な準備ができず、出来はひどいものだ。

会場にはサークルの方の車で連れて行ってもらった。30年来のペーパードライバーで何もお手伝いできず、参加チケットの獲得から宿の手配まで何から何までお世話になってしまった。同行させて下さった方々には、いくら感謝をしてもしきれない。

肝心のレースだが、自分は初めからタイムを競うつもりはなかったし、そうなると獲得標高も平均斜度も全く心配がないレベルのものだったので、肩肘張らずに参加することができた。走ってみると、当たり前ではあるが、自分より速い人も遅い人もいて、いろんなレベル帯の人が参加しているなと感じられた。年間 10,000 Km はゆうに走っているのでブロンプトンでも平均以上の速さで走れるのかなと思っていたのだが、終わってみると 7,793 人中 5,114 位で、下位 35% という結果だった。やはり、きちんと競技として練習している方々と比べるのはあまりにも失礼だ。

2025 年はこの富士ヒルを筆頭に、毎週コンスタントに動画を公開している。

とは言え、このペースで動画を公開するのはかなり大変だ。コースのレパートリーがまったく足りていない。また、温かい視聴者の方が時折コメントを寄せてくださるとはいえ、一人でモチベーションを維持していくのも難しい。今後は富士ヒルのようなイベントへの参加を増やしていき、様々な場所で走って経験を積んでいくとともに、人脈も増やせるようにしたい。

若い頃、 OSS コミュニティでの人脈が広がったことで、出版をはじめ様々な経験をさせてもらった。仲間を作ることが人生を豊かにする上で本当に大切なのは、よくわかっている。ただ、根っからのコミュ障である上にコロナ禍を経験したせいで、ここ数年では他人との関係は断絶状態にある。人とのつながりを取り戻すには、多少自分の意思に反してでも、きちんと意識をしてコミュニティに身を投じていくが必要がある。

土浦小旅行

先月の話になるが、 3/21 の春分の日に一泊して土浦へ行ってきた。宿泊するのを旅行と言うのであれば、これは小旅行と言っていいだろう。

初日は霞ヶ浦を一周した。カスイチはブロンプトンを買って半年の頃に行っており、その年の 年末のまとめブログ に写真だけ掲載されている。ロングコースは初めてだったのだが、前半で調子に乗ってペースを上げ過ぎたために、後半、かなりひどい目にあった。特に腰の痛みがひどくて大変だった。

youtu.be

二日目は筑波山でヒルクライムをしてきた。距離が少ないのもあったが、初日よりはかなり楽に回ることができた。やはり山は良い。

youtu.be

一方で、ダウンヒルでは冷や冷やするシーンが何度もあった。安全に下るのは難しい。