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サポートの一環として、お客様の要望に応じて新規でプラグインを開発した事例を紹介します。

RubyとApache Arrowの開発に参加している須藤です。RubyのMemoryViewの使い方がわからないという話を聞いてsumをするサンプルを作ったので紹介します。

こんにちは。Fluentdのメンテナーの福田です。

2024年12月14日にリリースした Fluent Package v5.2.0 では、ゼロダウンタイム・リスタートおよびアップデートの機能を追加しました。 この機能では、in_udp, in_tcp, in_syslog, の3種のInputプラグインの動作を止めずに、リスタートやアップデートを行うことができます。

本記事では、Fluentdのプラグイン開発者向けに、その他のInputプラグインをこの機能に対応させる方法について紹介します。

こんにちは。Fluentdのメンテナーの福田です。

2024年12月14日に Fluent Package v5.2.0 をリリースしました。

本リリースでは、ゼロダウンタイム・アップデート機能を追加しました。 これによって、今後のバージョンではリスタートやアップデートをゼロダウンタイムで実行できるようになります。

この記事では、メンテナーの観点から Fluentd の最新パッケージの動向を詳しく解説します。

こんにちは。Gitはコマンド操作とクライアントアプリ操作を使い分けるのが好きな福田です。

突然ですが問題です。 このGitのよくあるコマンドラインを見てください。

• git push origin main

このmainって、どのmainだと思いますか？

...答えは、ローカルリポジトリーのmainです。

え、当たり前ですかね...？ なんと私は10年以上にわたって、これがoriginのmainのことだと勘違いしながら使い続けてきました。

え、結果的に同じことじゃん、って？ まあそうなんですが、この勘違いが見事にpush誤爆を生みまして、真相を知った私はまあ大きな衝撃を受けたわけです。

この記事では、私の勘違いポイントと、その勘違いが招いたpush誤爆を紹介します。

先日 fluent-package v5.2.0をリリースしました。

v5.2.0の注目に値する機能として、対応しているバージョンのパッケージ間でダウンタイムなしのアップグレードが実現できるという点があります。 （つまり、v5.2.0にアップグレードした後、その次のバージョンに改めて更新するときにダウンタイムなしでパッケージを更新できるということです。）

この機能を実現するためには、パッケージ更新時のサービスの挙動を制御し、意図しないタイミングで勝手にサービスがリスタートされないようにする必要がありました。 本記事では、サービスのリスタートに関連するneedrestartの機能をパッケージ側から抑制する方法について説明します。

Firefox・Thunderbirdの法人向けサポートサービスをご提供している関係で、「Firefoxのバージョン何々のサポート期限はいつまでなのか？」という趣旨のお問い合わせを頂くことがあります。

様々な意味に取れる「サポート期限」という言葉ですが、ここでは「Firefoxの特定のメジャーバージョンについて、セキュリティアップデート（マイナーアップデート）が提供される期間」を指します。このサポート期限は、公式には明確な日付で記載されることがなく、具体的な日付を知るにはいくつかの情報を元に演繹する必要があります。この記事では、オフィシャルに示されている情報からFirefoxのサポート期限を読み取る手順をご紹介します。