2026-08-04（火）に開催されるRuby Association Activity Reportでpure Ruby Apache Arrow実装の活用方法という話をする須藤です。2025年度Rubyアソシエーション開発助成金プロジェクトとして開発したpure RubyのApache Arrow実装の成果報告です。本編の参加は無料（懇親会も参加する場合は有料）なので、興味のある人は参加してください。まつもとさんの基調講演や他の開発助成金プロジェクトの成果報告もあります。 pure Ruby Apache Arrow実装の活用方法 関連リンク：イベント（Ruby Association Activity Report）スライド（Rabbit Slide Show）リポジトリープロジェクトの成果このプロジェクトでは、低コストでのデータ交換のみにフォーカスしたpure RubyのApache Arrowシリアライザー・デシリアライザーを実装しました。成果物は次の2つです。pure RubyのApache Arrow実装：red-arrow-formatpure RubyのFlatBuffers実装：red-flatbuffersApache ArrowフォーマットはFlatBuffersを使っているのですが、FlatBuffersのRuby実装がなかったのでFlatBuffersの実装から作りました。最初はFlatBuffers本体に取り込んでもらおうと思ってコード生成部分はC++で実装していたのですが、取り込んでもらえなそうだったので、Rubyで実装し直しました。FlatBuffersのデータは効率のよいバイナリー形式で、スキーマはテキスト形式で書きます。たとえば、Apache Arrowなら https://github.com/apache/arrow/blob/main/format/Message.fbs がテキスト形式で書かれたFlatBuffersのスキーマの1つです。FlatBufersのデータを扱うときは、スキーマからそのスキーマを扱うコードを生成してそれをライブラリーとして使ってデータにアクセスします。たとえば、 https://github.com/apache/arrow/blob/main/format/Message.fbs から htt

去る7月21日、Firefoxの法人向け長期サポート版であるFirefox ESR1の新しいメジャーバージョンである「Firefox ESR153（153.0）」がリリースされました。1つ前のメジャーバージョンとなるFirefox ESR140のサポートは、10月13日に終了する予定となっています。Firefox ESRは現在、ESR153とESR140の2つのバージョンが存在しており、8月18日には、それぞれのセキュリティアップデート版であるESR153.1とESR140.14がリリースされる見込みです。ESR140のサポートは依然継続していますが、前述の通り10月13日にはサポートが終了するため、それまでの間にESR153へ更新することが強く推奨されます。当社では、Firefox ESR140からESR153の間の変更点のレポートを公開しており、このレポート中では10のカテゴリーに分けて、法人利用に影響が及ぶと考えられる変更点を詳細に紹介しています。この記事では、その中で特に影響度が大きいと考えられる項目を抜粋してご紹介します。Firefox ESR140からESR153の間の変更点（抜粋）全般Firefox Home（新しいタブを開いたときの空のタブ）の内容が一新され、壁紙のカスタマイズが可能になった（Firefox 145）ほか、天気予報などのウィジェットを表示可能になりました（Firefox 146）。天気予報は Preferences ポリシーで browser.newtabpage.activity-stream.widgets.system.weather.enabled を false にすることで無効化できます。全般的なウィジェット機能自体は Preferences ポリシーで browser.newtabpage.activity-stream.widgets.enabled を false にすることで無効化できます。分割ビュー2機能により、1つのウィンドウ内に2つのページを並べて表示できるようになりました。分割ビューを作るには、タブの上で右クリックメニューを開いて「分割ビューを追加」を選ぶか、タブを2つ選択した状態で右クリックメニューを開いて「分割ビューで開く」を選択する（Firefox 149）か、任意のリンクを右クリックしてメニューから

今月29日開催のクリアコード20周年記念Meatup（参加申し込みページ）に向けて準備を進めている結城です。クリアコード年表で使用可能なOutlook用のOfficeアドインに続いて、Thunderbird用のアドオンも作ってみましたので、こちらで紹介いたします。今回作成したThunderbird1アドオン2「CC 20th Anniversary Timeline」（以下「年表アドオン」）は、「クリアコード年表3へのイベントの投稿操作」を補助するものです。具体的には、公開のWebページのURLをアドオンに渡すと、その記事の内容を要約したテキストを伴ったイベント投稿画面が自動的に開かれて、そのままイベントを投稿できます。このククログの記事やプレスリリースなど、既存のWebページを手がかりに年表を充実させる役に立つはずです。インストールThunderbirdのアドオンは一般的にはThunderbird Add-onsからダウンロード・インストールしますが、年表アドオンはこちらのサイトには掲載していません。クリアコード年表のリポジトリーにXPIパッケージを含めてあるので、以下のリンク先のページからファイルをダウンロードして下さい。cc-20th-anniversary-timeline-we.xpiその後、Thunderbirdのアドオンマネージャーにファイルをドラッグ＆ドロップすればインストールできます。また、このアドオンでは、記事の要約を自動生成するためのバックエンドとしてOllama経由でローカルLLMを使用します。未導入の場合は、以下のリンク先の説明に従ってOllamaをインストールして下さい。Windowsではインストーラーからのインストールがお勧めです。Ollamaのダウンロードページ初期設定Ollama用の言語モデル（LLM）のダウンロード新規にOllamaをインストールした場合は、別途言語モデルのダウンロードも必要です。Ollamaは言語モデルをローカルで動かすための仕組みだけを提供しており、その脳味噌である言語モデルは都度ダウンロードしなくてはなりません。Windows版Ollamaの場合はコマンドプロンプトを、それ以外の環境の場合は端末エミュレーターを開いて、ollama pull 言語モデル名 という書式でコマンドを実行すれば、指定した言語モデルの

今月末に、クリアコード20周年記念Meatupが開催1されます。設立20周年を記念するこのイベントではクリアコード年表公開！#cc20thとアナウンスがあったように、コンテンツの1つとして「クリアコード年表」というアプリを公開しています。「クリアコード年表」は、クリアコードが設立以来どのようにフリーソフトウェアとビジネスを両立してきたかを、タイムラインで表示するものです。今回、クリアコード年表アプリの機能の一つとして、年表アプリをOutlookのアドイン化して、Outlook上で表示できるようにしましたので、導入方法についてご紹介します。OfficeアドインとはOutlookのOfficeアドイン開発を紹介したククログ記事でも紹介していますが、Officeアドインとは、マニフェストファイル（XMLまたはJSON形式）+ Webアプリで構成された、Microsoft Office向けのアドインです。マニフェストファイルおよびWebアプリは以下の役割を果たします。マニフェストファイルアドインのメタデータ、UIの拡張ポイント（リボンボタン等）、WebアプリのURLを定義Webアプリ実際の動作のロジックを提供HTTPSサーバー上にホスト内容はHTML/JavaScript/CSSなどで一般的なWebアプリとして作成Office.jsを使い、Officeの操作を行うOfficeクライアントはマニフェストファイルを読んで、指定されたWebアプリをロードし、実行します。クリアコード年表アドインでは、クリアコード年表アプリのサーバー上にアドイン用のWebアプリもホストしています。Outlookへクリアコード年表アドインをインストールする以下の手順でOutlookへクリアコード年表アドインを追加できます。メールサーバーはオンプレミス版のExchange Server、Microsoft 365を含むクラウド版のExchange Onlineのいずれかである必要があります。インストール方法マニフェストファイルをダウンロードします以下のURLにアクセスし、マニフェストファイル（cc-20th-anniversary-timeline.manifest.xml）をダウンロードしますhttps://20th.clear-code.com/cc-20th-anniversary-timelin

オープンソースのロボットアームであるOpenArmの開発をお手伝いしている須藤です。Meta Quest 3やPICO 4といったVRデバイスを使ってOpenArmを遠隔操作したいというニーズがあります。現在はMeta Quest 3用の遠隔操作アプリを提供していますが、PICO 4でも遠隔操作したいという要望やらなんやらがあるのでWebXRベースの遠隔操作アプリを試作しました。今回はじめてWebXRを触ったのですが、いろいろ学んだことがあったのでまとめておきます。WebXRWebXRはWebブラウザー上でVR（仮想現実、Virtual Reality）やAR（拡張現実、Augmented Reality）を実現するためのJavaScript用のAPIです。VRやらARやらをまとめてXRと呼んでいます。多くのXRアプリケーションは3Dのなにかを描画しますが、OpenArmの遠隔操作アプリはVRデバイスのコントローラー（Meta Quest 3ならこういう手に持つやつ）でOpenArmを動かしたいだけなので3Dのなにかは描画しません。（将来的にはOpenArmについているカメラの画像とかを描画したくなるかもしれませんが、現時点では描画しません。）VRデバイスのコントローラーの情報をリアルタイムで取得できれば十分です。WebXRでは3Dのなにかの描画もVRデバイスのコントローラーの情報の取得もできますが、今回は後者のAPIだけを使いました。https://developer.mozilla.org/ の情報とW3CのImmersive Webワーキンググループが提供するサンプルと実機での挙動を参考にしながら開発を進めました。WebXRを使うために必要なこといくつか動かすまでに知らないといけなかったことがあったので、まずはそれらについてまとめます。HTTPSWebXRを使うためにはHTTPSが必要です。手元で動作確認する場合、ruby -run -e httpd -- --bind-address 0.0.0.0などでローカルにWebサーバーを立ち上げてJavaScriptを配信することが多いと思いますが、これではWebXRを使えません。HTTPSではなくHTTPだからです。私は最初は既存のHTTPSサーバーを使って実験していました。具体的には https://www.c

オープンソースのロボットアームであるOpenArmの開発をお手伝いしている須藤です。OpenArmのデータ収集データフローと推論データフローはdoraを使っています。（もう半年くらい前になりますが）doraベースのデータフローの初期設計をしたのでなにを考えて設計したかを記録しておきます。データフローデータ収集や推論などといったタスクは単一のプログラムとしても実現できますが、データフローとしても表現できます。たとえば、ロボットを遠隔操作して学習用の教師データを集めるデータ収集タスクは次のように分解できます。人が遠隔操作用デバイスを動かして動作命令を出力1.の情報を受け取ってロボットを動かすロボットの今の状態を出力1.と3.の情報を記録人→遠隔操作用デバイス→ロボット→記 ーーーー→録データフロー内では、矢印の両端にいるもの（「人」や「遠隔操作用デバイス」）がノードで行動主体になります。矢印がデータフロー内でのデータの移動になります。専用のプログラムでこのようなタスクを実現することもできます。実際、OpenArmのデータ収集処理・推論処理の初期実装ではそうなっていましたし、フィジカルAIの便利ツールLeRobotでもそうなっています。（lerobot-recordというツールが提供されています。）専用のプログラムで実現するメリットは、自由度が高く、柔軟に処理を実現できることです。一方、変更するにはプログラムを変更する必要がでてきて、専用のプログラム固有の知識が要求されることがデメリットです。もちろん、よく変更したくなる箇所はコマンドラインオプションや設定ファイルでカスタマイズできるようにすることでこのデメリットを軽減できます。一方、このような処理を一般的なデータフローとみなして、汎用的なデータフローツール上で実現する方法もありえます。この方法のメリットは、汎用的なデータフローツールの知識を再利用できることおよび汎用的な処理をせずにすむことです。デメリットは汎用的なデータフローツールの制限に設計が左右されることです。たとえば、カメラで撮った画像も学習データとして記録したくなったとしましょう。人→遠隔操作用デバイス→ロボット→記 ーーーーー→ カメラ→録専用のプログラムの場合は、カメラから画像を取り出す機能を実装して組み込みます。データフローツール上で実現する場合は、すでに

今月末に、クリアコード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ワークショップ