主にWindows環境での開発を行っている橋田です。今回、PowerShellで現在のセッションのカルチャを変更する方法を調査しました。これは、PowerShellのスクリプトがシステムのカルチャの影響を受けないようにしたい場合などに便利です。バージョンによって対応方法が異なることや、その背景など、調査をして初めて知ったこともあったため、その調査結果を紹介します。デフォルトのコマンドレットPowerShellには、以下のようなカルチャを変更するコマンドレットが存在します。Set-CultureSet-WinUILanguageOverrideSet-WinSystemLocaleしかしこれらのコマンドレットは、システム全体やユーザー単位の設定を書き換えるため、現在のセッションのカルチャのみを一時的に変更したいという目的では使用できません。セッションのカルチャの動作セッションのカルチャの動作については、PowerShell 6で仕様変更が入っています。https://learn.microsoft.com/ja-jp/powershell/scripting/whats-new/differences-from-windows-powershell?view=powershell-7.5#make-psculture-consistently-reflect-in-session-culture-changes$PSCulture がセッション内カルチャの変更を一貫して反映Windows PowerShell では、現在のカルチャの値がキャッシュされるため、セッションの開始後にカルチャが変更されると値が同期しなくなる場合があります。 このキャッシュ動作が、PowerShell Core で修正されています。PowerShell 6以降では[System.Threading.Thread]::CurrentThread.CurrentCultureを変更すると現在のセッションに反映されます。一方、PowerShell 5.1以下では[System.Threading.Thread]::CurrentThread.CurrentCultureを変更しても、キャッシュされた値が使われるため現在のセッションには反映されません。キャッシュされているカルチャの値を変更する必要があ

Apache Arrowの開発に参加している須藤です。現時点でapache/arrowのコミット数は1位です。私はRubyでデータ処理できるようになるといいなぁと思ってApache Arrowの開発に参加し始めました。同じような人が増えるといいなぁと思うので、最近の活動を紹介して仲間を増やそうと試みます。今回はApache Arrow C++で使っているビルドツールCMakeのFetchContentという機能を紹介します。背景Apache Arrow C++は開発当初からビルドツールとしてCMakeを使っています。最近はMesonでも（一部の機能は）ビルドできるようになっています。世の中にはビルドシステムをいじるのも好き（苦にならない）という人がそんなにいないようで、ビルドシステムをいじるのも好きな私が結構メンテナンスしています。今回はCMakeの機能の中でも依存ライブラリーの管理に使えるFetchContentに注目します。最近は、似たような機能であるExternalProjectからFetchContentに移行しています。たとえば、私は最近はAWS SDK for C++の管理をExternalProjectからFetchContentに移行しています。Apache Arrow C++はたくさんのライブラリーに依存しています。すべての依存はオプションになっているので、最小限の機能でビルドするときは気にしなくてよいですが、普通はそれなりに機能を有効をしてビルドするので気にしなければいけません。普通は依存しているライブラリーを事前にインストールしておかなければいけません。システムのパッケージマネージャー（Debianならaptとか）でインストールできるものなら比較的簡単に準備できますが、そうでないものを準備することは面倒です。ソースをダウンロードしてビルドしてインストールしないといけません。ということで、デフォルトではシステムにある場合はそれを使って、ない場合は自動でソースをダウンロードしてビルドするようになっています。それを便利にするための機能がFetchContentやExternalProjectです。ちなみに、MesonにもSubprojectsという似たような機能があります。CMakeで依存ライブラリーをビルドする方法CMakeで依存ライブラリーをビル

定期実行といえばcronの阿部です。定期実行するときにみなさまはどのようなソフトウェアをご利用でしょうか？この記事はFLOSS1サポート業務でジョブ管理ツールのRundeckについて調査したのでその事例紹介です。（本題と全く関係ないのですが、最近、systemdのtimerという機能でも定期実行できることを知りました。）はじめに思ったより書くことが多くなりそうだったので、だいぶ簡潔に書きました。いろいろ省略したことで説明が正確ではない部分があるかもしれませんがご容赦ください。Rundeckの説明この事例に関連するところだけを簡単に説明どのような問題があったのか説明問題を調査した結果の流れで説明していきます。RundeckとはRundeck: https://www.rundeck.com/Rundeckはジョブ管理ツールです。cronに馴染みのある方であれば、cron + crontab + いい感じのGUI という理解で60%くらい合っていると思います。以降で、サポート事例を紹介するにあたりRundeckについて知っていたほうが良い部分だけ簡単に説明します。Rundeckの概要Rundeckは常駐プログラムですsystemdでstartしたりstopしたりしますRundeckのジョブとはcrontabでいうところの 5 0 * * * COMMAND の1行という理解で30%くらい合ってます（もう少し複雑な設定ができます）実行したいコマンドを登録して、スケジュールの設定とかができます参考: https://docs.rundeck.com/docs/manual/jobs/creating-jobs.html#scheduled-jobsRundeckがジョブを実行するときはスレッドで実行しますRundeckはジョブを実行しているスレッドが、ジョブのステータス（正常終了したとかエラーだったとか）をDB（H2とかPostgreSQLとか）に保存しますクラスターモードで冗長構成が実現できますhttps://docs.rundeck.com/docs/administration/cluster/補足: クラスターモード記事の内容に関係があるのでクラスターモードについて少し補足します。クラスターモードにすると、Rundeckサーバを複数台 + DBサーバは共通の1台、の

select max(_id) from table; なことをGroongaでしたい阿部です。冒頭から余談です。SQLは大文字で書く方がよくある書き方なんですが、小文字で書く派もそれなりいて私は小文字で書くのが好きです。大文字で書くのがめんどくさいからです。ということで、本記事ではSQLは小文字で書きます。閑話休題。Groongaは集計もできます。ただちょっとややこしいので、SQLで書くとこんな感じになりますよ、ということを示して世に多いであろうSQL好きにGroongaをPRするための記事です。おことわり書きコマンドの省略例示するGroongaコマンドが長くなるので --output_pretty yes は省略して掲載しています。レスポンス例の省略Groongaのレスポンスは [HEADER, BODY] の形式です。参考: https://groonga.org/ja/docs/reference/command/output_format.htmlまずこの HEADER の部分は省略します。また BODY の中には「何も加工していない検索結果部」と「集計結果部」の2つになります。今回は集計に焦点を当てるので、「何も加工していない検索結果部」は省略します。説明に使うデータ_keytagpriorityGroonga v13Groonga10Groonga v14Groonga60Mroonga v13Mroonga61Mroonga v14Mroonga24Mroonga v15Mroonga68Rroonga v12Rroonga3Rroonga v13Rroonga-9Rroonga v14Rroonga29Rroonga v15Rroonga0Groongaにデータを投入するには次のコマンドを実行します。table_create Tags TABLE_PAT_KEY ShortTexttable_create Memos TABLE_HASH_KEY ShortTextcolumn_create Memos tag COLUMN_SCALAR Tagscolumn_create Memos priority COLUMN_SCALAR Int64load --table Memos[{"_key": "Groonga v13", "tag": "Gro

PostgreSQLのautovacuumと格闘中の阿部です。（という出だしで始めましたが本記事ではPostgreSQLのautovacuumについては触れないので、興味があれば公式ドキュメントをご覧ください。）今回はPGroongaからGroongaのリソースを確認する方法を紹介します。PGroongaはインデックスとしてGroongaを使うPostgreSQLの拡張機能です。PostgreSQLにてお手軽にゼロETLで全言語対応の超高速全文検索機能を使えるようになりますが、より専門的なチューニングなどをする場合は内部で利用しているGroongaの状況も確認する必要があります。今回はその一例としてGroongaのn_buffer_segmentsの値を確認する方法を紹介します。はじめにこの記事はPGroongaでGroongaのリソースを確認するイメージをつかんでもらうことを目的に書いています。本文中に登場するGroongaコマンドやPGroongaの関数について細かく説明しすぎると目的から外れてしまうので簡単に紹介するに留めます。この記事では次のGroongaコマンドやPGroongaの関数が登場します。Groongaコマンドobject_inspect: https://groonga.org/ja/docs/reference/commands/object_inspect.htmlオブジェクト（テーブルやカラム）を調査するコマンドですこのコマンドで表題のn_buffer_segmentsの値も確認できますdump: https://groonga.org/ja/docs/reference/commands/dump.htmlいわゆるdumpコマンドですスキーマやデータを出力しますPGroongaの関数pgroonga_index_column_name: https://pgroonga.github.io/ja/reference/functions/pgroonga-index-column-name.htmlPGroongaのインデックス名をGroongaのインデックスカラム名に変換しますpgroonga_command: https://pgroonga.github.io/ja/reference/functions/pgroonga-comm

Apache Arrowの開発に参加している須藤です。現時点でapache/arrowのコミット数は1位です。私はRubyでデータ処理できるようになるといいなぁと思ってApache Arrowの開発に参加し始めました。同じような人が増えるといいなぁと思うので、最近の活動を紹介して仲間を増やそうと試みます。今回はapache/arrowリポジトリーで使っているCIツール「Crossbow」を紹介します。背景Apache Arrowはいろんな言語で使える！というのもウリの一つなので、たくさんの言語での実装があります。Apache Arrowのリポジトリー分割で紹介した通り、apache/arrowリポジトリー内に各種言語の実装がありました。こういう構成にしているとなにが困るかというと、CIです。1つのリポジトリーに開発が集中してCIが追いつかないんです。最近は各実装の別リポジトリーへの分割やGitHub Actionsのキャパシティ増加（Apache Software Foundationがなにかお金を払ってくれているのかもしれないがよくわかっていない）などで溢れ（実行待ちのジョブが溜まってなかなか結果を確認できない）なくなっていますが、2018年頃は溢れていました。ということで、「Crossbow（クロスボウ）」というApache Arrowの開発用のCIツールが開発されました。名前の由来はArrow（矢）に関連する単語だから、なはず。クロスボウは矢を射る弓の一種。Crossbowを使うことでapache/arrowのCIキャパシティは増加し、開発が楽になりました。しかし、前述の通り、2018年当時と比べると状況はだいぶ変わってきたので、Crossbowを卒業できるようになってきている感があります。ということでCrossbowをやめない？という提案をしているのですが、それについてはまた別途紹介します。今回はCrossbowを紹介します。CrossbowCrossbowはかなり強引にCIのキャパシティを増やすツールで、まぁ、なんというか、あまり行儀はよくありません。どうやってCIのキャパシティを増やしているかというと、各種CIサービスを組み合わせることで増やしています。1つのCIサービスだと溢れちゃうならたくさんCIサービスを使えばいいんじゃない？というアイディアです。

13年前にリーダブルコードの解説を書いた須藤です。リーダブルコードにもコメントの話がありますが、本に書いているケース以外でもコメントを書くことがあるので紹介します。ちなみに、私はできるだけコメントを書きたくない派ですが、そんな私でもコメントを書いておいた方がよいという場面があるのです。まぁ、レビューすることが増えちゃって、自分でコメントを書くというより、コメント書いておいて、と言うことの方が多いんですが。。。いつ削除してよいかを書く一時しのぎのコードを書かないといけないことがあります。たとえば、依存ライブラリーに問題があり、依存ライブラリーに報告して修正した（みんなもアップストリームで直すんだよ！）けどまだ修正が含まれた依存ライブラリーがリリースされていないときです。この場合は手元のコードに一時しのぎのコードを書いて対処したりします。このような場合は「いつこの一時しのぎのコードを削除してよいのか」をコメントで書きます。例： https://github.com/apache/arrow/pull/45310#discussion_r1924494628Could you add a comment that we can remove this workaround when we require aws-sdk-cpp 1.11.489 or later?このようなコードは不要になったらすぐに消したいものです。（研鑽Rubyプログラミングでも機能削除がうれしいと書いているよね！）このようなコメントがないと、このようなコードを見るたびに消せるかな？と確認しなければいけません。このようなコメントがあれば、すぐに消せるかどうか判断できます。リーダブル！どんなlintを無視しているかを書くlinterは機械的にいろいろチェックしてくれるので便利です。しかし、たまに誤検出することもあるので、そのようなチェックは個別に無視します。多くの場合、チェックはたくさんあり、特定のチェックを無視するためにはどのチェックかを識別する必要があります。識別するためのIDを数値で振っているlintもあればヒューマンリーダブルな文字列で振っているlintもあります。たとえば、Hadolintは数値でIDを振っているlintです。# hadolint ignore=DL3006とかで特定のチェック

Apache Arrowの開発に参加している須藤です。現時点でapache/arrowのコミット数は1位です。私はRubyでデータ処理できるようになるといいなぁと思ってApache Arrowの開発に参加し始めました。同じような人が増えるといいなぁと思うので、最近の活動を紹介して仲間を増やそうと試みます。今回はapache/arrowリポジトリーでやっているリポジトリーの分割について紹介します。背景Apache Arrowはいろんな言語で使える！というのもウリの一つなので、たくさんの言語での実装があります。もともとapache/arrowリポジトリー内に各種言語の実装があったのですが、最近はそれを言語ごとに別のリポジトリーに分割しはじめています。別のリポジトリーへの分割は最近になって始まったことではありません。2021年にRust実装をapache/arrow-rsに分割したり、Julia実装をapache/arrow-juliaに分割したりしてきました。しかし、それらは開発スタイルの違いが分割の理由で、最近の分割の理由とは違いました。それから数年は分割していませんでしたが、この1-2年でまた分割が始まっています。Go実装とJava実装は分割済みで、C#実装とJavaScript実装が分割中で、Swift実装はもうしばらくすると始まる予定です。分割の理由以前の分割の理由は開発スタイルの違いでしたが、最近の分割の理由はリリースです。具体的には次の2つの点が重要です。apache/arrowのリリースコストの削減（リリース対象が減るとリリースが楽になる）分割対象の実装のメジャーバージョンアップを減らしたい前者は、「まぁ、やることが増えれば大変になるのはそうだよね。。。」というのでなんとなくわかると思うので追加の説明はしませんが、後者は少し補足します。apache/arrowは3-4ヶ月に1回のペースでメジャーバージョンアップリリースをしています。毎回メジャーバージョンアップなのは「今の開発ペースだと3-4ヶ月も開発すれば非互換な変更はまず入っているよねー」という判断からです。apache/arrowはセマンティックバージョニングを採用しているので、非互換な変更が入っている場合はメジャーバージョンアップにしなければいけません。apache/arrowのすべての実装は同時に

2025年5月16日にFluent PackageのLTSの最新版となるv5.0.7をリリースしました。本リリースでは、パッケージでいくつかの改善が行われています。本記事ではFluent Packageの変更内容について紹介します。Fluent Package v5.0.72025年5月16日にFluent PackageのLTSの最新版となるv5.0.7をリリースしました。Fluent Package v5.0.7では以下の改善が行われています。Rubyのバージョンを3.2.8にアップデート同梱のFluentdをv1.16.7からv1.16.9に更新同梱のopenssl gemをv3.3.0に更新fluent-plugin-elasticsearchのメモリリークを解消この記事では、Fluent Package v5.0.7の主な変更点を詳しく解説します。変更内容の詳細Rubyのバージョンを3.2.8にアップデートRuby 3.2.8には複数のバグ修正が含まれています。詳細はRuby 3.2.8 リリースノート をご覧ください。同梱のFluentdをv1.16.7からv1.16.9に更新v1.16.8とv1.16.9の変更点を説明します。Fluentd v1.16.8 の変更点Windows: Supervisorプロセスが停止したときに、サービスが停止しない不具合を修正設定エラーなどでSupervisorプロセスが停止した際に、 サービスが実行され続ける不具合を修正しました。サービスが正しく停止するようになり、設定エラー時の異常検知が容易になりました。formatter_csvプラグイン: メモリリークを修正パフォーマンス改善のためにformatter_csvプラグインでキャッシュが導入されていましたが、不適切にスレッドをキャッシュしていました。in_execプラグインではログを取り込むたびにスレッドを生成しているのですが、formatter_csvプラグインと組み合わせて利用すると、すべてのスレッドがformatter_csvプラグインでキャッシュされ、メモリリークを引き起こしていました。Fluentd v1.16.9 の変更点Windows: サービスが誤って停止する不具合を修正Fluentd v1.16.8で「Supervisorプロセスが停止したときに、

PGConf.dev 2025が開催中だということをすっかり忘れていた須藤です。私はPGConf.dev 2025に参加していないのですが、1ヶ月ほど前に「ポスターセッションに参加しない？」とメールで連絡をもらったのでポスターデータだけ送っていたのでした。実際に使われたのかどうかはわかりませんが、せっかく作ったのでここに置いておきます。1ヶ月ほど前に、PGConf.dev 2025でポスターセッションを企画しているという方からメールで連絡が来ました。Commitfest（2ヶ月に1回くらいのペースで開催されているPostgreSQLにコミットしていこうぜ！という企画、という感じかな）でなんども次のCommitfestに延期されている人たち（ようはがんばっているけどまだコミットされていない人たち）に声をかけているようでした。そういう人たちがポスターセッションでPGConf.dev 2025に参加しているPostgreSQL開発者にアピールして、早くコミットまでいけるようにすることを狙っているのだと私は理解しました。私は一般的な学会のポスターセッションというものに参加したことがないのですが、普通はポスターの前に作成者が立って興味ある人にポスターの内容をもとに説明したり議論したりするはずです。しかし、私はPGConf.dev 2025には参加しません。それでもよければポスターデータだけ用意するよ、とお返事したところ、PGConf.dev 2025に参加して、かつ、ポスターを用意してくれる人が多ければ、使えないけど、そうではなかったら使うから用意してくれるとうれしいなという感じのお返事でした。ということで、こんな感じのポスターデータを用意しました。私がこの1,2年提案しているCOPY FORMATを拡張可能にするパッチの概要と実現方法となにを手伝って欲しいかをまとめてみたつもりです。ポスターデータを送ってからお返事が返ってこなくなった上にPGConf.dev 2025に参加していないので、私はこのポスターが使われたのかどうかはわかりません。ただ、このパッチはまだしばらくコミットされる気配はない（コミットされるかなーと思っていたけど、やっぱり実装方法を考え直さない？という感じになっている）ことはわかっています。この機能に興味がある人はpgsql-hackers@postgre

RubyKaigi 2025に参加して、dRubyに出会った児玉です。この記事では、次の2つのことについて話します！dRubyとの遭遇RubyKaigi 2025で印象に残ったトークdRubyとの遭遇いきなりですが、dRubyを触ったことがありますか？私は、気にはなってはいたのですが、今回のRubyKaigiまで触ったことがありませんでした。ひょんなことから、コード懇親会でdRubyのサポートをされていた塩井さんに、同イベントで咳さんが利用されていたdRubyのテキストを譲っていただきました。これがきっかけで、実際に手を動かして触れる機会を得ました！実際に読んでみると1ページ目から不思議な世界が広がっており、私は引き込まれました。ぜひ、この感動を皆さんにも味わっていただきたいので、紹介します！（1ページ目だけ紹介します。）自分で手を動かして触ってみたい方は、テキストであるdRuby hands-on workshopが配布されているので、ぜひ実際に動かしてみてください！（配布していただきありがとうございます。）では、実際にテキストの1ページ目に書いてある内容を見ていきましょう。次のような、hello_server.rbとhello_client.rbがあります。# hello_server.rbrequire "drb"class Hello def greeting puts("Hello World.") endenduri = "druby://localhost:54000"DRb.start_service(uri, Hello.new)sleep# hello_client.rbrequire "drb"DRb.start_serviceuri = "druby://localhost:54000"it = DRbObject.new_with_uri(uri)it.greeting次のように実行すると何が起きるでしょうか？// terminal 1$ ruby hello_server.rb// terminal 2$ ruby hello_client.rb私の感覚では、hello_client.rbを実行した瞬間に、it.greetingの部分でNoMethodErrorが起きて、エラー終了すると思っていました。ただそうはならないのが不思議なポイン

RubyKaigi 2025でアンドパッドさんが開催したコード懇親会をお手伝いした須藤です。2025年5月12日（月）（来週の月曜日）の夜にコード懇親会自慢大会を開催するので紹介します。まだ参加登録できるのでコード懇親会に参加した人もそうでない人も興味がある人は参加してね！内容このイベントはコード懇親会で楽しかったことを自慢するイベントです。コード懇親会ではグループにわかれて懇親するのですが、自分が参加しているグループ以外の様子はわからないので、他のグループの人たちや今回参加しなかった人たちにどんな感じで楽しんだかを自慢しよう！というのがねらいの1つです。もう1つのねらいはコード懇親会当日は聞けなかった感想を聞いて来年のコード懇親会に活かすことです。オープニングでは、コード懇親会のコンセプトを紹介したり今回はどうしてこんな内容にしたかを説明する予定です。このような説明をする理由は、このイベントに参加者以外も参加するというのもあるのですが、今回はほぼ説明なしで始めたので参加者した人たちもコンセプトを知らない人もいそうだなぁというのもあります。ちょっとdRubyフリークっぷりが溢れてしまっている感じがありますが、好きなんだからしょうがないんです。 Boast Code Party 2025 / コード懇親会2025自慢大会 関連リンク：スライド（Rabbit Slide Show）リポジトリーまとめ2025年5月12日（月）（来週の月曜日）の夜にコード懇親会自慢大会を開催するので紹介しました。まだ参加登録できるのでコード懇親会に参加した人もそうでない人も興味がある人は参加してね！待っているよ！

こんにちは。Fluentdの開発やメンテナンスに参加している藤田です。Fluentd公式のブログでの情報発信やGitHubのIssuesでのやりとりなどは、主に英語を使用しています。この度、もっと日本のユーザーの皆さんと直接繋がり、開発の現場からタイムリーな情報をお届けしたいと考え、日本コミュニティ向けのXアカウントを開設し、日本語での情報発信を始めることにしました！Xアカウントのご紹介アカウント名: @fluentd_jpこのアカウントでは、Fluentdの最新情報や不具合とその回避方法など、Fluentdをより良く利用するのに役立つ情報を発信していきます。Fluentdをご利用の方や、ログ収集などに興味がある方はぜひフォローしてください！具体的には、以下のような情報を発信していく予定です。最新情報 & リリース解説リリースノートの速報はもちろん、変更の背景や開発者としての注目ポイントをプラスαでお届けします。プラグインの情報各プラグインの更新情報などをお届けします。ハマりやすい設定の解説Fluentdは歴史的な経緯などにより多様な設定ができます。間違えやすい設定情報についてお届けします。コミュニティーに報告された事例の解説GitHubのIssues/Discussionsなど、コミュニティーにはユーザーが困った事例などが日々報告されています。みなさんにも有益な事例をピックアップして、解決方法を共有します。Fluentdを深く理解したいエンジニアの方、日々の運用で困っている方、そしてFluentdの開発に興味がある方にとって、価値ある情報源となることを目指します。Fluentdは、ユーザーと開発者が一体となった活発なコミュニティによって支えられ、進化してきました。皆さんからのフィードバック、バグレポート、そしてコントリビューションは、開発を進める上で不可欠な原動力です。このXアカウントが、皆さんと私たち開発者の距離を縮め、よりオープンで建設的なコミュニケーションを生み出す場となれば幸いです。おわりにFluentdに関する情報に興味のある方は、ぜひ @fluentd_jp をフォローしてください！皆さんのフォローやリプライが、情報発信の大きなモチベーションになります。どうぞよろしくお願いします！

RubyKaigi 2025でGoodbye fat gem 2025というfat gemをやめない？という話をしてきた須藤です。なお、クリアコードはシルバースポンサーとしてRubyKaigi 2025を応援しました。 Goodbye fat gem 2025 関連リンク：スライド（Rabbit Slide Show）リポジトリー内容内容は2025年、fat gemをやめるを（gemメンテナーじゃなくて）ユーザーにも伝わるようにユーザー視点でまとめなおしたつもりです。gemメンテナーかどうかで伝わりやすさが違う気がしますが、まずはスライドで私の主張が伝わるか確認してみてください。伝わらなかったら前述のブログ記事も呼んでみてください。ユーザー視点のまとめかたではあまり深刻さが伝わらない気がしたので、発表ではキャッチーな感じで伝えたつもりですが、伝わったでしょうか？要点はこうです。ユーザーが心地よいと感じるfat gem体験を維持するためのメンテナンスコストが高いこのままユーザーがfat gemのメンテナンスコストが高い状態を求め続けるとgemメンテナーが減ってしまってRubyエコシステムに負の影響があるのではないかユーザーの利便性とgemメンテナーのメンテナンスコストのバランスを考えたRubyエコシステムを考えられないか私の提案とは真逆のGoals for Binary Gems ("Wheels")という話もあったりして今後どうなるかはわからないのですが、RubyGemsの人たちとはお話しないといけないなーという気持ちになりました。ということで、RubyKaigi 2025中になけなしの英語でリンク先の記事を書いていたSamuelさんにちょっとお話にいったり（たぶんほとんど伝わっていない）、BundlerのSlackとかWhere is "Wheels" proposal discussed · rubygems · Discussion #8575とかで方向性を相談できない？とか声をかけることは始めました。この件について、今、ユーザーのみなさんができることはほとんどないと思うんですが、どうにもならなくなる前には知っておいて欲しいなぁと思ったのでした。RubyKaigiで共有できて助かりました。持ち時間が30分で詳しい話はできなかったのですが、この件についてなにか取

FirefoxやThunderbirdには、古い集中管理の仕組みとしてMCD（Mission Control Desktop）という機能があります。元々はシステム管理者が決めた設定値を各端末のソフトウェアに強制適用するための物でしたが、現在その役割はポリシー設定機能が担うようになってきており、この用途においてMCDは、ポリシー設定機能では制御できない部分を補うために使われる程度となっています。このMCDの設定ファイルを使用している環境では、FirefoxやThunderbirdの更新後に、起動時に「設定ファイルを正常に読み込めませんでした。システム管理者に問い合わせてください。」というメッセージが表示されるようになることがあります。最近も、Thunderbrird 136への更新でこの現象が起こるようになったとのご相談をお客様から頂きました。詳しく調査したところ、Thunderbird 136において、確かに同様のトラブルが起こりやすくなるような変更があったことと、多くの場合はモジュールの読み込みを行っている箇所を修正するだけで問題を解消できることが分かりました。本記事では、この問題の背景事情と回避方法をご紹介します。cu.import()があればchromeutils.importesmodule()に書き換えてみる">結論：Cu.import()があればChromeUtils.importESModule()に書き換えてみる先に結論から述べると、const { ～ } = Components.utils.import('～.jsm', {});あるいはconst { ～ } = Cu.import('～.jsm', {});このようなモジュール読み込みの指定がMCD用設定ファイルに含まれているのであれば、const { ～ } = ChromeUtils.importESModule('～.sys.mjs');と書き換えてみてください。それ以前は動いていたのにThunderbird 136に更新したら動かなくなった、というケースの大半は、この変更で解消されると考えられます。問題が起こる背景1：高度なカスタマイズ先に、MCDはポリシー設定を補完する物と述べましたが、もう一つの使い方として、Firefox 57およびThunderbird 78以降で廃止されたXU