STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

Euruko 2025 発表してきました

技術推進本部の shia です。最近東京は天気が荒れやすく、湿っぽい夏になっている印象ですが、ひと足先に秋を感じてきましたのでその話をしようと思います。

先日 09/18-19 にポルトガルの Viana do Castelo で開催された Euruko 2025 に参加してきました。あちらは昼でも 25度くらいで、 半袖だとやや肌寒い感じでいい天気でとても過ごしやすかったというか半袖しか持っていってないのでやや寒い生活をしていました。それはさておき、自分が発表した話や面白かったセッションなどをレポートします。

Euruko 2025

EuRuKo は、ヨーロッパで行われる代表的な Ruby に関するカンファレンスです。去年は弊社の笹田さんも発表者として参加しており EuRuKo2024 で発表してきました(YARVの話)というレポートを公開しており、サラエヴォで開催されてました。

Euruko は話を聞いてる限りだとシングルトラック + ワークショップなどが開催されたりする感じらしく、去年は異例的にマルチトラックでしたが今年はまだシングルトラックに戻り 16トーク、 6 ワークショップという構成でした。

今回は文化会館を丸ごと借りてやっており、大きなホールを二つに分けて半分はステージ、半分はスポンサーやフリースペースとして活用されてました。こういう空間の分け方もあるんだなと感心しました。

ホールのフリースペースの様子

これがカーテンの内側のステージの様子です。なお、よくある Rubyist Karaoke もここで行われました。こわい

キーノート - Matz

Matz のキーノートで開幕しました。 My favorite things ということでプログラミング言語の話がいろいろされました。個人的には最後の話が記憶に残っていて、人生、塞翁が馬ということで、現在は静的型言語が人気でうまくいってるけれども今後どうなるのかな〜ということを考えたりしました。どうなっていくのでしょうね。

セッション

以下は聞いたセッションの感想を英語足りずの人ですが、少しメモったのでそれを共有しておきます。時系列で紹介しており、全体に関してはホームぺージからも確認できます。動画もいずれ Youtube に上がってくるのではないでしょうか。

Introducing ReActionView: A new ActionView-Compatible ERB Engine - Marco Roth

Herb の話でした。 RubyKaigi で話したネタの延長っぽかったのですが、自分が今年聴き逃したので結構面白かったです。 ERB を HTML aware にすることで事前に検知できる問題を増やしたり、レンダリングされた要素がどの partial view からきたのか分かりやすく表示する機能とかも印象深かったです。

現代だと色々回り回って Node.js でも SSR してブラウザに渡すということがパフォーマンス上有利と話される時代という認識をしておりまして、それってサーバ側でテンプレートエンジン使ってレンダリングするのと大きく違わないといえそうだな〜とちょっと思ってるんですよね。もちろん dehydration があるので完全に同じとは言えないのですが、そこをいい感じに吸収するのが Stimulus の仕事という認識をしてます。そこで Stimulus + css で一定欲しい UI を実装できるなら、それなりの場合はそれでよかったりしないかな?と説得されまして、 Stimulus メンテナである発表者に React がないと困るケースどれくらいあると思ってるの、と聞いてみようと思ったらその後会えませんでした...

それとは別で、これくらい周辺ツールが充実してるなら色々なテンプレート言語やめて ERB に寄せた方がよさそうなどを考えました。それらがあれば仕事が捗りそうなので会社のアプリケーションで試したいですね。

Postgres Partitioning Best Practices - Karen Jex

なぜか突然(じゃないかもだけど)の Postgres のパーティショニングの使い方の話でした。 パーティションがあればよい場合(e.g. vacuum の代わりにパーティションごとの捨てるとか) 、あっても解決できないものやデメリット(e.g. 軸が複数だと大量のパーティション扱うのが大変、 かならず PK に含めるべき)みたいな話をされました。個人としては Postgres でパーティションを使ったことがないのでそうかそうか〜そうだよね、とか相槌うったり、辛いところが DynamoDB っぽくて興味深く聞かせてもらいました。

Rewrite with confidence: validating business rules through isolated testing - Szymon Fiedler

保険システムのリファクタリングをお題にこういう戦略をとったぞという話でした。 理解したものが正しければ、本番の処理そのもの記録 & 外部システムとのやりとりも丸ごと記録しておいて、新しい実装で同じ処理を実行するただし、検証終わったらトランザクションを rollback させる & 外部のやり取りはレコードしたものを活用する(つまり vcr gem がやってることと一緒)というものでした。

最初はひええ〜〜と思いながら聞いていたんですが、外部システムを含めた一つの処理を完全にリライトする時の検証方法と考えると、例えば全く同じ環境をもう一つ作り上げたとしても外部サービスが適切に繋がらなかったりするので、本当に丁寧にやる必要があるのならありなのかも。。。となりました。

The hidden value of niche open-source projects - Rémy Hannequin

TL; DR すると小さい雑な OSS でもやる価値はあるからガンガンやろう!というものでした。自分しか使わないものが知らない会社で使われてスポーンされるというのはとてもおもしろ体験に違いありません。 自分は必要だけど別に社内限定にする必要がないものを OSS で書いているだけの人間なのであまりこういうことを真面目に考えて作ってないので結構新鮮な話ではありました。

How a Ruby profiler works: Stackprof under a microscope - Ivo Anjo

今年の RubyKaigi のキーノートでは Ruby 側で使える internal API を紹介したり使う話をしてくれましたが、今回の話は stackprof はこう動くよ〜という話でした。肝は 1000行だよ、ここからここまでがトレースロジックで、ここからここまでがそれを保存するところだね、ね、簡単でしょ?という感じでボブおじさんが後ろから見えてきたのは僕だけじゃなかったと信じたいです。理屈はわかるんだけどそうじゃないんだ。。。中身をちゃんと理解できたとは言えないので詳しく書けませんすみません。資料公開されたらそちらをみてください。

Conquering Massive Traffic Spikes in Ruby Applications with Pitchfork - Sangyong Sim (Shia)

speakerdeck.com

自分の発表ですね。初日でほんと良かった。 STORES ネットショップで大規模なトラフィック増加が発生するイベントがあるが暖気が足りないウェブサーバをどうにかするために Pitchfork を導入していい感じにしました、という発表でした。 発表そのものは頑張りましたが、唯一予想してなかったのが現地のみなさんは本番ではほぼ puma を使ってると答えたところです。 Rails のデフォルトが変わったことが結構デカかったのかな。 なんなら Falcon どうよとか言われてて時代を感じました。一方で passenger 現役話も聞かせてもらい、お互い頑張ろうなとなりました。

Building interactive Ruby gem tutorials with Wasm – yes, right in the browser! - Albert Pazderin

Rails tutorial を wasm 上で動かすというやつでした。 Rails がブラウザで動かせるということはこういうことですよね。 初心者がよくセットアップでハマることを考えるとチュートリアルはこういった形で構成すると大変便利かもしれません。

https://rails-tutorial.evilmartians.io/ でお試しになれます。

Roasting Code for Fun & Profit with Structured AI Workflows - Obie Fernandez

Shopify/roast - GitHub の話でした。決定的なステップを挟むことで失敗確率を下げていきたいというのは良く分かるのですが、自分としては使いまわしたいプロンプトがあまり思い浮かばなくて試せてないツールでした。もうちょっと抽象的なワークフローを組む必要があるのかもしれません... それはさておき外部コマンド実行はもちろん、入力も受けられるし、並列実行も可能だしツールとして処理を切り出せたりして結構作り込んでいます。

RubyLLM: Making AI Development Beautiful Again - Carmine Paolino

RubyLLM の紹介でした。 Python のライブラリと比較しながらインタフェースはこう設計しました〜と話していてとても良いなと思いました。 インタフェースの設計の話であった 「Simple should be simple, complex should be possible」 という文章がとても良かったのでここにも貼っておきますね。

Don't Be "Thread"-ened: Testing Multithreaded Code with Confidence - Julia Egorova

ライブラリとしてスレッドが必要なものをメンテしていてどう頑張ったのか、の話になります。大きくはなしでテストできるように設計しよう(e.g. Thread.new の内部の処理を切り出してテストしたり)、とかしゃーない時は concurrent-ruby の CountDownLatch などを使っていい感じに待って結果を確認したりしましょう〜というものでした。なお実装側にはそういう Latch を差し込める場所がないのでオブジェクトをパッチングして差し込んだりしてるのがやゔぁかったですね。スレッドは大変。

Pitch: next year's Host

これはなにかというと、 Euruko の名物らしい次回の開催地を決めるための City Pitch になります。つまり、来年開催したい都市の自慢をします。このピッチが終わったら各位に配られた Ruby で投票が開始されクロージングで一番多くの Ruby を得られた都市が次の開催地になるというものですね。

これが選挙権です

今年は4箇所ありまして、

  • Paris, France
  • Poznań, Poland
  • Brno, Czech
  • Coimbra, Portugal

アピールポイント全部違くて面白かったです。我々はいろんな宝石を持ってるけどまだ Ruby という宝石がないんだ!きてくれ〜とか。毎年この都市で Java のやつらがイベントしてるんだ、対抗できるように助けてくれ〜とか。

結果としては Brno になりました。チェコ第二の都市として知られてるらしいです。どんな感じかな〜

gRPC on Ruby On Rails - a perfect match! - Emiliano Della Casa

パフォーマンスが欲しい時は gRPC !ということで、 grpc on Ruby の基礎の話として grpc gem や protobuf 周りの話がメインでした。そ、そうかな。。。

Prioritization justice: lessons from making background jobs fair at scale

非同期ジョブをフェアに処理するためにはどうするべきか、という話でした。 例えば、マルチテナントで一つのテナントがめっちゃくちゃジョブを追加してその他のテナント はどうしたほうが公平なのか、ですね。 まず公平さはなんなのか〜から始めて幾つかの軸で複数のソリューションを比べて最終的にはテナントごとに適切なタイムスライスが提供できる gem を作ったよ。と締めました。 記憶違いじゃなければ Envek/sidekiq-fair_tenant - GitHub です。

LT & Workshop

ここが二日目ランチ後、なのですけれども LT とワークショップで分かれて進行されました。 LT は前日あたりで募集するのでよろしく! FIFO でやるよ〜となってました。最近自分が参加するところだと結構前もって申し込んだり審査があったりするので本来の形に近い LT をみたな〜という感想です。各位5分で 1.5hr やっていたので流石に細かくは扱いません。

その間、ワークショップはどうも会場の外側の場所を借りて行われてました。ワークショップの参加募集も参加数日前にされて自分が発表準備をしている間にほぼ全て埋まってました。そのため、LT を眺めながらコードを書いてました。残念。

tidewave はなぜそのようになったのか、という話でした。 MCP で外部のツールに繋げるのは安全ではない、できればランライムで全て取得すべき。 coding agent を作ってるものに統合しよう、つまりウェブアプリを作るならブラウザに統合したほうが一番適切なコンテキストが得られる、というとても納得できる話でした。そう言いながら実際作ってしまうのが José ですよねぇ。個人的には便利そうだな〜と思いつつ、であれば、ウェブ UI とはあまり関係がないところ開発する時はどうしたらいいんだろね、と思ったり。シェルで動くからシェルに統合されるべき...? つまり Claude Code みたいなもんで良いのでしょうか?

Making Rails AI-Native with the Model Context Protocol - Paweł Strzałkowski

直前に MCP サーバなんか使うなみたいな話をされた後これがきてほ〜?と思いながら聴き始めたんですが、サービスのインタフェースとして MCP Tools を Rails way で提供する話で面白かったです。 rails scaffold で mcp tools が生えるんですよ、すごくないですか。 pstrzalk/mcp-host-on-rails - GitHub にサンプルコードがありますので興味があればぜひ見てみてください。

クロージングキーノート - Eileen M. Uchitelle

Rails World 2024 のキーノート再演でした。 巨大モノリスと言われるといろいろ考えさせられるものがある人間としては大変興味深い話して、モジュラーモノリスは銀の弾丸ではなかったという話を実際世界で一番大きいモノリスで試した人から聞かされると重みがありましたね。

全体の感想

振り返ってみると 4 つくらいが AI 関係トークであったことは興味深いものでした。なおバリエーションもちゃんと豊かな感じでよいな〜と。 ただ、仕事としてインフラの面倒を見ることが多くなった人間からするとみんな普通に LLM からの応答待ってるよ〜という風に話しているところが少し気になりました。ウェブサーバからするといわゆる Slow client というものでして、デプロイ速度やデプロイそのものの安定性に影響する認識なんですよね。これはコンテナの上で動かしてるなら非同期ジョブキューでも同じのはず。 IO 待ちがメインであるこれらが増えるということはシステム安定性だけではなく最大並列実行数も大きく引き上げる必要がある、という認識でして、今後はこの辺を適切に扱うためのインフラやアプリケーション設計が重要になっていくのかもしれないな〜となりました。どうしていくといいのかな〜

終わりに

この記事では Euruko 2025 で何があったかを軽く触れました。もし興味があるネタが見つかった & 来年は参加してみたい!という気持ちになれたら幸いです。