https://yapcjapan.org 
Yet Another Perl Conference
11 月 13、14 日に開催された YAPC::Fukuoka 2025 へ参加しました。 YAPC は “Yet Another Perl Conference” の略で、Perl コミュニティによるカンファレンスイベントです。 Perl を軸としつつ、そこから派生する様々な技術に関するセッションが行われました。
福岡工業大学の門の前にある YAPC の案内板
自分と Perl、YAPC
print chr(0x1F9F6), "\n"
自分は現在、株式会社はてなでエンジニアアルバイトをしています。 はてなでは複数のプロダクトのバックエンドに Perl を使用しており、自分も業務の開発で Perl を使用することがあります。
Perl を書きはじめたこともあり、以前から知っていた YAPC に参加する良いチャンスだと思い、参加を決めました。 福岡開催でかつ宿泊費の高騰などもあり、なかなかハードルが高かったのですが、Japan Perl Association による学生向けの旅費支援制度によって気軽に参加できました。 Japan Perl Association、並びにスポンサーの企業には深く感謝しています。
Day 1
一日目はセッションを中心に聴講しました。
なぜ強調表示できず ** が表示されるのか — Perlで始まった Markdown の歴史と日本語文書における課題
なぜ強調表示できず ** が表示されるのか — Perlで始まったMarkdownの歴史と日本語文書における課題
Markdown記法で記述された文書は、GitHubやQiita、そしてこのforteeなど我々がよく利用するサービスで数多く見つけることができます。さらに最近では、AIからのテキスト出力もMarkdown形式であることが多く、馴染み深い方も多いでしょう。 しかしAIからの出力の中には、たまに強調表示に失敗し、 「おや？」と思うことってありませんか？ 我々は単にアスタリスクで囲われた内部を強調して欲しいだけなのに、どうしてそんな一見シンプルな処理に失敗することがあるのでしょうか。 この身近な問い（Q）を解くためには、Markdownの原点に遡らなければなりません。2004年に公開された最初のMarkdownは、一つのPerlスクリプトでした。本トークは、強調表示の失敗という身近な問題をきっかけとして、この"旧"Markdown（Markdown.pl）まで遡ります。 まず、なぜ単純に見える強調表示に失敗しうるのか、Markdown記法の標準化プロジェクトであるCommonMarkの強調ルールとともに解説します。次に、原点であるMarkdown.pl、Markdownの普及と相互運用性という課題、CommonMarkの始まりと強調表示の仕様策定経緯に触れ、この問題に至るまでの歴史を紐解きます。さらに、現状のコミュニティでの議論と、正しく強調表示するために我々が採りうる手段についても共有します。 加えて、日本語の改行（soft line break）問題やルビ表記といった、日本語固有の他の課題にも焦点を当てる予定です。 このトークを通じて、普段何気なく使っているMarkdownの現在地を、その歴史から日本語という観点で再確認し、より快適な日本語ドキュメンテーションへの道筋を皆さんと共有します。
https://fortee.jp
最初は hkws さんのセッションを聴講しました。
チャット形式の AI サービスでよく見かける Markdown の強調表示がうまく動作しない問題を起点に、Markdown の歴史と日本語文書における課題について解説されていました。
自分も同様の強調が動作しない問題に遭遇したことがありました。 その際には Markdown パーサーのバグかと思って雑に流してしまっていたのですが、それは実際には仕様に起因する問題でした。 CommonMark には括弧などの約物があり、それと分かち書きをしない CJK の扱いの難しさが関係しているとのことでした。
Markdown は自分も日常的に使用しており、このブログも Markdown で書かれています。 複雑な歴史と仕様があることはなんとなく知っていましたが、改めて整理して聞くことで理解が深まりました。 まだまだ知らない仕様や挙動があると思うので、この機会に調べてみたいです。
大学における人工知能関連の教育について
大学における人工知能関連の教育について
福岡工業大学で「人工知能基礎」などの授業を担当してます． 大学でどんな感じで人工知能関連の教育をしているか，まずは概要を話しますので，後は聞きたいことを聞いてください． 答えられる範囲でお話ししますｗ
https://fortee.jp
次はゲストスピーカーである福岡工業大学の 山澤 一誠 教授のセッションを聴講しました。
このセッションでは福岡工業大学における「人工知能プログラミング」の講義での AI 活用と学生の変化について紹介されていました。 この授業では、パックマン、迷路、じゃんけんなどのゲームを解く、より賢い AI を作ることが課題となります。 近年の LLM やコーディングエージェントの発展により、学生の成果物に大きく変化があったということでした。
自分も大学生として課題に AI を活用しているため、他人事ではなく自分ごととして聴いていました。 実際に AI を使用したことで新しい領域を学びやすくなった反面、AI に頼りすぎて自分の理解が浅くなってしまうこともあると実感しています。
発表内で重要とされていたのは、 AI が書いたコードを自分で理解しレビューできる必要がある という点でした。 この点には同意しつつも、それを学生に求めることの難しさも痛感します。
また、発表内で紹介されていた、ここ数年での学生の解答の変化は面白かったです。 AI を使った場合に出力されがちな「賢い書き方」を単に grep してその件数を比較しただけで、あんなにも顕著な差が出るのは驚きでした。
k1LoW/deck を急激に (100 倍以上) 高速化する方法
k1LoW/deckを急激に(100倍以上)高速化する方法
deckはk1LoWさんが開発された、MarkdownからGoogleスライドを継続的に作成するための非常に優れたOSSであり、Goで書かれています。 筆者は、7月からこのツールを使い始めると同時に、その後の数ヶ月で多くの改善提案及びpull requestを行いました。コード行数にすると1万行以上に及びます。最終的にはコア開発者にも加えてもらいました。 deckを使いやすくするための数多くの変更をおこないましたが、中でも特筆すべきはそのパフォーマンス向上でしょう。10分以上かかっていたスライド生成が10秒以内で完了するようになったケースもあり、実に100倍以上の高速化を達成しています。 これらは、良く言われる「計測」で達成できた部分もありますが、実際にはTidy First的に仕様やコードの整理整頓をする中で自然と速くなったもの、その過程で高速化のアイデアが湧いて実現できた物も少なくありません。その過程で作者のk1LoWさんとも議論を重ねることもありました。それらの段階的な改善が、結果的に劇的なパフォーマンス向上に繋がったのです。 本トークでは、実際のdeckの高速化の旅路を具体的事例にとり、OSSやソフトウェア開発におけるパフォーマンスチューニングの秘訣についてお話します。
https://fortee.jp
次は songmu さんのセッションを聴講しました。
このセッションでは、k1LoW/deck のパフォーマンス改善をするにあたった過程が紹介されていました。 OSS プロダクトへの関わり方から、 k1LoW/deck とのどのように関わってきたか、そこからパフォーマンスチューニングの心得に繋がります。
k1LoW/deck は Markdown から Google スライドのスライドを生成するツールです。 一般的な Markdown からスライドを作成するツールとは異なり、Google Slide API を使用して Google スライド上に作成するアプローチをとっています。 このアプローチを取ることにより、Google スライド上で変更したデザインを保持したままスライドを更新できるという利点があります。
deck is a tool for creating deck using Markdown and Google Slides.
deck でのパフォーマンス改善は、 Google Slide API のバッチリクエストを最大限活用することで実現されています。 バッチリクエスト内でのリクエスト数に上限がないという富豪ぶりには思わず笑ってしまいました。
Slide API の話は deck 固有の事情ですが、後半のパフォーマンスチューニングの心得は汎用的でした。 今後の開発でも活かしていきたいです。
「データ無い！腹立つ！推測する！」から「データ無い！腹立つ！データを作る」へ ― ゼロからデータを作り、チームで育てられるようにするまで
「データ無い！腹立つ！推測する！」から「データ無い！腹立つ！データを作る」へ ― ゼロからデータを作り、チームで育てられるようにするまで
話者が所属する組織ではプリペイドカードを用いた決済機能とそれに付随した家計簿アプリを開発しているのですが、そこでは日々膨大な量の「名前」と格闘しています。カードの決済店舗名、家計簿の支出名、レシートからの店舗名や費目名などなど……これら名前が各々何であるのかを機械が理解できるようにするにはどうすれば良いでしょうか。 例えば「セブンイレブン」という名前を見た時、人間はそれが「コンビニ」の名前であることを一目で理解できますが、未学習の計算機にこれをやらせるのは困難です。ではどうするかというとパッと思いつくのは計算機に推論させるという方法があります。昨今の大規模言語モデルであれば例に挙げたようなタスクはこなせる可能性がある一方、現状ではコストが高くなりがちという問題もあります。そもそも人間に判断が付かないものは機械にとっても難しいものです。仮に「たんぽぽ」という店舗名を見た時、これがどんな種類の店であるかを自信を持って回答できるでしょうか？ 人が見ても判然としないものを機械に推論させても有意義なものが出てくるかというと難しいものがあります。 我々はこうした課題を解決するためにマスターデータ（辞書）を地道に作っています。本トークでは自然言語処理の理論・手法を要するものを、プロダクト作りの現場においてどうシステムや良い体験に適用していくかという実践的な話題を取り上げます。主に取り上げる予定の話題を紙幅の都合上以下に箇条書きにします: - LLM時代ではその知識の源泉となるデータは益々重要 - 推論せずに結果が得られるならば推論する必要は無い - 何の解決を目的としてデータを作るか - データが無いところからどう作りはじめると良いのか（一定の根性の話） - どのように作ったデータを育てるか - 作ったデータを有効に使う方法 - データを作り、育て、有効活用できるチームをどう構築するか
https://fortee.jp
次は moznion さんのセッションを聴講しました。
このセッションでは、プロダクト開発におけるデータの重要性とデータを作る際の向き合い方について紹介されていました。
特に印象に残ったのは、「データは無くても困らない」 と 「データはソフトウェアの一部である」 という言葉です。
「データは無くても困らない」こう聞くとデータを集める必要がないように聞こえます。 しかし、この言葉はデータがない場合には困っていることにも気づけない、という意味で使われていました。
この話は自分にも思い当たる節があります。大学の講義の一環で開発しているプロダクトで、必要なデータを自分達で集めた経験があるからです。 データがもしなかったら、可能性が狭まり本来の目的を達成できなかったでしょう。
「データはソフトウェアの一部である」という言葉は考えたことがありませんでした。 しかし、データもソフトウェアと同様に自動化やテストができると考えれば、この視点は腑に落ちます。
大規模OSSに一人で立ち向かうには
大規模OSSに一人で立ち向かうには
私は2024年の2月からWebKit（実際にはその中のJavaScript処理系であるJavaScriptCore）への貢献を開始し、1年後の2025年2月にレビュワーという最も強い権限を持つメンバーの一人になりました。 そして、2025年8月にはWebKitへの貢献が評価され、それに関連する職を手にいれることができました。 私はこれまで基本的に一人でWebKitへの貢献を行ってきました。 周りに質問できる人が全くいない中、コードベースへの理解はもちろん、独自の開発文化なども身につけながら、コミュニティからの信頼を得られるように努力してきました。 その中で「大規模なOSSに一人で立ち向かう」ためのアプローチが少しずつ見えてきました。 この発表では、WebKitのような大規模かつ技術的に複雑で歴史の長いOSSプロジェクトに一人で立ち向かい、技術的な理解を身につけながらコミュニティからある程度認められるようになるための方法について、なるべく再現性のあるアプローチについてお話しします。
https://fortee.jp
次は Sosuke Suzuki さんのセッションを聴講しました。
「情熱をエミュレートする」この言葉がとても心に残っています。 必ずしも情熱を維持する必要はなく、情熱がある人だったらどうするかを考えることが重要という意味です。
また、後半の大規模 OSS へ貢献するための TIPS は大規模な OSS に複数関わってきた経験に基づいており、説得力がありました。 「寝ること、自然を歩くこと」は人間の基礎にして一番難しいことだと感じます。
自分は大規模な OSS に継続的に貢献したことは今のところありませんが、今後その機会があった場合はこの内容を思い出していきたいです。 また、この内容は OSS に限らず、普段の開発にも応用できる部分があるでしょう。
「バイブス静的解析」でレガシーコードを分析・改善しよう
「バイブス静的解析」でレガシーコードを分析・改善しよう
大規模なプロダクトでは、lintや、use漏れチェック、使ってないファイルの検出といった、静的解析を伴う開発支援ツールが重宝されます。 しかし、存在するすべての記法を扱う必要のある汎用ツールでは、どうしても実行時間が伸びてしまったり、プロジェクト固有のかゆいところに手が届きにくかったり、といった課題がつきものです。 発表者が携わる、開発期間約10年・数十万行規模のリポジトリでは、近年注目されている"vibe coding"の考えを下敷きに、プロジェクト専用の軽量なツールを開発して、開発支援に活用しています。 本発表では、プロジェクト固有の静的解析ツールをAIとともに開発し、レガシーコード改善に活用する「バイブス静的解析」を提唱します。 # 静的解析を用いたツールのこれまで - PPI, PPRを使った汎用ツールのおさらい - 汎用的がゆえに、いかなるソースコードも正しく解釈しなければならない宿命 - ツールの実行時間増加への利用者側の工夫 # バイブス静的解析のアプローチ - プロジェクトに合わせた専用の静的解析ツールを「バイブス」重視、すなわち、勢いで開発する - 完璧を目指さず、コードベース上で必要な表現だけに対応する - AIの力を借りて、誰でも保守でき、壊れても機能開発の片手間に短時間で直せるものを目指す # ゴール - 「バイブス静的解析」の考えを使って、新たなツールを勢い重視で開発できるようになる - お手元のリポジトリから、数秒以内にuse漏れや不要ファイルといったエラーを検出できるようになる
https://fortee.jp
次は hitode909 さんのセッションを聴講しました。 ここに来てほぼ初めて Perl のお話です。
AI によるコード書き換えは信頼できない部分があるため、静的解析するツールを AI で作成するという内容でした。 ただの静的解析ツールではなく 正規表現 で静的解析する プロジェクト固有の ツールを作るのがポイントでした。
正規表現であれば簡単に作成でき、プロジェクト固有にすることで必要最低限の記法で済みます。 様々な記法で書くことができる TMTOWTDI (There’s More Than One Way To Do It) の Perl ならではのアプローチだと感じました。
「偽陰性」は許容するが「偽陽性」は許容しない、という考え方も興味深かったです。 必要なコードを誤って書き換えてしまうことは避けなければならない一方で、完璧を求めずに見逃しても良い、というバランス感覚が重要だと感じました。
発表では Perl コードの例が多く紹介されていましたが、他の言語でも応用できる部分が多いため、今後の開発にも活かしていきたいです。
Perl ブートキャンプ
Perl ブートキャンプ
> いいか、みんな > (ﾟдﾟ ) > (| y |) > > ハッシュリファレンスと package では手続き型プログラミングしかできないが > {} ( ﾟдﾟ) package > ＼／| y |＼／ > > 二つ合わさればOOPとなる > ( ﾟдﾟ) bless > (＼／＼／ --- Perl を初めて触る方を対象とした、1 時間の速習ワークショップです。対象は他の言語に慣れている Web エンジニアを想定しています。 Perl における OOP の歴史や、強力な正規表現、特殊変数の世界など、現代から見る Perl の奇妙さを体験しつつ、現代的な Perl プログラミングまで駆け抜けます。 文法の細部よりも、Perl 独特の仕組みと速習のポイントを凝縮し、短時間で「Perl を読める」「ここに戻ってきたら分かる」という感触を得られる構成です。 はてなサマーインターンシップで使ってきた [はてな教科書](https://developer.hatenastaff.com/archive/category/%E3%81%AF%E3%81%A6%E3%81%AA%E6%95%99%E7%A7%91%E6%9B%B8) を下敷きにしています。
https://fortee.jp
次は Takafumi ONAKA さんによる Perl ブートキャンプを聴講しました。
Perl のコードを読むための取っ掛りとして、Perl の基礎的な文法や概念について解説するセッションです。 このセッションの目標は約 1 時間で「Perl 完全に理解した」になることです。
自分はアルバイトで Perl を書いていたため、一度基礎的な学習はしています。 しかし、ちょうどここ 2 ヶ月ほど私用によりアルバイトを休んでいたため、ちょうど良い復習になりました。
周りの友人は Perl の独特な記法や挙動に困惑していました。 自分が最初に学習したときを思い出して共感もしつつ、困惑した反応はおもしろかったです。
無事ブートキャンプを修了し、 Perl を完全に理解しました。
頑なに再代入しない！
頑なに再代入しない！
コードを読んでいると、この変数はどこで定義され、どこで値が設定されたのか？を確認することがしばしばあります。 再代入が多いとどのタイミングで値が変更されるのか？を確認するコストが発生するので、私はめんどうだと思ってしまいます。 また、再代入がないほうがメンテナンス性が高いと信じています。なぜならば、すべてが再代入なし（= すべてが定数）の方がバグが生まれにくいはずだからです。 （いわゆる関数型プログラミング、というやつです。） と、いうことで私は基本的に再代入をしないコードを書くように心がけています。 （もちろん、それによるデメリットがあるのも承知でそのようにしています。） 私が始めたOSSではありませんが、現在は9割方私が書いたコードになっているnode-lambda ( https://github.com/motdotla/node-lambda ) （JavaScriptです）を例に、頑なに再代入をしない（関数型プログラミング）を実践した例を紹介します。 （これまではデメリットについて、厳密に検証したことがなかったのですが、改めて検証してまとめてデメリットについても発表します。） 大規模開発の参考になること間違いなし！
https://fortee.jp
頑なに再代入しない！ - 2025-11-12 - ククログ
頑なに再代入しない阿部です。 YAPC::Fukuoka 2025で頑なに再代入しない！というタイトルでトークします。 スライドも公開しますが、発表用のスライドのため十分な説明が記載されていないので、解説テキストを追加したブログ記事も残します。
https://www.clear-code.com
次は、 abetomo さんのセッションを聴講しました。
このセッションでは JavaScript における再代入の問題点と、代替手段との比較について紹介されていました。 再代入することでコードの可読性が下がったり、バグの温床になったりすることがあるという内容でした。 一方、再代入を避けた場合のパフォーマンスへの影響についても触れられていました。
自分も JavaScript を書くことが多く、再代入はあまり使用したくないと考えています。
また、自分は JavaScript を書く際には Biome というリンターを使用することが多いです。
Biome ではそもそも推奨設定で let の使用を禁止しており、再代入を避けることを強制しています。
useConst
Learn more about useConst
https://biomejs.dev
パフォーマンスについては普段あまり気にしていなかったため、実際に計測された具体的な数値を見ることで意識が変わりました。 ただ、多くの Web アプリケーションではネットワーク通信の時間が支配的なため、この差が問題になることは少ないでしょう。 とはいえ、パフォーマンスが重要な場面もあるため、状況に応じて判断していきたいです。
学生支援プログラム懇親会
スポンサーの企業の方と学生参加者でわいわいもつ鍋を囲みました。 自宅サーバーの話などで盛り上がっていた記憶があります。
博多といったらもつ鍋
もつ鍋を食べてホテルに戻り、寝落ちをして一日目は終了しました。
Day 2
慣れないアパホテルのベッドでアラームに起こされ、寝坊する友人を置いて再び会場へ戻ってきました。 二日目はセッションを聞いたり、スポンサーブースを回ったり、踊り場の企画に参加したりと盛りだくさんでした。
OSS開発者の憂鬱
OSS開発者の憂鬱
「OSS」ってキラキラして見えるかもしれないけど、憂鬱になることがたくさんある。これまで愚痴を表に出すことはしなかったけど、このトークではあえてそれをさせてくれ。今までの苦労を成仏させてくれ。 僕は2021年の年末からHonoというOSSを作っている。それは驚くほど人気になった。2025年8月現在、GitHubのスター数は「26K」。日本人発のプロダクトだと世界で第3位の数字である。この規模のOSSを開発・メンテナンスをできるのは非常に貴重な経験で「僕にしか見れない景色」を見ている。今回はその景色を少しでもあなたに見てもらいたい。決して、OSSにコントリビュートすることを促すわけではない。ただ、あなたが使っているソフトウェアの背景にはとんでもないドラマがあるってことを知ってもらいたい。 具体的には以下のトピックを話します。 * Honoの現状 * 僕らはCPANで息を吸うようにOSSをしていた * GitHubのInboxが恐怖 * ありがたいIssueと厄介なIssue * Whyを聞かれると辛い * Share a minimal project to reproduce it! * 中学生コントリビューター * 登山をしてたら向かいから集団が来て全員に挨拶しなくてはいけない問題 * 嫉妬される * Noを言うのは大変 * やりたいことをシェアしない * Hono Conference * 外向的性格がOSSをやると * You are a legend! * 頑張ればなんとかなる * そして、希望 まぁ、大変だけどすごく楽しいよ！ 同タイトルのプロポーザルをYAPC::Hakodate 2024の際に出しましたが、個人的都合で当日行けなくなりました。テーマは同じですが、当時とは状況が変わっているのでアップデートした内容になります。
https://fortee.jp
次は yusukebe さんのセッションを聴講しました。
yusukebe さんが開発している OSS の TypeScript フレームワーク Hono での話を中心に、これまでの OSS 開発の変化とその憂鬱な部分について紹介されていました。
Web framework built on Web Standards
Hono は以前から自分も使用しており、比較的身近な OSS です。 自分が使っている Hono だからこそ、OSS として成長する中での苦労という話はリアルに響きました。
大規模OSSに一人で立ち向かうには のセッションが「貢献者側」の視点だったのに対し、こちらは「作者側」の視点であり、対照的で面白かったです。
自分もエンジニアとして、OSS エンジニアに対しては多かれ少かれ憧れを持っています。 OSS は良いことだけではない、むしろ辛いことの方が多いというのは以前から知っていましたが、具体的な話を聞くことで改めて認識できました。
また、憂鬱を減らすための貢献者側の心得として、Minimal Reproduction を作成しバグの再現を助けることが重要だという指摘は、自分も心がけていきたいです。 自分も OSS へ Issue や PR を送るときは、できるだけ再現手順を丁寧に書くよう心がけています。 今後もこの点は深く意識し、メンテナーが心地良く開発できるように貢献していきたいです。
機密情報の漏洩を防げ！ Webフロントエンド開発で意識すべき漏洩ポイントとその対策
機密情報の漏洩を防げ！ Webフロントエンド開発で意識すべき漏洩ポイントとその対策
Web サイトの JavaScript や CSS はブラウザから閲覧できます。従ってそれらに機密情報が入らないよう、細心の注意を払わなければなりません。なになに? 「minify してるから大丈夫。」「モダンなフレームワーク使ってるから大丈夫。」...だって? 本当にそうですか? 機密情報の漏洩を招くポイントは、様々な場所に潜んでいます。このトークでは、一般的なWebフロントエンド開発で意識すべき漏洩ポイント、そしてその対策についてお話します。 - Source Map 経由での漏洩 - Client Component 経由での漏洩 - Next.js Pages Router の _buildManifest.json - その他注意すべき漏洩ポイント - 漏洩の確認方法 - 漏洩を防ぐには
https://fortee.jp
次は mizdra さんのセッションを聴講しました。
このセッションでは、Web フロントエンド開発における機密情報漏洩のリスクとその対策について紹介されていました。
自分はフロントエンドを書くことが多く、とても身近な話題でした。 幸い普段から意識していることが多く、特に Server Components は使用することが多いので、改めて知識を整理できました。
どのように漏洩するかについては既知の情報が多かったのですが、後半の漏洩の有無を調べたり漏洩を防ぐための機能については知らないことも多かったです。 特に、Chrome DevTools での検索機能は知っていたものの活用できていなかったので、今後活用したいです。 また、 React の Taint API については知らなかったので experimental ではありますが、情報を追っていきたいです。
experimental_taintObjectReference – React
The library for web and native user interfaces
https://ja.react.dev
next.config.js: taint | Next.js
Enable tainting Objects and Values.
https://nextjs.org
探求の技術
探求の技術
本発表では、急速に進化する技術の世界において、いかに効果的に新しい技術を探求し、その知見を価値あるアウトプットに変換していくかについて、実践的な方法論を共有します。 私は毎週技術ブログを執筆し、年間300冊の本を読むという活動を続けています。この継続的な探求活動から得られた知見を基に、技術者として成長し続けるための具体的なテクニックをお伝えします。 - 技術探求の原動力について - 効果的な技術記事の書き方に - AI時代における技術探求の在り方
https://fortee.jp
次は azukiazusa さんのセッションを聴講しました。 このセッションでは、azukiazusa さんが技術を探求しアウトプットするための、原動力と記事の書き方について紹介されていました。
自分もよく azukiazusa さんのブログを読むことが多く、その記事はとてもわかりやすいと感じています。
azukiazusaのテックブログ2
azukiazusaのテックブログ2です。週に1回 Web 開発に関する記事をお届けします。フロントエンドに関する分野の記事が中心です。
https://azukiazusa.dev
翻って自分の探求はというと、技術に関する情報収集は好きで Twitter の TL や GitHub の Feed をよく追っています。 しかし、それらの情報を咀嚼し言語化することがあまりできておらず、その力が不足している自覚があります。 セッションの中であった 「自分の学習効果を最大化するためにアウトプットを行う」 というものは自分にとってまさに足りていない部分であり、今後意識していきたいです。
技術記事の書き方についても、実践的なノウハウが詰まっていました。 中でも AI を構成の壁打ちや構成の確認に用いるのは、自分も取り入れたい方法です。 例にあった textlint MCP は、CLI の方は既に使用しているので MCP も試してみたいです。
textlint MCP Server Setup | textlint
Model Context Protocol (MCP) is an open standard that enables AI models to interact with external tools and services through a unified interface. textlint CLI contains an MCP server that you can register with your code editor to allow LLMs to use textlint directly.
https://textlint.org
懇親会
セッションやキーノートが修了し、バスに揺られて懇親会会場へ。 これまでいくつかのカンファレンスに参加してきましたが、会場が別に用意されているのは初めてで少々驚きました。
懇親会といったらお寿司
懇親会では様々な方とお話しました。 特に、バイトでお世話になっているはてなの方々と初めてお話しできたのは嬉しかったです。 他にも学生の方や、様々なエンジニアの方とオリジナルのビールを片手に歓談しました。
あっという間に時間が過ぎ、名残惜しさを感じつつも会場を後にしました。
まとめ
初めての YAPC 参加でしたが、幅広い内容のセッションを聴き、たくさんの人と交流できました。 Perl に限らず、日々の開発や OSS との向き合い方について持ち帰れるものが多かったです。 コミュニティの温かさも印象的で、来年、再来年も参加したいです。
また、繰り返しにはなりますが、Japan Perl Association による旅費支援制度には非常に感謝しています。 本当にありがとうございました。
来年は …
YAPC::Tokyo 2026 in Tokyo Big Sight
また来年、有明でお会いしましょう !
おまけ - 福岡観光の写真
0日目 博多到着後に食べた博多ラーメン
2日目 深夜に食べたラーメン (なんと 290 円 !!!)
3日目 博多ポートタワーから眺めた景色
4日目 太宰府天満宮の参道にて 梅ヶ枝餅と抹茶
4日目 飛行機から眺めた博多の夜景
