2026年7月18日(土) に大津市伝統芸能会館で開催される関西Ruby会議09に、永和システムマネジメントから haruguchi が関西LT保安協会 (とは？) に登壇します。
ここでは、登壇者から LT 内容について軽く紹介をします。
「滋賀県観光保安協会だより」をお届けします。全国から滋賀へお越しになるRubyistの皆さまの安全と観光満足度を守るため、当協会が琵琶湖のほとりから選りすぐりの滋賀情報をRubyとともにご案内する5分間です。旅のしおり代わりにぜひご覧ください。協会一同、湖畔でお待ちしております。
LT の時間は 16:30 から 17:20 です。
また、永和システムマネジメントは Gold Sponsor として協賛しており、当日は koic と ham-cap も参加予定です。
それでは滋賀県の大津市伝統芸能会館でお会いしましょう。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
2026年7月の Rails / OSS パッチ会を 7月8日(水)に Discord でオンライン開催します。
この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS について、upstream にパッチを送る会です。
会には Ruby と Rails のコミッターで、RubyKaigi のチーフオーガナイザーでもある顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。
開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。
Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です。
今月開催される関西Ruby会議09の話題などあると思います。
これからパッチ会に参加してみたいという方、OSS 開発者間の会話に興味があるので聞いてみたいという方もお気軽にどうぞ。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
2026年6月の Rails / OSS パッチ会を 6月26日(金)に Discord でオンライン開催します。
この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS について、upstream にパッチを送る会です。
会には Ruby と Rails のコミッターで、RubyKaigi のチーフオーガナイザーでもある顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。
開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。
Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です。
来月開催される関西Ruby会議09の話題などあると思います。
これからパッチ会に参加してみたいという方、OSS 開発者間の会話に興味があるので聞いてみたいという方もお気軽にどうぞ。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
2026年6月6日(土) に島根県指定有形文化財の興雲閣で開催される松江Ruby会議12に永和システムマネジメントから koic と S.H. が LT に登壇します。
ここでは、それぞれの登壇者から LT 内容について軽く紹介をします。
koic です。今回、松江Ruby会議へ初参加ということで LT を持参して参加させてもらいます。
Ruby の NotImplementedError は本来の API 用途の意図で使われていない状況を、ビジネス Rails アプリケーションと OSS ライブラリ、フレームワークのいずれにおいても見掛けます。みなさんのプロジェクトではどのように扱っていますか？
今回のトークは、この NotImplementedError の現状にスポットを当てて Ruby City MATSUE でお話しします。NotImplementedError について、廊下会議や「佐香や」での懇親会の肴になれば幸いです。
S.H.です。 『Lightning Talk on Steam Deck with Ruby』というタイトルでLTをします。
内容としてはRubyKaigi 2026でLTをした『Ruby on Bare Metal』で紹介した実装をベースに携帯ゲーム機であるSteamDeck上でRubyを動かすまでの試行錯誤をお話しします。 また当日はSteamDeck上で動くRubyを使い、SteamDeckと付属品のみでLTをする予定です。 元々は「携帯ゲーム機だけで発表ができるといいなぁ」というものぐさな発想から始まった試みですが、結果として得られた「Rubyを別の環境で動かす」という新しい可能性についてもお話ししたいと思います。
LT の時間は 15:25 から 16:25 です。
松江Ruby会議12は面白そうな発表が盛りだくさんです。懇親会付きのチケットは売り切れているようですが、まだ本編参加申し込みは間に合うようです (懇親会チケットを逃した方は2次会で) 。
それでは松江の興雲閣でお会いしましょう。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
FPS (First Person Shooter) が大好きなRubyistことS.H.です。最近はHaloとMarathonをガッツリ遊んでいます。
2026年5月30日(土)に開催される関ケ原Ruby会議01に登壇します。
当日は「Termfront: Ruby標準ライブラリだけで作るFPS」というタイトルで最近作っているターミナル上で遊べるFPSゲームについて発表します。
TermfrontはRubyの標準ライブラリのみを使って疑似3D描画、入力処理、マップ表示などのFPSに必要な要素を実装しているゲームになります。 またTLSで暗号化された通信によるオンライン対戦モードなどもRubyと標準ライブラリだけで実装しています。
発表の中では、制約の多いターミナル環境でどのようにFPSを成立させたのか、その設計の判断や実装の工夫などをお話しします。
またオンライン対戦モードもあるので、当日は壇上の僕と会場のRubyistたちでTermfrontを遊んで"合戦"が出来ればと考えています。
そのため関ケ原Ruby会議01に参加される方はぜひgem install termfrontを事前にしてきてください。
壇上であなたと対戦できるのを楽しみにしています。
株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
2026年5月の Rails / OSS パッチ会を 5月27日(水)に Discord でオンライン開催します。
この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS について、upstream にパッチを送る会です。
会には Ruby と Rails のコミッターで、RubyKaigi のチーフオーガナイザーでもある顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。
開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。
Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です。
先月開催された RubyKaigi 2026 の話題などあると思います。
これからパッチ会に参加してみたいという方、OSS 開発者間の会話に興味があるので聞いてみたいという方もお気軽にどうぞ。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
こんにちは！ アジャイル事業部の @maimux2x です。
2026年4月22日から24日まで北海道函館市で開催された RubyKaigi 2026 に参加してきました。
本記事ではアジャイル事業部から参加したメンバーそれぞれの感想を参加レポートとしてお届けします。
Vladimir Dementyev（palkan）さんによる Ruby でソースコードのロード（require）に介入する標準機構がないことについて、require-hooks という gem で実現するという内容の発表でした。require-hooks には以下の3種類のフックがあります。
around_load : ファイルのロード前後に処理を挟む（ログ、計測）source_transform : ソースコードを書き換えてからロードするhijack_load : ISeq を自分でコンパイルして渡すその中でもhijack_load の話は RubyVM::InstructionSequence#load_iseq という Ruby 2.3.0 のころから存在する API を使って実現されていて、新たな仕組みを作るのではなく既存の仕組みをうまく活用して、Ruby を拡張している点が自分の中ではすごく印象に残っています。
まつもとさんが AI を活用しながら日々の開発を楽しんでいらっしゃる要素がひしひしと伝わってきて、私自身ももっといろいろなものを作りたいという気持ちをもらえたキーノートでした。一方で、私は AI を使いこなすだけの基礎的な知識がまだまだ足りていないため、そういう部分に関しては自分から学びに行ったり、自分でもっと手を動かしながら作るということを続けていきたいと同時に感じました。自分に合った AI の活用を模索しながら、Rubyでの開発をこれからも楽しんでいきたいと思いました。
普段からRubyのドキュメントにお世話になっているので、今回のStanさんお話はとても興味深かったです。 まずRDocのテーマ刷新について。数ヶ月前からモダンで見やすくなったなと感じていたので、その背景を知ることができてスッキリしました。 また、RDoc独自のマークアップ記法からMarkdownへの移行についての話が印象的でした。膨大な既存ドキュメントの置き換えという、人手では困難な作業も、AIを活用して効率化できるというお話には納得感がありました。これまで手間のかかっていた定型的な書き換えが、AIのおかげ楽になったんだなと実感しました。 終盤のllms.txtに関する考察も面白かったです。コーディングエージェントは内部でHTMLをMarkdownに変換しているため、AI専用のファイルを作るメリットよりも、メンテナンスのコストを考えて作らないと判断するのは、重要な視点だと学びになりました。 「人間のためになるものは、結果的にAIのためにもなる」という考え方をされていて、ドキュメント作りに限らず他の場面でも応用できそうに思いました。
これまでの hasumi さんの PicoRuby の発表では、キーボードやマイコン上で Ruby が動く話が面白くて、今回も楽しみにしていました。自分の中では PicoRuby はマイコンのイメージが強かったので、今回はブラウザ、しかもフロントエンドフレームワークの話ということで、どんなふうになるのだろうと思いながら聞きました。 Funicular によってフロントエンドを Ruby で書けるというだけでも楽しいけれど、ブラウザ上の PicoRuby.WASM とキーボード上の PicoRuby がつながるデモを見て、とても興奮しました！キーボードがただの入力装置ではなく、LED による出力装置になり、さらにサーバーとしても動くところが、いろんなものが Ruby で動いて繋がる様子が目にみえて、ワクワクした気持ちになりました。
タイトルから既に面白そうだと思い楽しみにしていたセッションでした。音楽機器であるDJコントローラーをプログラミング用の入力デバイスとして使用し、入力されてくるMIDI規格のメッセージをRubyで処理するという内容なのですが、2つのエディタを同時に操作するなど通常ではできないことが可能になったりしていて興味深く拝見しました。また、終盤にはRactorによる並列処理のデバッグ時に複数ワーカーのログを読むのは大変だからという理由で、それぞれのワーカーのログに音階やドラムの音を割り当てることでログ出力を音楽のようにするというデモをされていて、まさに「その発想は無かった…!!」という気持ちになりました。非常に遊び心にあふれたセッションで、型にはまらずに楽しめばいいんだということを思い出させてくれる内容だったので、強く印象に残っています。
私は tompng さんの BigDecimal の高速化の発表が印象に残りました。途中から「数式をどう実装するか」ではなく、「数や式をどう見るか」の話になっていくのが興味深かったです。
特に、
exp(1.111111111111...)
をそのまま計算するのではなく、
exp(1) * exp(0.1) * exp(0.011) * exp(0.0001111) * ...
のように分割していたのが印象的でした。 「値」としてではなく、「分解可能な構造」として数を扱っている感じがして面白かったです。
また、
((((((1×2)×3)×4)×5)×6)×7)×8...
と
((1×2)×(3×4))×((5×6)×(7×8))...
は数学的には同じでも、計算構造を変えるだけで性能が大きく変わる、という話も印象に残りました。
最初の「宇宙規模の桁数を計算したい」というロマンっぽい導入から、最後まで “Digits, Digits, and Digits” な発表で楽しかったです。
makenowjust さんによる、Ruby の正規表現エンジンを作り直すという発表でした。
当初は YJIT / ZJIT を活かして Onigmo のパーサや文字クラスを Ruby API として公開し、マッチング部分を Ruby で書き直す、という提案だったそうですが、Ruby の正規表現の前処理を深掘りしていくと、正規表現リテラル/.../ と Regexp.new で経由する処理が違っていたり、Prism と parse.y でも挙動が分かれていたりと、想像以上にカオスな実態が明らかになっていきます。
そこから話は「Onigmo ごと作り直そう」という Project Naraku の構想に発展していくのですが、前処理の複雑さという課題に対して、部分的な改善ではなくエンジンそのものを作り直すという思い切った構想に強く惹かれました。
普段なにげなく書いている正規表現の裏側にこれだけの世界が広がっていて、それを引き受けて作り直そうとしている方がいるということに、Ruby コミュニティの厚みを感じたセッションでした。
今年はじめに ydah さんが Lrama に PSLR を機能追加する PR を投げたことで界隈に激震が走ったのは記憶に新しく、これに関して発表するのは間違いないと思っていました。個人的には、昨年の自分の発表と同じようなふるまいや構造にスポットを当てた発表になるのかなと思っていたのですがそうではなく、PSLR を使うと parse.y のどの部分についてどのように改善することができるかに全部振り切った発表で、とてもおもしろかったです。
lex_state を使われ方や成り立ちから6つのカテゴリに分け、それぞれ例を挙げながら PSLR ではこのように解消できるとわかりやすく説明されていました。中には最初から lex_state を使う必要のなかったものも含まれていたそうで、悪魔城あな恐ろしや。layer 6 は PSLR を導入しても原理的に解決できなかったものを指していますが、発表後に聞いたところこれが意外と多いそうで、導入したからバシッと解決といかないあたりも悪魔城あな恐ろしや。ただ、「lex_state とは何なのか」という問題に1つの光明が見えたという点で、この業績は素晴らしいと思います。
メンバーそれぞれの視点で RubyKaigi 2026 を満喫することができました！スピーカーの皆様、オーガナイザー、スタッフの皆様、今年も素敵な RubyKaigi をありがとうございました！ 来年の宮崎もとても楽しみです！
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
