Groongaのパトリシアトライについてちょっとわかってきたつもりの阿部です。

ちょっと前に意気揚々とパトリシアトライのキーをデフラグする機能を追加したことを紹介したのですが、その機能にバグがありました。かなしい。

本記事ではどのようなバグがあってどのように修正したのかを紹介します。

バグの説明をするためにパトリシアトライのレコード削除やレコードの再利用について知っておく必要があるので、はじめにその辺の説明をします。

（前の記事の続編な内容なので、前回の記事を読んでから本記事を読んでもらえるとうれしいです。）

Groongaの開発に参加している須藤です。14.1.3で並列オフラインインデックス構築機能を実装したので実装内容を紹介します。

こんにちは。 OSS Gateのワークショップの企画・実施をここ数年担当している福田です。

2025年2月1日に開催されたBuriKaigi 2025において、OSS Gateの取り組みについて発表（LT）しました。 LTでは次のような話をしました。

OSS（オープンソース・ソフトウェア）の開発に参加したことはありますか？ それはハードルが高いな、と思ったそこのあなた、実は少しコツをつかめば誰でも気軽に参加できるんです！ OSS開発に興味がある方、世界を広げたい方、社員教育の題材をお探しの方などに、OSS Gateという面白い取り組みがあることを知っていただき、今後活用していただきたいです！

本記事では、このトークで伝えたい要点を紹介します！ 合わせて、BuriKaigi 2025の様子も紹介します！

COPYのフォーマットを拡張できるようにするためのPostgreSQLにパッチを送っている須藤です。本命のパッチはまだマージされていないのですが、マージされやすくなるといいなぁと思って関連するコードのパッチを書いたり、他の人のパッチをレビューしたりしていたらPostgreSQL 17 Contributor Giftをもらいました。

FirefoxやThunderbird、Chromium系ブラウザーなどの拡張機能では、Native Messagingという仕組みを使って、通常のAPIの範囲では行えないローカルファイルへの直接のアクセスなどを行えます。これは、ブラウザーが拡張機能からの求めに応じて「Native Messaging Host（以下NMH）」と呼ばれる特殊なネイティブアプリケーションを呼び出すことによって実現されます。

NMHはどのような言語で開発しても問題ありません¹が、拡張機能がマルチプラットフォームで利用され得ることと、NMHは標準入出力を使う非GUIアプリケーションとして実装すればよいことから、当社では、単一ソースからマルチプラットフォームな実行ファイルを容易にクロスビルドできるGo言語（golang）を用いる場合が多いです。本記事では、このような前提で開発されたもののそれまで自動テストがなかったgolang製NMHに、後付けで自動テストを作る際の注意点を紹介します。

こんにちは。データ収集ツールFluentdのメンテナーの福田です。

今回の記事では、有名なWebサーバーアプリケーションであるnginxの最大接続数のチューニングについて調査した事例を紹介します。

最大接続数をチューニングするにあたり、reuseport設定とファイルディスクリプター数上限(worker_rlimit_nofile)を考慮する必要がある、という点が重要です。

この調査はクリアコードのFluentd法人様向けサポートサービスの一貫で実施したもので、 Fluentdとセットで周辺のフリーソフトウェアのサポートを実施した事例となっています。

nginxなどのwebサーバーの性能チューニングや、クリアコードの法人様向けサポートサービスに興味のある方は、ぜひ本記事をご覧ください。

Apache Arrowの開発に参加している須藤です。19.0.0がリリースされたので紹介します。

fat gemを簡単に作れるようにするgemであるrake-compilerをメンテナンスしている須藤です。2019年にもfat gemをやめる話をしていましたが、5-6年経ってもまだfat gemが使われているので、この5-6年でのアップデートを紹介します。

Mroongaのメンテナンスもしている堀本です。 今回はGitHub Actions上でAlmaLinuxの仮想マシンを作って何かする人向けの記事です。

Groongaとその関連プロダクト（PGroongaやMroongaなど）は、様々なOS向けにパッケージを提供しています。 提供するパッケージはGitHub Actions上でビルドしたり、テストしたりしています。 今回は、AlmaLinux向けのパッケージのテストをする環境を作る時に躓いた点があったので、その回避策を紹介しようと思います。

GitHubを利用して様々なプロジェクトに関わっている場合、関連するissueを一覧で確認できると便利な場合があります。 Notificationsのフィルタを活用すればある程度一覧性を担保できますが、その結果を複数人で共有、加工等したい場合には不向きです。 GitHub ProjectsではOrganization配下に作成されたリポジトリのissueを任意で追加できるので、トリアージが必要なissueを登録しておくと一覧できて有用です。

クリアコードではFluentdの開発にも深く関わっていることから、Fluentdのサポートサービスを提供しています。 Fluentdにはプラグインのエコシステムがありますが、関連するリポジトリはあちこちに分散しています。 それらのリポジトリで新規に起票されたissueをGitHub Projectsで一覧できると有用なのですが、そのようなしくみは整えられていませんでした。

そこで、GitHub ProjectsにOrganizationを横断して既存のissueを集約し、Fluentd Kanbanとしてトラッキングしやすくした方法について紹介します。