onkとそーだいによるキャッシュの話です。
次の記事を元に話します。

• https://onk.hatenablog.jp/entry/2023/12/18/000000
• https://soudai.hatenablog.com/entry/cache-strategy

サーバー監視 SaaS である Mackerel の OpenTelemetry 対応の一環として、ラベルつきのメトリックを自在に引くための PromQL エンジンを開発しました。PromQL は Prometheus というオープンソースの監視ソフトウェアで使われているクエリ言語です。

新卒エンジニアが初めて携わったこの大型開発の裏側とそこから得た学びを共有します。リリース10年目を目前にする SaaS に、 OSS に依存する大きな機能追加を行うエンジニアリングをみなさまにも追体験していただきます。

こんなことを話します：

• なぜ PromQL を選択したか
• 既存のシステムを壊さずに生かすアーキテクチャ設計
• どこまでを OSS に任せ、どこからを自分達で作るのか
• 素早く動くものを作るためのマインド
• OSS の挙動を広く・あるいは深く理解するための道具

私の所属する会社では、長年 Perl を用いた開発を行ってきました。
ここ数年で Go言語 への移行を進めていますが、大量にある Perl 資産を即座に全てGoに移行することは出来ず、並行運用しながらサービスの開発を行っています。
並行運用を行うということは、それだけ運用コストが発生します。

弊社のある試算では Perl のコードを全て Go に移行しきるまでに約 10年 の期間を要するのではないかと出ており、ここまでの長期間の保守を行うことは困難さがあります。

そこで、Perl から Go の移行を加速するための、Perl XS と Cgo を用いた Go の連携や、モダンなコンテナ環境、モダンなデプロイフローの構築など
Go への移行を円滑に行えるように取り組んでいる内容をお話します。

みなさんは15年以上動き続けるPerlのアプリケーションを見たことはあるでしょうか。私の周りには、数は減りましたが、そのようなアプリケーションがたくさんあります。その多くは積極開発フェーズではなく、いわゆるメンテナンスフェーズという状態です。
このようなアプリケーションでは、例えばそれぞれのフレームワークが違うとか、最初に書いた人の個性が大いに現れているとか、同じアプリケーションでも、いわゆる"雰囲気"が違うなど、一言では言い表せないような、様々な状態になっています。
積極開発されていないため、このような状態はもしかしたら「荒れ地」に見えるかもしれません。しかし、メンテナンスフェーズにあるからこそ、見えてくることもあるのではないでしょうか。
この発表では、古いPerlアプリケーションを運用する経験において、私が考えていることを整理し、Perlに限らない提言としてお話します。

2023年のYAPC::KyotoではChatGPT（LLM）がホットなトピックとして盛り上がった印象です。
Web API経由で使え、文章生成や要約をさまざまなWebアプリケーションに追加できます。

LLMから望む出力を得るにはプロンプト（例：以下の文章を要約してください）が重要です。
一方、開発を進める中で精度改善を狙ってプロンプトは変更されます。
では、プロンプトの変更前後でLLMが生成する文が同じなのかどうか、どのように評価すればよいでしょうか。

このトークでは文章の定性評価の評価指標を紹介していきます。

• ROUGE
• BLEU
• BERTScore
• LLM as a judge（最近の研究動向）

Pythonにそれぞれのライブラリがあるのですが、ROUGEやBLEUはPerlのスクリプトがベースという点が興味深く、YAPCでの発表のモチベーションとなっています

SonikはJavaScriptの「メタ」フレームワークです。メタというのは以下の3つの技術の上に成り立っているからです。

1. Hono - Web framework
2. Vite - Bundle & Dev tool
3. UIライブラリ - hono/jsx, Preact, React

Sonikを使うことにより2つのことができます。

1. ファイルベースルーティングによる大きなWebアプリの作成
2. フルスタックアプリケーションの作成

特にSonikは、バンドルサイズが小さく、レンダリングが高速で、Cloudflare PagesやVercelなどのエッジ環境に適しています。またDXも優れていて、CloudflareのBindingsに対応した高速な開発サーバーを備えています。

現在「アルファ」ステータスですが、当日は完成度の高いものを見せれると思います。

1993年にまつもとゆきひろ氏によって開発されたプログラミング言語Rubyは、Perl, Smalltalk, LISPなどの影響を受けながらも独自の魅力を持ち、日本をはじめ世界で利用されています。
私はこの10年Rubyを使い続けてきましたし、今後も使い続けるつもりでいます。このように「Rubyに対してお客様以上の気持ちを持っているプログラマーのこと」をRubyistといいますが、その意味で私はRubyistです。RubyにRubyの何が私を惹き付けるのか。このトークは以下の内容で構成されています。

1. Rubyとはどのような言語か、Rubyの現在位置
2. Rubyの魅力を考察する
3. Rubyでこんなことができます

チームでWebサービスを開発する場合、複数の機能やデータを持つブランチが並行して開発されます。チームのメンバーなら職種を問わず、好きなだけブランチ別の環境を起動できる仕組みがあると、開発と動作確認のサイクルを高速に回すことができます。

そのような仕組みを実現するために、IaCでサーバーリソース一式を丸ごと構築すると、起動までの時間や金銭的なコストが大きくなってしまいます。

mirage-ecs(github.com/acidlemon/mirage-ecs)は、Webサービスの検証環境を誰でも、何個でも、低コストで立ち上げるためのOSSです。 「環境」はAmazon ECSのタスクとして数分で起動し、専用のURLでアクセスできるようになります。

開発者がその原理と実装、数十人の開発チームを持つ複数プロダクトにおける運用で得られた知見についてお話します。

経済産業省作成のレポートによると、パブリッククラウドの利用料を中心とする「デジタル赤字」は2030年には8兆円を超えるともいわれています。
円安も続くいま、クラウドコストの「最適化」に留まらず、より強気な「削減」を行わざるを得なくなることも予想されます。

今回は、私たちがコスト削減代行を100社以上行ってきたノウハウをもとに、
きれいごとではなく、何が何でも1ドルでも減らすための活きた「ケモノ道」的テクニックを紹介します。

話すこと

• 具体的な削減手法の実例
  • アプリケーションのチューニング
  • リアーキテクチャ
  • インスタンス最新化
  • 通信経路最適化 and more...

対象者

• パブリッククラウドでサービスを展開している方

※あらゆるパブリッククラウドに通ずることについて発表したいとは思っていますが、事例はAWSに関するものになります。

10年以上前に「タワレコ店員からエンジニアになって思ったこと」というスライドを書きました。

そこからさらに10年が経ち、今は OSS のメンテナやプロジェクトリーダー、マネージャなどやれることも少しずつ広がってきました。
気がつけば「プログラマー35歳定年説」を超える年齢となりましたが、今でもコードを書くことを仕事として楽しんでいます。

このトークでは、これまでのキャリア（業務、OSS、転職、同僚）における失敗や成功を通じて学んだことや、大事にするようになった考え方を紹介したいと思います。
また、私自身 Perl や YAPC、コミュニティからも学んだことも多くあるのでそれについても感謝も込めて紹介できればと思います。

エンジニアとしてこれからやっていけるか不安を持っていたりキャリアに悩んでいたりする方に、大丈夫、楽しもうと思ってもらえるようなトークになればと思っています。

皆さんは普段どんなプログラミング言語を使っているでしょうか
golangなどのコンパルする言語もありますが、Perlを始めとするスクリプト言語を使っている方も多いでしょう。
現代のスクリプト言語は実行時にスクリプト言語のソースコードを、言語内独自のVMが実行可能なアセンブラのような命令にコンパイルし、その結果を実行する方式が多いです。つまり、現代においてはスクリプト言語を実装するということはほぼCPUの命令実行シーケンスを実装することと同義です。

特に最近は一部界隈ではRubyの処理系であるRubyVMを実装するのが流行っています。

本トークではRubyVMをPerl...ではなくて、Raku(旧Perl6)で実装し、Rakulangの言語の面白さとRubyVMの実装の面白さについて見ていきます。
なお現時点でコードはほとんど書いてないので当日までに完成するかは......。お楽しみに

PostgreSQLで素朴に全文検索をする場合、LIKE演算子を使った中間一致になります。
デフォルトのPostgreSQLでは、LIKE演算子を使った中間一致検索にはインデックスを使用できないため、データ量に比例して検索速度は低速になります。

PGroonga(ぴーじーるんが)は、全言語対応の高速な全文検索機能をPostgreSQLで使えるようにする拡張です。
PGroongaでは、英数字も日本語等のマルチバイト文字に対してもインデックスを使った全文検索が可能です。検索速度は非常に高速で、かつ高機能です。
本発表では、PGroongaがどのくらい速いのか、どのような便利機能を持っているのかを紹介します。

本発表は、PGroongaのことをまだ知らない or PGroongaに興味はある（聞いたことはある）が詳しいことはしらない人 or 高速に全文検索したい人向けの発表です。

twitter(X)に何かあるたびに話題になるmastodonやmisskeyのような非中央集権型マイクロブログサービスが構成するネットワークは"fediverse"と呼ばれます。これらは主にActivityPubというプロトコルで接続されていますが、ActivityPub仕様は大枠を定めているだけであり、実際に現在のfediverseに参加するには単にプロトコルの仕様書に書かれていること以上のノウハウが必要になります。

このトークでは、Perl版ActivityPubサーバ"Actub"を紹介しながら、fediverseに参加するサーバアプリを作成するために必要なノウハウについて概説します。

内容としては、Builderscon 2019で発表したものをベースとして、Perlでの実装方法と、その後のfediverse界隈の変化に対応した最新の状況についてお話しします。

いつも通り、開催時にはそろそろ全容が見えてきているであろう Perl 5.40 の新機能などを紹介します。

Goは並行処理で知られていますが、アクターモデルを導入することで、
さらに洗練された並行処理ができるようになります。

このセッションでは、アクターモデルの基本的な考え方とGoで実装する際の具体的な手法と効果、
実際の導入例をもとに詳しく解説します。
メッセージベースのコミュニケーションを中心としたアクターモデルが耐障害性や拡張性にどのような影響をもたらすのか、
EIPについてやProtoActor、Ergoといったツールキットも交えてお話しします。
Goとアクターモデルの組み合わせによるすこしだけ違うプログラミングパラダイムを探求してみましょう！

言語を問わず利用できるEvent SourcingはCQRSとの組み合わせだけでなく、そのエッセンスは様々な仕組みに取り入れることができます。
マイクロサービスアーキテクチャ化、大規模なデータ処理の改善、CDC、
分散システム・リアクティブシステム構築などではほぼ必須のテクニックとなっています。
しかし、ネット上にある記事を鵜呑みにしてしまうと致命的なアンチパターンに繋がってしまうことも多くあります。
状態をもたせないイベントでマテリアライズドビュー化してしまう、
巨大なランタイムを持たせてしまったハンドラ、
分割しすぎて時系列を無視したイベントなどなど。
当然いくつかは実際にやってしまったこともありますが、
このセッションでは実体験をもとにEvent Sourcingとは何かを説明しながら、
何をすべきでやるべきでないのかを楽しくお話します！

私は、今年で9周年を迎えたソーシャルゲームのサーバの保守・運用に従事しています。今回は、既存のサービスに対して新しい取り組みを行う模索として、Perlで動いているサーバに対してAPI通信を行ない、クライアントとして振る舞うプログラムをGoで書いてみるという挑戦をしました。このような挑戦をするに至った経緯や、ぶち当たった壁・それを通して感じたことなどをお話できたらと思います

話すこと

• この挑戦をするに至る個人的キャリア上の動機
• Perlで仕事を覚えた人間が、今Goに触れてみて感じたこと
• 9年間熟成された、弊社独自のAPI仕様書を紐解いてみる
• 初心者だからこそ、車輪の再発明をしないように気をつけよう！知名度のあるOSSに乗っかろう！…その気持ちが引き起こした失敗と成長
• 同じ仕事を何年もやり続けて、なかなか挑戦の機会が与えられなくても、自分で挑戦の機会を作り出すことはできる

キャッシュはパフォーマンスを劇的に改善する効果がある反面、一度使うと簡単にはやめられない複雑性と中毒性があります。
その特性から「キャッシュは麻薬」と言われ、安易な利用は忌避されています。

しかし、キャッシュがもたらすパフォーマンスの改善効果は無視することはできず、コンピュータの世界において有効活用されているのも事実です。

そこで今回は実際にキャッシュを使う時に陥りやすい問題を取り上げながら、実際の活用例を説明します。

話すこと

• キャッシュが有効な例と失敗例
• キャッシュを実装パターンと始めるときの勘所

対象者

• アプリケーション開発などでパフォーマンスに苦労したことがある人
• キャッシュを利用したサービスの運用で苦労ｗしたことがある人
• キャッシュを利用したことがないが、怖いなと思っている人
• とにかく今すぐパフォーマンス改善したい人

このトークでは、私が実務でイチからバックエンドアプリケーションを開発する際に実践している手法について紹介します。

近頃私はTypeScriptでバックエンドAPIを開発していますが、今回はPerlで簡単な事例を作って解説する予定です。
決して真新しい内容ではないでしょうが、この技術選択をした背景と理由を交えたトークにします。

対象者 中級者～上級者向け

• クリーンアーキテクチャの実践例を見たい方
• 手続き型プログラミングの手法が気になる方
• アプリケーション設計にの知見を深めたい方

話すこと

• 技術選択の背景と目的
• コンポーネント構成と依存関係
• 純粋関数とビジネスロジック
• 目的別のテスト
• 利点と試行錯誤している箇所

深く話さないこと

• クリーンアーキテクチャとDDDの定義
• ビジネスロジックの定義
• 細かいプログラミングのテクニック

いま私がイチオシする技術、WebAuthn/パスキーについて紹介するトークです。

しかしただ紹介するのではつまらないので、WebAuthnの仕組みを解説しながらライブコーディングを行っていきます。現代のPerlで書くので今どきのPerlの書き方もわかって一石二鳥ですね！

注意点

• WebAuthn/パスキーの簡単な概略だけ最初に解説します
• WebAuthnのサーバー実装を主に解説します
• 時間の短縮のため、いわゆる「作り置き」スニペットを使用するかもしれません
• Perlの書き方の説明は私が解説したいときにだけします
• フルスクラッチと言っても細かい技術要素はCPANモジュールを活用します
  • 例: 署名検証, CBORのパーサーなど

対象者

• WebAuthnを本質的に理解したい方
• 今どきのPerlを書いている人を観察したい方