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としてトラッキングしやすくした方法について紹介します。

クロスプラットフォームで動作し、オープンソースであるデータ収集ソフトウェアとしてFluentdがあります。 Fluentdはさまざまな用途にあわせてプラグインにより機能を拡張できます。 多くのプラグインが開発されているのは、要件を満たすべく新規にプラグインが開発される事例があるためです。

Fluentdで収集したログは、Fluentd内部ではイベントという形で処理されます。 イベントはタグと日時、レコードから構成され、収集されたデータはレコードに詰め込まれます。

発生したログをアーカイブ目的のため手を加えずになんらかの外部サービスに保存するだけということもありますが、 レコードに詰め込まれたデータの加工が必要となる場合が多々あります。

Fluentdでは非常に多くのプラグインが開発されてきているので、レコードを分割するという目的だけでも専用のものがいくつかあります。 今回はそのようなプラグインの中から、Fluentdサポートの一環として、お客様の要望に応じて新規でプラグインを開発した事例を紹介します。