結城です。Firefox 149での開発者向けの変更点情報に記載されたトピックの1つに、拡張機能内のリソース（URLがmoz-extension://～となる物）を読み込んだタブへのスクリプトの動的な注入操作の廃止があります。この変更は現在は開発版でのみ有効化されており、Firefox 152以降でリリース版でも有効化される旨が決定しています。今のところは隠し設定を切り替えれば従来の動作に戻せます1が、いずれはこの隠し設定も廃止されて、拡張機能内のリソースに対してはスクリプトの動的な注入操作が恒久的に不可能になるはずです。筆者が開発している拡張機能「Tree Style Tab（TST）」や、そこで使用しているライブラリーを共用している当社製の他の拡張機能でも、一部の機能が動かなくなる影響が出ていたため、この2ヵ月ほどの間に対応のための改修を行いました。この記事では、「そもそも、それらの拡張機能ではなぜスクリプトの動的な注入を行っていたのか」「なぜスクリプトの動的な注入が禁止されるようになったのか」「変化に拡張機能側でどのように対応したのか」を解説します。そもそも、なぜスクリプトの動的な注入を行っていたのか通常、スクリプトの動的な注入・実行機能は、いわゆるユーザースクリプト機能を実現したり、一般のWebページの内容を拡張機能が変更したり、拡張機能が提供する独自のUIをWebページ内に埋め込んだりするために使われます。ただ、拡張機能のパッケージ内に含めたHTMLファイル（moz-extension://で始まるURLが自動的に割り当てられる）からは、わざわざ動的に注入しなくても、普通に<script>を使ってパッケージ内のJavaScriptファイルを読み込めます。拡張機能で独自のUIをウィンドウやタブの形で提供する場合は、そうしてスクリプトを読み込むように記述したHTMLファイルのURLをtabs.create()やtabs.update()、windows.create()などに指定して開くだけで済みます。つまり、ウィンドウやタブで独自のUIを提供する際に「ウィンドウやタブを開いて、後からスクリプトを動的に注入する」という操作は、普通、する必要がありません。それにも関わらずTSTや当社製の拡張機能が敢えてスクリプトの注入という手法を用いていたのは、それが拡張機能の

RubyKaigi 2026でPure Ruby Apache Arrow reader/writerという話をした須藤です。なお、クリアコードはシルバースポンサーとしてRubyKaigi 2026を応援しました。また、アンドパッドさんが開催するコード懇親会のお手伝いもしました。 Pure Ruby Apache Arrow reader/writer 関連リンク：スライド（Rabbit Slide Show）リポジトリー内容Apache Arrowフォーマットを読み書きできるpure Rubyライブラリーを作ったので、そこで得られたpure Rubyでバイナリーファイルを高速に読み書きするための知見を共有しました。また、既存のRubyの機能では足りない部分もまとめました。今後はこのあたりに興味がある人たちとRuby本体を改良していきたいです。事前情報の方にもっと詳しく書いているのでそちらも読んでみてください。改良項目案：高速な組み込みのビット操作ビット操作はFeature #20163 - Introduce #bit_count method on Integerなど、なんどか提案されていますが、まだ実現されていません。Integerのメソッドとして提案されていますが、Integerはimmutableなので破壊的な変更をできないことが懸念点の1つになっています。RubyKaigi 2026中にまつもとさんや田中さんに聞いてみた感じでは、IntegerではなくStringの機能として提案するとワンチャンあるかも？という気持ちになりました。PicoRubyのためにこのあたりが強化されて欲しいということで、はすみさんが取り組んでくれそうです。（私もお手伝いするつもりです。）なお、この話題はRuby Committers and the Worldでもでていました。そして、おそらくそれを受けてIO::Buffer#bit_countが追加されていました。それはそうと、IO::Bufferからexperimentalを取るためには全体的に実装を確認してコーナーケースも含めて品質を上げる必要がありそうです。あとでやろうかなぁという気持ちになりました。io::buffer#get_string">改良項目案：ゼロコピーなIO::Buffer#get_stringIO::Bu

RubyKaigi 2026でPure Ruby Apache Arrow reader/writerという話をする須藤です。RubyKaigi 2026での私の話をより理解できるようになるために簡単に内容を紹介します。なお、クリアコードはシルバースポンサーとしてRubyKaigi 2026を応援しています。また、アンドパッドさんが開催するコード懇親会のお手伝いもします。 Pure Ruby Apache Arrow reader/writer 関連リンク：スライド（Rabbit Slide Show）リポジトリー背景私はRubyが好きなのでデータ処理をするときもできるだけRubyを使いたいです。そのためにはRuby用のデータ処理ツールが必要です。ということで、Ruby用のデータ処理ツールを整備するプロジェクトRed Data Toolsを始めました。2016年ころの話です。Red Data Toolsはいろいろ便利なデータ処理ツールを提供してきました。よくあるデータセットを共通のAPIでダウンロードできるRed Datasets、可視化ツールCharty、データ処理プラットフォームApache ArrowのRubyバインディングRed Arrowたち、Red ArrowベースのデータフレームRedAmberなどです。ここにRubyだけで実装されたApache Arrow読み書きライブラリーが増えました。それが今回の話になります。モチベーションApache Arrowのかなり初期の頃からRubyでApache Arrowを使える状態にしてきました。Apache Arrowのコミッターになって公式のRubyバインディングを開発したのです。Apache Arrowは特定のプログラミング言語に依存せずに効率よくデータ交換できるデータフォーマットです。私がApache Arrowに関わりだした頃は、データ処理システム内の各種データ処理モジュールがApache Arrowを介して協調する未来を目指していました。そのシステムでは各種データ処理モジュールは様々なプログラミング言語で実装されています。それでもApache Arrowを使うことでそれらのモジュールは効率よく協調できるのです。RubyからもApache Arrowを使うことができれば、データ処理モジュールを実装するプロ

2026年3月27日にLTS版 Fluent Package v6.0.3をリリースしました。本記事では、Fluent Package v6.0.3の変更内容を紹介します。Fluent Package v6.0.3Fluent Package v6.0.3 では、以下の対応を行いました。内部ライブラリ cool.io v1.9.3 で発生した特定条件下での深刻なメモリリークの解消Rubyのバージョンを 3.4.9 にアップデートしました脆弱性対応のため同梱の Nokogiri (Windows版のみ) を更新変更内容の詳細内部ライブラリ cool.io v1.9.3 で発生した特定条件下での深刻なメモリリークの解消Fluent Package v6.0.2 に同梱の cool.io v1.9.3 において、メモリ使用量が継続的に増加し続ける不具合が確認されておりました。本リリースでは、この問題を解消しています。影響を受ける環境TCP コネクションの接続と切断が高頻度で繰り返される環境下においてメモリリークが発生します。とりわけ out_forward プラグインを、 keepalive false（デフォルト値）で運用している環境でメモリリークが容易に発生します。原因Fluent Package が非同期I/O処理に利用している内部ライブラリ cool.io v1.9.2 および v1.9.3 に不具合が存在していました。Fluent Package v6.0.2 は cool.io v1.9.3 を同梱しています。TCP コネクションを切断する際、内部の監視オブジェクトを解放する処理がスキップされてしまい、メモリ上に不要なデータ（ゴミ）が蓄積し続ける状態となっていました。対応不具合を修正した cool.io v1.9.4 をリリースし、Fluent Package v6.0.3 に標準同梱しました。長期間稼働させた場合、システム全体のメモリリソースを圧迫し、OOM (Out of Memory) Killer 等によってプロセスが予期せず終了するリスクがあります。out_forward をご利用中で、v6.0.2 へアップデート済みのユーザーの皆様におかれましては、本バージョンへの速やかなアップデートを強く推奨いたします。※ なお、Fluent Package v

Fluentdの公式サイトは www.fluentd.org ですが、2026年2月20日にそれまでサイトをホスティングしていたHerokuから、Netlifyへと移行しました。サイトのコンテンツの見栄えにほぼ影響ないように作業をすすめたので、移転していることに気づかなかった人も多いと思います。今回は移行の背景等を記録として紹介します。公式サイトの移転のきっかけそもそもは、公式サイトを移転するという話ではなく、GitHubのissueで https://fluentd.org へとアクセスできないという報告があったことからはじまりました。www needed to access to websitewww.fluentd.org にしか普段アクセスしていなかったため気づいていなかったのですが、https://fluentd.org にブラウザでアクセスできない状態になっていました。http://fluentd.org にアクセスすると、 https://www.fluentd.org へリダイレクトするように設定されていましたが、https://fluentd.org にアクセスすると証明書のエラーが発生するようになっていました。https://www.fluentd.org については、https://github.com/fluent/fluentd-website のmasterブランチへのpushをトリガーとしてHerokuにデプロイしていることは把握していましたが、http://fluentd.org や https://fluentd.org にアクセスしたときにどう管理されているのかについては当時把握できていませんでした。そのあたりを関係者に確認していく必要がありました。関係者からの聞き取りでわかったこともともと fluentd.org のドメインはFluentdの開発元であったTreasure Data, Inc.さん（以下TDさん）が保持していたという経緯があります。そのため fluentd.org のリダイレクト設定についてどうなっているか確認してみたところ、TDさんではそのあたりを把握していない状況であることがわかりました。そこで、CNCFのフロントデスクに問い合わせした結果、次のような状態であることがわかりました。fluentd.org はC

RubyKaigi 2026の2日目の夜にアンドパッドさんが開催するコード懇親会のお手伝いをする須藤です。2026年4月6日の10:00から参加登録できるので、「コードで懇親？楽しそう！」と思うRubyKaigi 2026参加者は登録してね。コード懇親会とはコード懇親会はRubyKaigi 2018のときに私が思いついた懇親会のスタイルです。普通の懇親会とはちょっと違うコンセプトの懇親会です。普通の懇親会は飲食物が用意された状態で各参加者がそれぞれ違う参加者と話をして懇親します。ちょっとしたトークや催し物が用意されることもあります。コード懇親会はその名の通りコードを軸に懇親します。一緒にコードを書いたり、一緒にコードを読んだり、どうしてこんなコードになっているのかみんなで考えたり作者に聞いたり。そんな感じで懇親します。そんなことをして楽しい時間になるの？って思いますよね。楽しい時間になるはず！特にRubyistなら！Rubyは楽しくプログラミングできるように設計されたプログラミング言語です。だったら一緒にRubyでコードを読み書きする時間も楽しい時間になるはずだよね。そういうコンセプトです。とは言っても、やっぱり人によると思います。「一緒にコードを読み書きする」と聞いて「楽しそう！」と感じる人はコード懇親会を楽しめるでしょう。一方、「？」と思う人はそうでもない可能性が高そうです。そんな人は、自分が楽しめそうな他のイベントを選んで参加してください。おそらく https://rubykaigi.org/2026/events/ にイベントリストが公開されるはずなので、そこで自分が楽しめそうなイベントがきっと見つかるはずです。（でも、言葉では理解できなかったけど体験したら理解できた！となる人もいる気はするので体験して自分は楽しめるかどうか確認して欲しいとは思っています。）なお、他のドリンクアップ系イベントと違ってお酒はありません。RubyKaigi 2026では毎晩お酒を飲みたい！という人は別のイベントの方が向いています。あるいは、コード懇親会が終わった後に一杯やりに行ってください。21:15に終了予定です。過去のコード懇親会情報言葉での説明だけではイメージがつかない人向けに過去のコード懇親会の様子がわかる情報をおいておきます。参考にしてください。コード懇親会は過去にRu

RRDといえばRRDtoolの阿部です。最初に使ったときはMRTGよりきれいで感動したものです。そして、今回もRRDなるものが登場しますが、RRDtoolとは無関係です。今回のRRDはRerunというプラットフォームに関係するものです。RerunはPhysical AI（ロボットとか）のデータをいい感じに記録して、いい感じに可視化するプラットフォームです。そこで使われるファイルのフォーマットがRRDと呼ばれています。Rerunとは？あたりの説明から入り、RRDファイルを作成し、可視化をして、Rerunを試してみるのが本記事です。Rerunとは？冒頭にも書いた通りですが、とても簡単に説明すると「Physical AI（ロボットとか）のデータをいい感じに記録して、いい感じに可視化するプラットフォーム」です。「いい感じに記録」とはどういうことか、AIがよしなに判断してロボットアームが自動で何かつかむ場面を例に説明します。ロボットアームが自動で何かをつかむためには、周りの状況を把握する必要があります。ということで、カメラも必要です。それを踏まえてつかむまでの流れはおおまかに次のとおりです。カメラで周囲を把握し、対象物の位置を特定するその位置に向けてアームを動かすアームが動くにつれて対象物との距離が変わるので、カメラの情報を元に位置を補正する対象物に到達したらつかむ個別に事象が起こるような書き方をしましたが、実際にはアームを動かすこととカメラ情報の解析はほぼ同時に行われています。つまり、データを記録する場合はある瞬間のアームの状態とカメラの状態を同時に記録する必要があります。「アームの状態」と一言で書きましたが、アームには関節があり、肩・肘・手首・手のそれぞれにモーターがついています。なので、複数のモーターの状態を記録する必要があります。さらにモーターごとに「どの角度にあるか」「どのくらいの速さで動いているか」「どのくらいの力を出しているか」といった情報があります。まとめると、ある瞬間の複数のモーターの状態どの角度にあるかどのくらいの速さで動いているかどのくらいの力を出しているかカメラの画像（説明を割愛しましたが、多くの場合、カメラも複数台あります）を記録する必要があります。これらは時系列に発生するので、ある瞬間の複数のデータを時刻をそろえて記録しなければなりません。また、数

Windows環境で開発をしている橋田です。パスワード付きのプロキシーを設定していると、ネットワークアクセスの際にプロキシーの認証情報（ユーザー名/パスワード）を求められます。Microsoft EdgeとGoogle Chromeを利用しているお客様から、ブラウザ使用中にプロキシーの認証情報入力ダイアログが表示された際に、認証情報を自動で入力したいという要望をいただきました。今回、この要望に応えるため、WindowsのUIオートメーションツールを使用して、Microsoft EdgeとGoogle Chromeのプロキシーの認証情報入力ダイアログに認証情報を自動で入力するツールを開発しました。開発したツールはProxyDialogAutoFillerという名前でOSSとして公開しています。この開発事例を元に、WindowsのUIオートメーションツールの基本的な使い方を紹介します。既存のプロキシーの認証情報（ユーザー名・パスワード）の自動入力ツールとの比較ChromeにはProxy Helperといったプロキシーのユーザー名/パスワードを自動入力する機能を搭載した拡張機能（アドオン）があります。しかし、拡張機能だけでは自動で入力できないタイミングが存在し1、取りこぼしが発生し得ます。このような取りこぼしを回避するため、今回はWindowsのUIオートメーションツールを使用して、ブラウザの外部からブラウザ上に表示されるプロキシーの認証情報入力ダイアログを監視する仕組みとしました。基本的な動作基本的な動作として、まずProxyDialogAutoFiller（今回開発したツール）が常駐し、EdgeまたはChromeのプロセスが起動しているかどうか監視します。EdgeまたはChromeのプロセスが起動している場合、UIオートメーションツールを使用して、そのプロセス上にプロキシーの認証情報入力ダイアログが表示されているかどうかを判定します。プロセス上にプロキシーの認証情報入力ダイアログが表示されていた場合、UIオートメーションツールを使用して、保持しているユーザー名/パスワードをダイアログに入力します。より詳しい動作の説明については、ProxyDialogAutoFillerのドキュメントに記載されているため、そちらを参照してください。UIオートメーションの使い方以下、今回

Outlookのアドインの開発をしている橋田です。クリアコードではTypicalReplyという、以下のような機能を提供するOutlookアドインを提供しています。受信したメールに定型の内容の返信メールを作成するボタンを追加する例: 「通報」ボタンを押すと以下の内容の返信メールを作成する件名: 迷惑メールの通報宛先: 社内のシステム管理部門元のメールを添付ボタンの設定を組織単位で集中管理するTypicalReplyはVSTOというフレームワーク上で開発されていました。VSTOアドインはクラシックOutlookでのみ動作し、新しいOutlookでは動作しません。今回、お客様から新しいOutlookでもTypicalReplyを使用したいという要望を頂き、新しいOutlookでも動作するTypicalReplyを新規開発しました。新しいOutlookで動作するアドインを作成するためには、Officeアドインプラットフォームでアドインを作成する必要があります。今回は、この開発事例を元に、OfficeアドインでのOutlookのアドイン開発の流れを紹介します。背景: OutlookのアドインについてOutlook向けのアドインの開発の背景として、2026年現在のOutlookおよびOutlookのアドインの状況について説明します。Outlookの種類現在、Windows向けのOutlookにはクラシックOutlook、新しいOutlookの二種類が存在します。また、Web上で使用可能なOutlookとしてOutlook on the webが存在します。クラシックOutlook: Windowsアプリケーションとして開発されていた従来のOutlookクライアントです。新しいOutlook: Webベースで開発された新しいOutlookクライアントです。Outlook on the web: ブラウザ上で動作するWebベースのOutlookクライアントです。Microsoft社はクラシックOutlookから新しいOutlookへの移行を進めており、2029年にクラシックOutlookはサポート外となる予定です。参考情報:https://learn.microsoft.com/ja-jp/microsoft-365-apps/outlook/get-started/guide-

結城です。当社が受託開発を行う際には、なるべく「筋が良い」設計でソフトウェアを実装したり、仕様に問題がある場合は「筋が良い」仕様になるようご提案したりといった要領で、可能な限り技術的に「筋が良い」解決方法を取るように努めています。技術的な制約によって理想的な解決の仕方ができない場合でも、当社では様々な可能性を探り、ご相談を頂いた時点では想定されていなかった方法で問題を解決します。本記事で取り扱うEdge拡張機能の開発事例も、その一つです。本事例では、「Webブラウザー・Edgeの仕様にない挙動を実現したい」という、通常であれば技術的に不可能と思われるご要望を、その背景にあった事情まで遡ってヒアリングして、無事解決まで導くことができました。この記事では、当社が本事例でどのように問題を解きほぐして解決したのかをご紹介したいと思います。頂いたご相談お客様から頂いたお問い合わせは、要点をまとめると「Edgeのコンテキストメニューの『最新の情報に更新（リロード）』『印刷』や、キーボードショートカットの『F5』『Ctrl-R』『Ctrl-P』を無効化したい」というものでした。こちらのお客様とはFirefoxのカスタマイズ案件で既にお取引があり、Firefoxでは特定のキーボードショートカットやメニュー項目をピンポイントで無効化するカスタマイズが可能だったことから、同様のカスタマイズをEdgeで行えないか、ということでお問い合わせを頂いたと考えられます。しかしながら、ChromiumベースのブラウザーであるEdgeは、あらかじめ隠し設定やグループポリシーで制御可能なように実装されている機能以外は、任意で無効化することができません。当社で技術資料を調査した限りでは、Edgeでは印刷操作は無効化できるものの、リロード操作を無効化する設定は用意されていない様子でした。キーボードショートカットについては機能ごとに無効化できるようですが、メニュー項目の方が利用可能なままだと、機能の無効化としては不充分です。このような場合、機能の入口である「メニュー項目」や「キーボードショートカット」を無効化する代わりに、機能の出口である「ページの再読み込み」や「印刷」の部分に介入して、「ページの再読み込みに特有の読み込みパターンを検知してブロックする」「印刷ダイアログが表示されたことを検知して、それを強制

2026年2月27日にLTS版 Fluent Package v6.0.2をリリースしました。本記事では、Fluent Package v6.0.2の変更内容を紹介します。Fluent Package v6.0.2Fluent Package v6.0.2では、以下の改善を行いました。Rubyのバージョンを3.4.8にアップデートしました同梱のFluentdをv1.19.1からv1.19.2に更新しましたrpm: tmpfiles.dによってFluentdの一時ディレクトリーが消去されてしまった状態ではアップデートに失敗する問題を修正しましたmsi: インストールがエラーで中断してしまうことがある不具合を修正しましたこの記事では、Fluent Package v6.0.2の主な変更点を詳しく解説します。変更内容の詳細Rubyのバージョンを3.4.8にアップデートRuby 3.4.8には複数のバグと脆弱性の修正が含まれています。詳細はRuby 3.4.8 リリースノート をご覧ください。同梱のFluentdをv1.19.1からv1.19.2に更新Fluentd v1.19.2では以下の修正が含まれています。設定ファイルの自動読み込みによってエラーが発生しないようにしましたin_tailで読み取り権限のないファイルを読み込ませようとしたときのエラーを修正しましたout_forward利用時に不安定なネットワーク環境下で無限ループが発生しないように修正しましたgem: IPv6アドレスのエラーを解消するため最新のnet-httpを使うようにしましたバックアップ設定ファイルが読み込まれていそうな場合に警告できるようにしました詳細については、Fluentd v1.19.2 をリリースで説明しているのでそちらを参照してください。rpm: tmpfiles.dによってFluentdの一時ディレクトリーが消去されてしまった状態でアップデートに失敗する問題を修正tmpfiles.dによって一時ディレクトリが削除されている状態で、fluent-package v6.0.0もしくはv6.0.1へアップデートしようとすると、失敗する問題があったのを修正しました。v6.0.0から入った処理に問題があったためで、更新前のバージョンに関係なく発生していました。これからFluent Package

RubyKaigi 2026の2日目の夜にアンドパッドさんが開催するコード懇親会のお手伝いをする須藤です。去年に引き続き、今年もアンドパッドさんがコード懇親会を開催してくれる予定です。去年はいくつかのテーマを事前に用意してみたのですが、よさそうな感じだったので今年も事前にテーマを用意する予定です。今年は、運営側が用意したテーマだけではなく、参加予定者から公募したテーマも1つか2つ混ぜてどうなるか試してみたいです。ということで、この記事はそのお知らせです。コード懇親会とはコード懇親会は「コードで懇親しよう！」というコンセプトのイベントです。Rubyはプログラマーの楽しさが大事なことの1つです。Rubyでプログラミングすると楽しいなら、Rubyistは（お酒とかじゃなくて）コードを中心に据えても楽しく懇親できるんじゃない！？というアイディアです。テーマコード懇親会ではテーマごとにグループを作って懇親します。たとえば、去年のテーマは以下のとおりでした。dRubyMRI (Matz Ruby Interpreter, CRuby)TRICK, Reline and IRBRubyGems/BundlerRed Data ToolsmrubyRDocOSS contributionこのうち、dRubyからmrubyまでが事前に決めたテーマで最後の2つがその場で参加者の興味を決めたテーマでした。以前はすべてその場で参加者の興味を聞いて決めていましたが、去年はいくつか事前にテーマを決めました。テーマを事前に決めることとその場で決めることで大きな違いは準備ができるかどうかです。たとえば、dRubyテーマでは既存のワークショップ資料をもとにしたアップデート版の資料を用意してそれを使っていました。事前に用意したテーマすべてで準備していたわけではありませんが、必要であれば事前に準備できるというのが違いになります。事前準備なしで、はじめましての人たちと最初はたどたどしいながらも徐々にコードを通じて懇親していくスタイルもそれはそれで面白い体験（たとえば、RubyKaigi 2024でのコード懇親会の石川さんの感想など）だと思いますが、事前準備ありならではの面白い体験もありそうです。ということで、RubyKaigi 2026でのコード懇親会でも事前にいくつかテーマを用意します！今回のテーマすで

OSS開発に参加する人を継続的に増やしていくプロジェクトOSS Gateをやっている須藤です。2026-02-13（金）にOSS Gateワークショップを東京でオフライン開催しました！会場はオプティムさんが提供してくれました！懇親会ではオプティムさんが作っているスマート米を無料で提供してもらいました。カレーライスにして食べました。おいしかったです！お米がおいしすぎてカレーの方が余ってしまいました。参加者数：22人！新型コロナウィルス以降、OSS Gateワークショップは主にオンラインで開催していたのですが、約1年ぶりにオフラインで開催することになりました。せっかくオフラインで開催するならできるだけ多くの人と一緒にやりたいと思って今回はいつもよりも告知をがんばりました。その結果、いつもは多くても10人くらいだったのに今回は22人も参加してくれました。しかも、参加登録者のうち欠席した人は1人だけでした。これまでになんどもイベントを開催してきましたが、こんなに欠席率が低いことは非常に稀です。数割の人が（連絡なく）欠席することばかりだったので非常に驚いています。もしかしたら、平日の日中に開催したからかもしれません。欠席が多いイベントは平日の夜や休日のイベントでした。イベント開催前は「平日日中で集まる？大丈夫？」という懸念もあったのですが、会場提供のオプティムさんが社内でたくさん参加者を募ってくれたり、いろいろな人に告知を手伝ってもらったりしたら20人超の参加者になりました。1/3くらいがオプティムの方でした。会場提供してくれたオプティムさんには優先的に参加してもらいたくて最初の方は告知先を絞っていました。ある程度オプティムさんからの参加者が出揃った段階で、個別に声をかけて告知を手伝ってもらいました。手伝ってくれたみなさんありがとうございます！また、@yasulabさんにはRailsガイドのコミュニティ支援の一環としてRailsガイド内で告知してもらいました。Railsガイドに協賛すると同じようにRailsガイド内で告知できるので、Railsユーザーにリーチしたい人は検討してみてください。さらに、ワークショップの様子も撮影してもらいました。実は、OSS GateのYouTubeチャンネルがあって、9年前にクラウドワークスさんに会場提供してもらったときのOSS Gateワークシ

2026年2月13日にFluentdの最新版となるv1.19.2をリリースしました。v1.19系のメンテナンスリリースとなっており、fluent-package の次期LTS版であるv6.0.2に同梱される予定です。本記事では、公式サイトで公開している情報を日本語で解説します。主な改善Fluentd v1.19.2では、いくつかの不具合を修正しました。設定ファイルの自動読み込みによってエラーが発生しないようにしましたin_tailで読み取り権限のないファイルを読み込ませようとしたときのエラーを修正しましたout_forwardで不安定なネットワーク環境下で無限ループが発生しないように修正しましたgem: IPv6アドレスのエラーを解消するため最新のnet-httpを使うようにしましたバックアップ設定ファイルが読み込まれていそうな場合に警告するようにしました以下、それぞれ解説します。設定ファイルの自動読み込みによってエラーが発生しないようにしましたFluentd v1.19.0から、特定のプラグインを組み込みで有効にできるようにする機能を搭載しました。しかし、これには副作用があり、/etc/fluent/conf.dを自動で読み込むようにしたことにより、従来該当ディレクトリ配下に設定ファイルを配置していた場合には重複して読み込んでしまっていました。これにより、Fluentd起動時にエラーが発生していました。従来の設定ファイルを変更せずそのまま使い続けたい場合には、次のようにconfig_include_dirを明示的に無効化して回避する必要がありました。<system> config_include_dir ""</system>今回のリリースでは、そのような利用条件でも起動時の設定読み込みでエラーが発生しないよう修正しました。in_tailで読み取り権限のないファイルを読み込ませようとしたときのエラーを修正しました">in_tailで読み取り権限のないファイルを読み込ませようとしたときのエラーを修正しましたLinuxのCapabilityを有効にしてログを読み込むようにしていた場合、未初期化の変数にアクセスしようとしてエラーが発生するケースがありました。今回のリリースでは、そのような場合でもエラーが発生しないように修正しています。out_forwardで不安定なネッ

Groongaの開発とサポートをしている堀本です。今年も年に一度の肉の日（2月9日のこと）が来ました。例年通り、Groongaをメジャーバージョンアップしたので、この一年でどのくらいGroongaがよくなったかを紹介します！メジャーバージョンアップなのですが、特に非互換の変更を入れていないので、いつもどおり既存のデータベースを移行せずにGroongaをアップグレードできます。GroongaGroongaは今回のメジャーバージョンアップで16.0.0になりました。前回のメジャーバージョンアップからの目玉機能は以下の通りです。セマンティックサーチのサポート踊り字の正規化対応TABLE_PAT_KEYのテーブルの最大合計キーサイズを拡張grndb checkの改良それぞれ簡単に紹介します。セマンティックサーチのサポート最近では、LLM（大規模言語モデル）を使って、検索キーワードの字面ではなく、意味に基づいた検索ができる検索エンジンが増えています。Groongaでも、LLMを使った意味ベースの検索ができるようになりました。検索の精度は使用するLLMの精度に大きく依存しますが、従来のキーワード検索と併用してより有用な検索結果を得られるケースがあります。この機能については、 PostgreSQL Conference Japan 2025でも発表してきたので、 PostgreSQL Conference Japan 2025：PostgreSQLでのセマンティックサーチへの挑戦 #pgcon25j の記事も合わせて参照してください。踊り字の正規化対応日本語には踊り字という前の文字を繰り返す記号があります。例えば、「久々」の「々」や「こゝろ」の「ゝ」が踊り字です。これらの踊り字の有無を無視して検索できるようになりました。つまり、「こころ」で「こゝろ」と「こころ」がヒットするようになります。この機能についても、 PGroongaで踊り字の有無を無視して検索する方法 に詳細がありますので、合わせて参照してください。table_pat_keyのテーブルの最大合計キーサイズを拡張">TABLE_PAT_KEYのテーブルの最大合計キーサイズを拡張非常に大きなデータも扱えるGroongaですが、制限もあります。その中の一つに、最大の合計キーサイズの制限があります。今回はこの最大の合計キーサイ