アクションカメラは上下を勝手に判定するので、例えば前屈した姿勢でカメラのスイッチを入れたりすると、簡単に上下が逆さまの動画ができてしまう。
これを直す方法に難儀していたのだが、 ffmpeg でメタデータを弄るのが早いことがわかった。手元にインストールしなくても、 https://ffmpeg-online.vercel.app/ で -c copy -metadata:s:v:0 rotate=180 とオプションを付けて実行すればよい。これは便利。
cargo update --verbose
いつ頃からかわからないけど、 cargo update が便利になっている。新しいバージョンが存在するのをきちんと教えてくれる。
今までは新しいバージョンの存在を知るために cargo outdated や cargo upgrade を使っていたが、この出力だけで不要になってしまった。
update の対象ではない場合は普段は表示してくれない。
> cargo update
Updating crates.io index
Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 5 unchanged dependencies behind latest
が、書かれている通り cargo update --verbose を実行するだけで確認することができる。
YAPC::Fukuoka 2025 を終えて
先ほど、夜の便で無事に羽田に帰ってきた。まずは、素晴らしいカンファレンスを作ってくれたスタッフの方にお礼を言いたい。
最近持ち歩く PC が GPD win min なので、メモは取らなくていいかなあと思っていたのだけど、やっぱりメモをとったほうが頭に入ってくるので、結局全編メモを取りながら聞いていた。
聞いた中で面白かったのは、まず macopy さんのトーク で、コーディングエージェントがどう動いているのか短時間でよくまとまっていて素晴らしかった。 yoshiori さんのトーク も業務で技術的な課題を解決していく面白さを追体験出来て、とても良かった。最後に すぎゃーんさんのトーク は取り上げた課題の難易度も解法の解説も絶妙に興味深いものばかりで、プログラミングってやっぱり楽しいものだよなあと再確認できた。ビジュアライズも効果的で素晴らしい。最大で４トラック同時に開催されていたので、ベストトーク賞候補のトークやゲストのトークを含めて、聞けていないトラックの方が圧倒的に多かったことは強調しておく。
今回は珍しく、自分のトークもあった。予想通り聴講者は少なかったが、終了時に「面白かった」と声をかけてもらえたので満足である。実際、このプロジェクトは１エンジニアとして取り組んでとても面白かった 1 ので、そのエッセンスを詰め込んだトークにしたつもりである。
今回の福岡は、旅としても大変楽しかった。今までの YAPC では YAPC に忙しくて（それはそう）あまり観光できなかったのだが、今回は全日程に余裕があったように思える。最近家庭の事情で朝型の生活になっていたのも良かったのかもしれない。十分に睡眠を取った上で６時には起きて余裕を持って身支度をした上で、開場前にゆったりとモーニングを楽しむ時間まであった。
YAPC の翌日は予定だけ確保して何も旅程を決めていなかったのだが、 YAPC 終了後にふと google map を見ると、福岡の北側に面白そうな地形があることに気が付いた。海の中道と志賀島である。博多港が駅から徒歩で 45 分程度のところにあり、船で志賀島に入れることもわかった。そして、渡船場のすぐ近くにはレンタサイクルがある。素晴らしい。
博多港から乗船し、
軽くヒルクライムをして潮見公園からの海の中道の眺めを満喫し、
島を一周後 2 たまたまやっていた「潮騒ヨイ祭り」で焼きサバを頂き、
最後は海の中道からの絶景を拝みながら帰ってきた。
今日は 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 でリニューアル
- 含まれるもの、含まれないもの、中心、は何か
- 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
- CGI 1990 年
- リクエストを受けた時だけリソースを利用（今時）
- 書籍がたくさん出ていた
- mod_perl
- 2009 年 PSGI/Plack
- PSGI を満たせば入れ替え可能
- 秩序を保って、多様性
- 変化を促すのに、ルールを入れる、のが面白い
- 2005 年
- 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
- 「課題」をコミュニティで話す
- コンテキストが異なる人で話すと、抽象化される
- 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
- Unicode
- 国旗は code point を二つ使っている
- Perl には
\Xがあり、１表示文字にマッチする - JS にはまだない
Intl.Segmenterを使う
- Perl には
- JS はスクリプト言語
- もともと Perl のカンファレンスだったはず
- 悪いことではなく、 Perl コミュニティは正しいことをしてきた
- LT も文字列の扱いも我々が正しかった
- Q). なぜ正しく UTF-8 を選択できたのか？
- A). 後出しじゃんけんで勝てた
- Q). Perl は JS になれたのか？
- A). ブラウザで動くのはなかなか
転ばぬ先のXS入門 / polamjag さん
List::Util::minXS で書かれている- 「インストールがコケる」が主要の問題
Makefile.PLExtUtils::MakeMakerBuild.PLModule::BuildModule::Build::TinyMinillaDist::ZillaApp::cpm- fetch configure install
- configure で
Makefile.PL作成、 install で実行
- XS
- インターフェース記述ファイルフォーマット
- XS はプログラミング言語
xsubppで C へトランスパイルExtUtils::ParseXS
- Perl ランタイムは C で書かれている
- 共有ライブラリ、静的ライブラリとリンク
- 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::XSDBD::mysql`Inline::Rubyencode_jsonをgrepすると二つ出てくるMODULE = Cpanel::JSON::XS PACKAGE = Cpanel::JSON::XS- これより前は C プログラム（ POD の未除去）
- それより下が XS でエントリポイント
- XSUB: Perl 上での関数定義の単位
- ALIAS 別名
- PPCODE 以下が実装
PUTBACK/SPAGAIN/XPUSHs
SVPBIBRV
AVHV- スタックの操作が必要となる
- 引数をスタックから取得
- 戻り値をスタックに積む
- perlinterp, perlgts, perlsub, perlffunc, perlcall などにスタックの話が出てくる
PUTBACK/SPAGAIN- スタックを Perl ランタイムに書き込む
pTHX_マルチスレッド用のマクロsv_2mortalNEWSV
aTHx_受け取ったものを渡すときに使うマクロ- Perl を壊さないような変数操作などは xsubpp や C マクロに隠蔽されている
*.cファイルを見るとxsubppの実行結果も見られるdbd_st_fetch`dbd_st_executeの二つをDBD側で用意するdTTHXDBI のしきたりの初期化処理mysql_st_internal_execute41mysqll_で始まるものはほぼ mysql の関数
- Low-Level Inline::Ruby
- 氷山の一角
slu_sv_valueamagic_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 で解放の共有
- e.g. 同じ文字の大文字小文字が連続しているときに取り除く
- スタックを用意して1文字ずつ読み、マッチしたら pop 、それ以外なら push
s/(.)(?!\1)(?i)\1//
- e.g. 二次元座標の問題
- e.g. 点列が動いて、突然クリスマスツリーになる問題
- 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ですよね
packunpack- バイナリパースや 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 スクリプト。デバグログが入力
xSwipe448 stars- Synaptics ドライバでも動く、 perl は入っている
- OS アップデートでデバグログが消えた
- タッチパッド、ポインティングスティックは修飾キー
- 道具がより手がなじむようにするのは最高
ghqの秘密 / songmu さん
- Go Hot 九州
- もともと go get の挙動を模した
- いろんなリポジトリをとるテストがある
伝統的日本企業のソフトウェアエンジニアになって無双しよう！ / kurain さん
- 1960 年、797 名
- toC サービスをやっている
- 内政組織がない
- 大量アクセス
- リリースできない
- 協力会社多すぎ問題
- 速く安定した開発
- Charaforio 、アプリデータ分析の内製化、新規開発、認知拡大
- 伝統的日本企業
- 物販とライセンス
- セキュリティは大事
- 企業理念「みんななかよく」
- 相談すればみんなやさしいので問題は解決する
- 今後はノベルティにも期待・・・！
ベストトーク LT / カヤックさん
- 鎌倉にサウナ、OKINAWA うんこミュージアム
- 何やっているかよくわからない会社
- 面白法人は「みんな面白いんでしょ？」
- オモハラ
- 自分たちが面白がる、面白い人と言われる、周囲の人を面白く
- ストレートに面白い、逆に面白い、一周回って面白い
- 演習力で振り落とされているから
- 逆に求心力が働いている人が残る
- 「なるほど」と思った人は騙されやすいタイプ
- ストレートに、誰かの人生を面白い
- 真ん中を目指すのは難しい
Stay Hacker ～九州で生まれ、Perlに出会い、コミュニティで育つ～ / P山さん
- 旅先でタクシー捕まらない問題
- GO株式会社
- KKD 勘、経験、度胸
- 2013 年 電力会社の ISP のサーバエンジニア
- Postfix
- 委託先が本物の自動化 「.pl」
- プログラミングへの感銘
- ラクダ本を頭から読む
- 仕事では使えず、伸び悩む
- モダン Perl 入門
- 「デザインパターン」
- 習作が必要
- 定期異動→保守
- オンライン面接「ある数字が素数かを判断」
- 奇数を判定するプログラムを書いてしまった！
- 「計算量」の話がわからず
- 雰囲気で触ったことのない
Redis発言
- 雰囲気で触ったことのない
- 希望年収を低くすることで入れてもらえた
- 「胡散臭くて最後まで迷った」
- 420 万くらいにしてくれると思って 300 万と書いたら 300 万になった
- エンジニア評価制度
- カンファレンスやコミュニティの活動が推奨された
- builderscon Tokyo でトークをさせてもらえた
- 集客できなくて悔しい
- WEB+DB PRESS & Software Design
- テクニカルライティングについて学んだ
- YAPC
- 「九」州 良いコミュニティ
- PHPカンファレンス福岡
- 福岡 Rubyist 会議 / fukuoka.rb
- Fukuoka.go
- 空港が近い→全国様々なカンファレンス
- アウトプットを評価してくる場は、幸運
- 「熱」
- 良くしたい
- 言語、役職、職種の壁がない
- 「怠惰」「短気」「放漫」
- 技術力で解決する人
- 技術力が高いとコミュニケーソン能力も高い
- Hacker の仕事はプログラムを書くことではなく課題を解決すること
- AI に奪われるものではない
- アイデアが浮かんだ後、コードを書き始めると写経になる
- AI によって解消される
- AI によって変わらないと思うこと
- やるやつはやるしやらないやつはやらない
- Hacker であり続けるために
- いい課題、研鑽を続ける、事例から学ぶ
- Hack し続ける
- 怠惰、短気、傲慢
- 「手段」は変わる。「目的」は変わらない
- これをどう使うか、考え続けるのが Hacker
クロージング
今日は 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
- 「教師」を超えることはない→機会が教師なら人類を超える
- ユニットテストが欠けない＝学習ができない＝苦手
- AI の弱点、コンテキスト処理能力、知らないことが多い
- 長いコンテキストが苦手 / せいぜい 30K トークンくらい / プロジェクト全体を一度に見られない
- コンテキストの汚れに弱い→同じ失敗が続く
- コンテキストエンジニアリングが大事→きれいにコンパクトに
- 知らないこと→実際にどう動くか、開発過程、ファイル以上の大きな単位
- プログラミング
- 機能、性能、使いやすさ、安全性
- AI が得意なのは機能だけ
- 実行のための機能→関数型、構成のための機能→OOP
- プログラムの最適化
- 処理の重複の排除
- キャッシュ
- 多胎の活用
- 単一責務→変更の発生源をまとめる。クラス利用者の責務
- 非機能要件は人間が頑張りましょう！
「データ無い！腹立つ！推測する！」から「データ無い！腹立つ！データを作る」へ / moznion さん
- サービスと「名前」
- 機械は「セブンイレブン」を理解しない
- 「セブン」「ブンイレ」でもわかる
- LLM ならわかるのでは
- 人間が見てもわからないものは機械もわからない
- 「マツヤ」「コスモス」
- データはなくても困らない→困るのは必要になってから
- 可能性が狭まる
- データがない、何もわからない、どういうデータが必要かわからない、の悪循環
- データがあるだけではダメで、使えるように整理してないと駄目
- 「AIでよくね？」
- 決定論的に計算できるものを LLM に計算すべきではない
- 「大本おのデのデータ」は今後価値を持つ
- 「何に使うのか」からデータを考える
- データを作るための「生データ」
- あるのか、どこにあるのか、形式や構造
- まずはここから
- システムがデータを生む、 WEB を使う、買う
- ドメイン知識がないとデータを作るのは難しい
- 「辞書」を作る
- 名称情報から「ラベル」をつける
- DuckDB が高機能で性能が良い、組み込み
- Gabage In, garbage Out →前処理できれいにする
- 人間に適したワークフロー→スプレッドシート
- データの後処理→テスト、ベンチマーカー
- SQLite のダンプは他の DB へ読み込ませやすい
- データ作りにもソフトウェア開発のベストプラクティスを使える
- LLM に Assist Tool を生成させる
- 人力を諦めない
- 孤独
- 品質が高いデータができる
- 超人以外は無理
- ポシャりやすい
- 「なんの役に立つのか」
- データづくりとシステム作りのフェーズはわけない
- データをシステムに投入しながら
- 100% のデータというものはない
- 小さな労力で、高い効果
- 継続的に育てる
- データセットは作って終わりではない
- データがどう使われいるか
- 目的外利用→使いまわせるのは良いデータ
- チームを作る
- ガイドラインを作る
- データを買ってビジネスを進めながら、自分たちで作ることもできる
- 前処理の陳腐化はどうする？
- ベンチマークの悪化から気がつけるとよい
なぜThrottleではなくDebounceだったのか？ 700並列リクエストと戦うサーバーサイド実装のすべて / yoshiori さん
- テスト結果の収集
- AI でまとめる。原因、再現性、などなど
- テストの分散→平均的に同じ時間で終わるように
- 700 並列でテストを実行するお客さん
- ジョブキューでは意味がない
- 処理を間引く Throttle や Debounce
- Debounce
- データが集まるまで、待つ仕組み
- タイマーをデータが来るたびにリセットする
- 没になった案
- Rate Limit 、や缶バッチ、スケールアップ・アウト、ジョブキュー
- クローズ処理はまとめられる
- Throttle より Debounce の方がより待機してよりまとめられる
- クライアント技術→直列
- クライアントもサーバーサイドも複数台ある
- Redis を使った実装
- UUID を書き込み、変わっていなければ終わったと判断
- Redis をロック代わりにした
- レースコンディション
- Debounce は delay 時間の調整がキモ
- 長過ぎると遅延
- 短すぎるとまとめられない
- 二つの要件
- まとめて実行したい
- 早く届けたい
- 速報値と確定値に分ける
- 速報値は即時実行
- 確定値は長い delay で debounce
- delay を徐々に調整
- UUID の代わりに、前回のリクエストの時間を保存
- 実装よりコメントが大きくなった
「バイブス静的解析」でレガシーコードを分析・改善しよう / hitode909 さん
- AI のコード生成の問題
- 妥当性、プロジェクト固有の問題
- Vibe coding : AI で勢いよく開発
- バイブス静的開発
- 人間が解釈できるものに留める
- 自分たちのコードベースだけを正規表現で
- 議員性は許容
useだけではなく、様々な依存- 文字列を生成していることもある
- ツールを AI に作らせる
- 依存関係も出力してもらう
- 20 PE で 4 万行の削除
use済テストの品質改善- Q). PPR は？→遅い
- どんなタイミングで？
- 消す暇がないから AI で、というのがきっかけ
- AI が余計なファイルを見ない、という利点もある
- AI が誤った時の対処法
- 反省させて、プロンプトを作ってもらうとよい
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 ベンチマーク
- ライブコーディング
企画 LT
プロジェクトの空気を読んで開発してくれるPerlのAIツールがほしい / kfly8 さん
+がないとisが解釈できない問題 → 5.421;は要らない- AI は古い記法を使う
- Perl TODAY という本(無料)を書いた
- Hono CLI アプローチ
- AI 向けの perldoc を開発中
Pythonを"理解"しているコーディングエージェントが欲しい！！ / ftnext さん
- Calude は速くて安い。使わざるを得ない
- Python のことわかってないよね
- f-string と % の使い分けができない
- Ruff を使った指摘。フックを設定
- デモ
- サブエージェントの出番？
基盤モデルのアーキテクチャを改造してみよう - 時系列基盤モデルのマルチモーダル拡張事例の紹介 / himuhimu467 さん
- 生徒の離脱予測
- 膨大な時系列を学んだモデル
- 新規のドメインでもほどほどの予測
- 離脱予測＝離脱を防止したい
- 出席傾向が落ちると、回復しない
- 出席傾向が落ちるタイミングを知りたい→時系列モデルだけでは無理
- 振り返りのテキストデータも入力。マルチモーダル
- Fusion Module でマルチモーダルがうまくいくか決まる→ここをチューニングしていく
認知ではなく良い体験設計を追求する、そのための広告プロダクト開発組織における『Bet AI』とは / honyanyas さん
プロダクトにも、チームにも。サイボウズが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 である。
回収したフロントライトを見てみると、ライトにブラケットスペーサーを装着するための爪とネジ受けの両方が折れてしまっている。御覧の通り、ブラケットスペーサーのほうは無傷である。こんな壊れ方がありうるのか・・・？？
普段から川沿いの道を走るので振動が多い環境とは言えるかもしれないが、それにしてもこの壊れ方は信じがたい。夜間走行中にこんな折れ方をされると、本当にお手上げである。何もできる対策がない。フロントライトのバックアッププランも、きちんと考えた方が良いのかもしれない。
ふくしま復興ライド120
今年はレインボーライドよりもしっかり走れるイベントに出たいなあと思って検索したところ、ツール・ド・ふくしまのサイクリング部門として 120Km のライドがあり、ミニベロでも参加できそうなので申し込んだ。
福島には去年行った が、自転車で走るのに大変良い場所だったので、これだと即決。ホテルは 前回と同じ いわき駅の B4T にしたのだが、今年はキャビンではなくシングルにした。キャビンの安さは魅力的だったが、去年、ノマドスペースでひどい目にあったり、空調が調整できなかったりで大変だった。シングルは高いだけあって、非常に快適に過ごすことができた。キャビンと同様にひどく狭いが、配置は考えられていて特に過ごしにくさはなかった。
ふくしま復興ライド120のコースは獲得標高が 2,000Km 近くあったが、特に問題なく走り切ることができた。ただし、周りはロードバイクばかりで、どんどん置いて行かれる（笑）。制限時間内にはゴールできたので、良しとしよう。ゴールはもうほとんど人が居なくて、出店も片付け始めていて寂しい雰囲気だった。
ゴール後は自走で帰ろうと決めていたのだが、コースは結構迷った。国道 6 号は交通量が多いので避けたかったのだが、じゃあどうするか。 ride with GPS のヒートマップで人が通ってそうな部分を選ぶのだが、帰りが夜になるとあまり人気がないところは選びたくない。結局、日が暮れる前には帰れたのだが、引いたコースは街灯がないところばかりだったので、夜だと危なかったかもしれない。
やっぱり福島は良い。また走りに行きたい。
