今月末に、クリアコード20周年記念Meatupが開催1されます。設立20周年を記念するこのイベントではクリアコード年表公開！#cc20thとアナウンスがあったように、コンテンツの1つとして「クリアコード年表」というアプリを公開しています。「クリアコード年表」は設立してからクリアコードがどのようにフリーソフトウェアとビジネスの両立をしてきたかを、タイムラインで表示するものです。自由にコメントを寄せてもらえるように、年表アプリにアカウント連携のしくみを導入しました。今回は、年表アプリへのアカウント連携組み込みのさわりを紹介します。どのアカウントと連携できるようにするかクリアコードは、これまでさまざまな自由な（場合によっては不自由なこともある）ソフトウェアの開発に関わってきました。そのため、GitLabとのアカウント連携ははずせません。実際、自分たちでもGitLabのインスタンスを運用して活用しています。2クリアコードとこれまで関わりのあったお客さんは、かならずしもGitLabに馴染みがあるとは限りません。より間口を広げるため、GitHubのアカウント連携にも対応することにしました。2どのようにアカウント連携を実現するか今回実装した20周年アプリは、普段触っていない技術で作ってみようということで、Rails 8を採用しました。20周年記念イベント開催までの限定された期間だけ稼働する予定のものなので、素早く立ち上げられることが大事だったからです。社内にはRubyに詳しい人も多いので、みんなであれこれいじりやすいだろうという目論見もありました。アカウント連携については、Devise + OmniAuthに落ち着きました。以下のようなgemを利用することで、比較的低コストで実現できました。...gem 'omniauth-gitlab'gem 'omniauth-github'gem 'omniauth-google-oauth2'gem 'devise-jwt'今から思えば、 組み込みの認証ジェネレータとOmniAuthを組み合わせたほうがシンプルに実現できた気もします。今回のアカウント連携での知見としては次のようなものがありました。GitLabとセルフホストしているGitLabのインスタンス双方のアカウント連携を実現するにはどうするとよいか複数のアカウント連携を実現するには

2026年6月25日にFluentdの最新版となるv1.19.3をリリースしました。v1.19系のメンテナンスリリースとなっており、fluent-package LTS版のv6.0.4に同梱されています。本記事では、公式サイトで公開している情報を日本語で解説します。情報セキュリティ早期警戒パートナーシップガイドラインに基づき、Fluent Packageにおける複数の脆弱性としてFluentdの脆弱性を公表・修正しています。Fluentd v1.19.3では、いくつかの不具合・脆弱性を修正しました。複数の脆弱性(後述)を修正しましたin_debug_agentで既定ではリモートから接続を受け付けないように挙動を変更しましたバッファのパスに[]を含む場合、resumeできない不具合を修正しましたリモート側で接続が切断された後のソケットへの書き込みに関する不具合を修正parser_csv: 空行をパースしたときにTypeErrorが発生する問題を修正しましたstorage_local: 非ASCII文字を保存したときに、再起動など再読み込みが必要になると例外が発生する問題を修正しました脆弱性修正Fluentd v1.19.3では複数の脆弱性を修正しました。Remote Code Execution (RCE) via Arbitrary File Write in ${tag} PlaceholderCVE-2026-44024CVSS v3 score: 9.8/10 (Critical)脆弱性: プレースホルダーにtagを指定している場合、設定ファイルの書き方や実行権限が不適切だと、任意のパスにファイルを書き込まれ、リモートからコード実行可能な脆弱性です。Exposure of Sensitive Information via Monitor Agent APICVE-2026-44025CVSS v3 score: 7.5/10 (High)脆弱性: monitor_agentによって公開されているAPIを悪用して、Fluentdの設定内容を読み取られる脆弱性です。互換性のない変更: もしあえて(安全でない)以前の挙動に戻したい場合、include_config、include_retry および include_debug_info パラメータを変更します。<

2026年6月26日にLTS版 Fluent Package v6.0.4をリリースしました。本記事では、Fluent Package v6.0.4の変更内容を紹介します。情報セキュリティ早期警戒パートナーシップガイドラインに基づき、Fluent Packageにおける複数の脆弱性として同梱されるFluentdの脆弱性を公表・修正しています。Fluent Package v6.0.4Fluent Package v6.0.4 では、以下の対応を行いました。脆弱性対応のため同梱のFluentdをv1.19.3に更新脆弱性を修正したs3およびopentelemetryプラグインに更新Fluent Packageをすぐに更新できない場合には、後述する緩和策を適用するか、個別に脆弱性が修正されたgemのインストールを推奨しています。変更内容の詳細脆弱性対応のため同梱のFluentdをv1.19.3に更新Fluent Package v6.0.4 では、Fluentd v1.19.2以前に複数の脆弱性が発覚したため、それらを修正したFluentd v1.19.3を同梱するようにしました。閉域網（信頼されているネットワーク内）での利用には影響ありません。脆弱性が報告されたバージョンを含むパッケージは、次の通りです。fluent-package v6LTS: v6.0.3以前のすべてのバージョン通常版: v6.0.0 (通常版の更新はしばらく予定されていないので、LTSへの移行を推奨します。)fluent-package v5LTS v5.0.9以前のすべてのバージョン (v5.0.xはすでにサポート終了しているので、v6 LTSへの移行を推奨します)通常版: v5.2.0以前のすべてのバージョン (v5.xはすでにサポートを終了しているので、v6 LTSへの移行を推奨します)td-agentすべてのバージョンが該当 (td-agentもすでにサポートを終了しているので、v6 LTSへの移行を推奨します)Fluent Package v6.0.4に同梱されているFluentd v1.19.3では次の脆弱性が修正されました。Remote Code Execution (RCE) via Arbitrary File Write in ${tag} PlaceholderCVE-20

こんにちは、Fluentdチームの藤田です。先日、アナウンスがあった通り クリアコード20周年記念Meatupに向けた「クリアコード年表」システムを公開しました。https://20th.clear-code.com/さて、今回の記事では少し趣向を変えて、この年表アプリの裏側で稼働しているインフラと監視の仕組みについて紹介したいと思います！クリアコードといえば、データ収集ツールである Fluentd の開発・サポートに深く関わっています。今回のアプリ運用でも当然 Fluentd を活用しているのですが、ただ単に「Webサーバーのログをファイルに保存する」ためだけに使っているわけではありません。今回は、Fluentdを「イベントルーター」として活用し、社内チャットへのリアルタイム通知システムを構築した2つの事例をご紹介します。事例1：アクセスログを「イベント通知」に変換する年表アプリを公開したからには、ユーザーから新しいエピソードやコメントが投稿されたら、すぐに社内で気づいてワイワイ盛り上がりたいですよね。これを実現するために、アプリケーション側にわざわざ通知用のコードをゴリゴリ書くのは少し手間で、「リトライ処理はどうしようか？」などなどエラー処理は気が滅入るところです。そこで、Webサーバーのアクセスログに目をつけました。「コメントの投稿」は、HTTPリクエストとしては POST /events/xx/comments のようなアクセスとして記録されます。Fluentdのストリーム処理を活用し、この特定のアクセスログだけをリアルタイムにフィルタリングして、社内チャットへ通知として横流しする仕組みを構築しました。<source> @type tail path /var/log/nginx/access.log pos_file /var/log/fluent/nginx/access.log.pos tag nginx.access <parse> @type nginx </parse></source><filter nginx.access> @type grep <regexp> key method pattern ^POST$ </regexp> <regexp> key path pattern ^/(api/v1/)?events/[0-9]+/co

Fluentdでは、JSONデータのパースにおいて、長らく yajl-ruby gem に依存してきました。しかし、よりモダンで標準的な環境への移行を目指し、標準ライブラリである json gem への置き換えを進めています。Fluentd v1.19.0 リリース時に当時対応可能な箇所は移行しましたが、ストリーミングで送られてくるJSONデータのパースにおいて yajl-ruby gem の依存を消せずにいました。しかし、最新の json gem にストリーミング処理を可能にする JSON::ResumableParser が導入されることで、ついに完全移行への道が開かれました。本記事では、この移行の過程で直面した技術的な課題と、RubyのC拡張におけるディープなバグの発見、そしてアップストリームへの還元について解説します。背景：なぜ yajl-ruby を置き換えるのかFluentdの in_forward や in_unix、各種 exec 系のプラグインでは、ストリームとして連続的に流れてくるJSONの断片を効率よくパースする必要があります。これまでは yajl-ruby がその役割を長らく担ってきました。しかし、yajl-ruby が内部で使用している Ruby の C API はすでに deprecated となっており、今後の Ruby 4.1 ではついにその API 自体が完全に削除される予定です（ruby/ruby#15447）。yajl-ruby のアップストリームでも対応パッチ自体はマージされているものの、一向に新バージョンとしてリリースされない状態が続いています（brianmario/yajl-ruby#233）。このような背景から、このまま yajl-ruby に依存し続けると、今後新しくリリースされる Ruby のバージョンで Fluentd を安定してメンテナンスし続けることが困難になるという強い危機感がありました。幸いなことに、次期バージョンの標準ライブラリである json gem に、ストリーミングパースを可能にする JSON::ResumableParser が導入されます。今回はこの最新のパーサーを利用し、将来の Ruby バージョンでも安全に動作し続けるよう、Fluentd内部のパース処理を置き換える実験的な取り組みを行いまし

Cloudflare Workersを使っていない須藤です。著者の1人であるちまめさんにCloudflare Workers 実践ガイド 〜エッジで実現するWebアプリケーションの設計・実装・運用⁠〜をもらったのでCloudflare Workersを勉強してみました！本書の構成最初の100ページくらい（4章まで）がCloudflare Workersの説明で、その次の200ページくらい（！）（5章のみ）が具体的な使い方1で、その次の100ページくらい（6章のみ）が具体的な使い方2で、最後の40ページくらいが実際に運用するときの役立ち情報という感じでした。Cloudflare Workersの説明最初の説明のところでは、他の類似の仕組みとのトレードオフもあわせて示してくれているので、私のようにCloudflare Workersに詳しくないけど、他の仕組みはまぁまぁ知っているという人がCloudflare Workersが向いているところ・向いていないところのポイントを掴みやすいです。Cloudflare Workers以外のCloudflareが提供する各種サービスの概要もここでカバーされています。自分たちのサービスでCloudflare Workersおよび周辺サービスは使えるのか？使えないのか？ということが気になっている人はこのあたりを読んで判断材料を集めるとよさそうです。関係ないのですが、Cloudflare Durable Objectsを使うとどうして安全なカウンターを実現できるのかわかりませんでした。本書にCloudflare Durable Objectsを使ったカウンターの実装例として小さなコードが載っているのですが、これがどうやって直列処理されるのか（書き込んでいるプロセスは対象のオブジェクトのロック（？）をどのタイミングで開放するの？とか単純に直列処理したら遅くない？とかエッジコンピューティングで直列処理の待ちって現実的なの？とか）がピンときませんでした。本書では各種サービスのドキュメントのリンクが載っているので、そういう細かい話は本書の範囲外ということだと思います。周辺サービスの細かい話が気になる人は本書よりも公式ドキュメントのほうが向いていそうです。具体的な使い方1最初の説明のあとは、1章で200ページくらいというそれだけで1冊の本にしても

Redmineが20周年だそうです。おめでとうございます。あとクリアコードが20周年だそうです。そして私も社会人20周年っぽいです。阿部です。REDMINE JAPAN vol.5で「Redmineで欲しい情報を見つける、そしてAIに賢く答えてもらおう」というタイトルで発表予定です。スライドも公開しますが、発表用のスライドのため十分な説明が記載されていないので、解説テキストを追加したブログ記事も残します。はじめにRedmineを使っているとどんどんデータが溜まっていきます。有益な情報もたくさんあるので、あとから参照して活かしたいです。例えば直近で「認証に失敗する不具合」があったときに、過去に同様に問題がなかったか検索したりするでしょう。そのときに「認証に失敗する不具合」で検索して欲しい情報にたどり着けるでしょうか？もしかしたら過去の情報には「ログイン」や「サインイン」、「バグ」という用語が使われているかもしれません。そうすると「認証に失敗する不具合」で検索していてはたどり着けません。検索して情報が見つからないと、近年話題のAIも活用しきれません。基本的にAIは一般的なことしか知らないので、Redmineに記載されている内部情報は知りません。ですので、Redmineの情報をAIに与え、その上でAIに回答してもらう方法を取ります。しかし、先ほどのように欲しい情報が検索できないと、AIに必要な情報が与えられず、AIにいい感じの回答をしてもらえません。と、言うことでRedmineにいい感じに検索できる何かを追加して、いい感じの検索結果を得て、それをAIに与えることでAIに賢く答えてもらおう、を試みた結果についての記事です。（いろいろ試行錯誤中だったりで、運用にすぐ使える状態ではないですが、動いてはいるので改善すれば近々利用できるはず！）課題の整理と解決方法課題は上述の通り表記ゆれなどで見つけたい情報が見つけられないことです。どこかで聞いたことのある課題です。そう！「PostgreSQLでのセマンティックサーチへの挑戦」で見ましたね！そして、その課題はセマンティックサーチを使えば解決できそうです。（なぜ、セマンティックサーチを使うと解決するのか、など細かい話は↑の記事に書いてあるのでそちらを参照してください。）「PostgreSQLでのセマンティックサーチへの挑戦」の記事によ

イベント準備をしている吉本です。以前ククログで予告していた、クリアコード20周年記念Meatupのイベントコンテンツの一つ「クリアコード年表」システムを公開しました！https://20th.clear-code.com/GitLab/GitHub/Googleアカウントでログインしていただくと、右上のメニューからタイムラインへイベントの追加が可能ですので、気軽にクリアコードとあなたのエピソードを追加してください！もし、すでに年表に含まれるイベントを知っていたり、覚えていることがあれば、イベント右下のコメントマークから、コメントを残してみてください。よろしくお願いします！今後クリアコードメンバーがイベントの追加や、機能の追加を行う予定です！クリアコード年表の実装にまつわる記事も公開予定です。お楽しみに！おまけもし、クリアコードファンからの機能追加リクエストがあれば、issue/merge requestを送っていただければと思います！こちらのリポジトリーでお待ちしています！

Ruby関連の開発に参加する人が増えるといいなぁと思っている須藤です。2026-08-05（水）の日中にRubyアソシエーションさんがRubyエコシステム開発入門ワークショップを開催します。このワークショップはRuby本体やRubyGemsの開発に参加してみたいけど敷居が高そう・どこからはじめればよいかわからないなどといった理由で最初の一歩を踏み出せていない人たちをサポートするワークショップです。RubyKaigiのようなカンファレンスや各種Rubyコミュニティなどに参加すると、使うだけではなく開発にも参加したくなるものですが、このワークショップに参加するとそういった人たちが実際に行動に移せるようになるはずです！自分がそのような人の場合は、ぜひ参加してみてください！まわりにそのような人がいる場合はこのワークショップを教えてあげてください！なお、平日の日中の開催なので、もしかしたら都合の調整が必要かもしれません。興味のある方は早めに調整したほうがよいかもしれません。また、そのような最初の一歩を踏み出す人たちをサポートしてくれる「経験者」のみなさんの参加も募集しています！「経験」は一度でもバグレポートを出したりパッチを送ったりしたことがあれば十分です。どのようにサポートをすればよいかもワークショップ内ですべて説明するので事前準備も必要ありません。サポートする人が多いほどより多くの最初の一歩を踏み出す人たちを受け入れることができるので、協力よろしくおねがいします！ワークショップ情報開催日時：2026-08-05（水）10:00-17:00イベントページ： https://rubyassociation.doorkeeper.jp/events/196711参加費：無料会場：ギフティさんワークショップ終了後、ギフティさんのご厚意で無料で懇親会を開催します！ワークショップで一緒に最初の一歩を踏み出したみんなと交流したり、ワークショップで扱わなかったら関連する話題をまわりの人に聞いたりできます。ワークショップの内容ワークショップはOSS Gateワークショップという既存のワークショップをベースにしています。OSS GateワークショップはOSS一般を対象にしていますが、今回のワークショップはRubyに特化した内容にアレンジします。このあたりの調整はOSS Gateワークショップ

OSS Gateの立ち上げメンバーの一人の須藤です。気づいていなかったのですが、2025年12月15日でOSS Gate立ち上げ10周年を迎えていました。OSS Gateの立ち上げイベントを2015年12月15日に開催していたのです。ちなみに、広瀬さんと南さんと3人でOSS Gateを立ち上げちゃう？という話をしていたのが2015年の10月でその後にOSS開発に参加する人を増やす取り組み「OSS Gate」を開始を書きました。お祝いするタイミングを逃したと思っていたのですが、11周年を迎えるまでは10周年ということを教えてもらったので、11周年を迎える前に10周年イベントを開催します！日時は2026年10月3日（土）の13:30からで、場所は東京のアンドパッドさん（広瀬さんの現職）のオフィスで、イベント名は「OSS Gate Pass 2026」です！これまでの10年のOSS Gateの活動のおかげでなにかしらよいことがあった！ということを共有するイベントにしたいです。そんなエピソードを話してくれる・聞きたいという方はぜひイベントページから登録してください！OSS Gateをやってきてよかった、これからもやっていこうという気持ちになれるような時間にしたいです。トーク募集！今回のイベントは「これまでの10年のOSS Gateの活動のおかげでなにかしらよいことがあった！ということを共有」したいので、よくあるトーク主体のイベントになります。つまり、みなさんからのエピソードの共有がないと成り立たないのです！これまでOSS Gateでなにかよいことがあった人はぜひこのイベントで共有してください！Doorkeeperのコミュニティページを見ると1476人が過去になんらかの形でOSS Gateのイベントに関わっていそうです。そのくらいいるなら10-20人くらいはなにかよいことがあったと共有してくれそうじゃないかと期待しています！トークの応募はGitHubのissueで受け付けています。初めて話す人でも話しやすいようにトーク時間は10分を想定していますが、10分でも長い！という人は「5分でおねがいします！」とかとコメントに書いて教えてください。調整します。スポンサー募集！今回のイベントは東京で開催しますが、OSS Gateは北海道や関西など日本各地で活動してきました。そのため、遠方

クリアコードの代表取締役の須藤です。前職の仲間たちと一緒に立ち上げたクリアコードが今年の7月25日に設立20周年を迎えます。それを記念して20周年記念イベントを開催します！そんなクリアコードをお祝いしてくれるクリアコードファン（自称）のみなさんはぜひイベントにもお越しください！イベントページ： Connpass場所：さくらインターネットさんの東京支社のイベントスペース（新宿）開始日時：2026年7月29日（水）19:00さくらインターネットさん、会場提供ありがとうございます！clear-code.comの各種サーバーはさくらのVPSを使っています！どうして29日なのかやMeatupはtypo?とか仲間たちと立ち上げ？とか気になった人は世界の先駆者！？に聞いたOSS「肉の日リリース」の話を読んでみてください。イベントのメインコンテンツクリアコードは「フリーソフトウェアの推進とビジネスの両立」という他の会社とは結構違う判断基準をしながらも20年生き残ってきたのですが、本当にフリーソフトウェアを推進できていたの？とか世の中の役に立てていたの？とかを確認できるといいなぁと思っています。ということで！クリアコードの年表を閲覧したり、自分とクリアコードのイベント（このくらいのときにクリアコードとか関わったんだよなぁとか）を書き込めたりするシステムをクリアコードメンバーで作ります。年表システムは来月くらいからオンラインでも書き込めるようにする予定なので、イベントに参加できないクリアコードファンのみなさんも書き込んでください！年表システムの準備ができたら改めてアナウンスします。年表システムはクリアコードメンバーが普段触ったり触っていなかったりする技術をムダ使いして作るおもしろいものになる予定なのでお楽しみに！お祝いコメント募集中！年表システムとは別にクリアコードファンのみなさんからお祝いコメントを集めています！以下のどこからでもコメントできます。たくさん来るほど私が喜びます！GitHub: https://github.com/clear-code/anniversaries/issues/1GitLab: https://gitlab.com/clear-code/anniversaries/-/work_items/1Webフォーム： お問合せフォーム （「種類」は「その他」で

結城です。先だって、当社のThunderbirdサポートにおいてお客様から以下のようなお問い合わせを頂きました。Thunderbird 140.5.0ESRが複数のメールフォルダーについて、ダウンロード済みであるはずのメールを、毎日再ダウンロードする。その結果、ローカルのプロファイルフォルダーのサイズが1日あたり1～2GBずつ増加し、ハードディスクの空き容量が逼迫している。現象は特定のユーザーでのみ発生している。Thunderbirdのプロファイルを再作成して全メールを受信完了させた後でも、現象は引き続き発生する。メールサーバー側には特にエラーログは記録されていない。本稿執筆時点でも完全解決には至っていませんが、お客様のご協力を頂いての調査の結果、原因の一端と回避方法は判明しました。今回は、同様のトラブルでお悩みの方の参考になるよう、本件について現時点で分かっていることをご紹介します。はじめに：回避方法まず現時点で判明している回避方法を紹介しますが、その前に、「同様のトラブルで困っていて、とにかく回避方法を探している」という方に向けて、注意事項があります。今回のトラブルは、以下の条件で発生しています。条件が異なる場合は別の原因である可能性が高く、この回避方法は有効に作用しないと考えられます。当該メールアカウントの「サーバーの種類」が「IMAPメールサーバー」である。当該メールアカウントの「メッセージの格納形式」が「フォルダー単位（mbox形式）」である1。メールのダウンロードが何度も行われているフォルダーのプロパティを開き「一般情報」タブを見ると、「メッセージ数」は変化しておらず、「ディスク上のサイズ」の数字だけが増えている。この回避方法を実施した場合、「メール本文が途中で切れて見える」トラブルの発生頻度が上がる恐れがあります。安全のためには、社内LANのように安定したネットワークを経由してメールサーバーと通信できており、通信の意図しない途絶などが滅多に発生しない状況で使用するようにしてください。インターネットのように不安定なネットワーク経由でメールサーバーと通信している場合には、この回避方法は非推奨です。以上の事を踏まえての、本件トラブルの回避方法は以下の通りです。Thunderbirdの設定画面（メニューバーの「ツール」→「設定」、またはアプリケーションメニュー

結城です。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を使うことができれば、データ処理モジュールを実装するプロ