NaCl

NaCl松江本社の田中です。Ruby World Conference 2025が開催されました。まつもとゆきひろ基調講演「Rubyコミュニティの30年」と題して、1995年のRubyの公開から現在に至るRubyの歴史・コミニティの足どりをたどる講演でした。そして発表が終わりに近づいた頃「One more thing..」としてサプライズの発表がありました。スポンサーセッションスポンサーセッションではスモウルビープログラミング甲子園のWeb版の発表と開発に至る道のりについての発表をしました。Web版が追加されたことで、弊社の主催するスモウルビープログラミング甲子園の参加者がもっともっと増えることを期待しています！展示ブース弊社の展示ブースでは、スポンサーセッションで発表したスモウルビー甲子園Web版の展示を行いました。ブースに来られた方に実際にスモウルビー甲子園Web版を触ってゲームをプレイして、運営が用意したAIプログラムと対戦していただきました。プレイしていただいた方にはブロックエディタであるスモウルビーのブロックのチートシートや、デモで利用したソースコードは、後日公式サイトの方にアップされています。お知らせ:RubyWorld Conference 2025にてスモウルビー甲子園を展示しました最後にレポートした以外にも(私が聞きそびれたものも含めて)、たくさんの面白い講演がありました。また来年も Ruby World Conference の会場でたくさんの方とお会いするのを楽しみにしています！One more thing..その他、この記事では紹介しきれませんでしたが参加者のみなさんがイベントの様子をXにポストされたものを日付ごとにまとめました。ご興味ある方は是非ご覧ください！Day<=0 (~2025-11-05): https://posfie.com/@nishidayuya/p/U74SDL1Day1 (2025-11-06): https://posfie.com/@nishidayuya/p/lu4qJhKDay2 (2025-11-07): https://posfie.com/@nishidayuya/p/ruZyFL5Day>=3 (2025-11-08~): https://posfie.com/@nishidayuya/p/0Hgn6Xn

RubyWorldConference 2025 参加レポート

NaCl松江本社の多田納です。第3回 Matz葉がにロボコンというイベントが開催されました。私は当日スタッフとして参加してきましたので、大会の様子等をレポートします。当日は県内外から20名以上の参加者が集まりました。参加者のご家族なども観戦に訪れており、賑わいを見せていました。オープン部門の決勝では、中学生と高校生がお互いに一歩も譲らないデッドヒートに。熱い勝負の結果、なんと中学生が優勝するという結果になりました。Matz葉がにロボコンを通して、こどもたちがRubyやプログラミングの楽しさを感じている様子が伝わってきてとても嬉しく思いました。また機会があれば何らかの形で関わっていきたいと思います！

第3回 Matz葉がにロボコンに参加しました

NaCl東京支社の早川です。和菓子作り体験今回のレクリエーションでは現役の和菓子職人を講師としてお招きし、和菓子作り体験を行いました。島根県松江市の老舗和菓子屋　彩雲堂の光田さんです。今回私たちは練り切りと、きんとん作りに挑戦しました。初めに色のついた餡子が配られ、見本のお菓子と同じものを作ることを目指します。白い餡と桃色の餡を使ってグラデーションのかかった球体を作ります。　　三角ベラと呼ばれる道具で12等分の花びらを形作ります。これが難しい！最大の難所。みんな真剣です。最後に三角ベラの先端に彫られた型で、黄色い花芯を作れば完成です！光田さんの丁寧なレクチャーにより見事、美しい菊が完成しました！和菓子作り体験がひと段落ついた後、光田さんは「はさみ菊」と呼ばれる難易度の高いお菓子作りを実演してくださいました。菓子用のはさみを使って花びらを一枚一枚生み出していく様は、美しくも緊張感があり、全社員が静かに見守りました。光田さんはお菓子を作りながらご経歴や職人の修行についてお話しされました。宴会お菓子作り体験終了後、全社会議があり、その後は宴会です！食酒処 かわばたさんにお邪魔しました。乾杯の挨拶中。おいしいお料理と島根の地酒を堪能しました。2次会宴会の後はそれぞれ別の店に移動したり、ボードゲームをしたりして過ごしました。私は『キャメルアップ』というゲームに参加し、大変白熱しました！妨害を好むプレイヤー達レース終盤、ほとんどのラクダが重なってしまった様子。こうなると誰にも先の予想がつかない…他のテーブルでは『JUST ONE』や『マッチ売りの大富豪』をプレイしていました。みんな楽しそう！2次会は0時まで続き、大変盛り上がりました。まとめ昨年に続き、今年もオフラインでの全社会議を行うことができました。本社と支社のメンバーはなかなか顔を合わせる機会がないので、このような交流の機会があるととても嬉しいです。また来年も集まれるように、仕事を頑張るぞ～と思えました！

2025年度全社会議レクリエーション

NaCl東京支社の早川です。Kaigi on Rails 2025に参加しました。本記事では参加レポートとして、私の参加したセッションと感想をまとめました。Kaigi on Rails 2025Kaigi on Rails 2025は、東京のＪＰタワー ホール＆カンファレンスで開催されました。NaClもスポンサーとして参加しております！基調講演 dynamic!MOROHASHI Kyosukeさん(@moro)によるキーノートです。「動的（ダイナミック）」な開発の重要性を説いた発表でした。「ハッピーパス」から始めて段階的に機能を追加する考え方、フォース（コードを取り巻く「こうした方が良さそう」という感覚）に注意を払うこと、そして「最もシンプルで、うまくいきそうなもの」にする、といった内容が印象に残りました。変化を受け入れること、変化を楽しむことが重要であるというメッセージは、アジャイルマニフェストに通じる内容で、Railsの思想を再確認できる素晴らしい発表でした。参考情報スライド入門 FormObjectShu Oogawaraさん(@expajp)による、FormObjectを理解して向き合うことを目的とした、FormObjectの使いどころを体系的に整理した発表でした。具体的には「モデルを操作しない」「2個以上のモデル操作」「ライフサイクル処理の分割」の3パターンに分類して紹介されています。参考情報スライドRailsアプリケーション開発者のためのブックガイドMasayoshi Takahashiさん(@takahashim)による、Railsアプリケーション開発者におすすめの書籍紹介です。また、なぜ本を読むべきかという点にも触れられており、書籍は文化の継承、時間を超えて知識を共有できる優れたツールであると語られていました。紹介される本がどれも魅力的で、「本を読まねば！」と感じる内容でした。参考情報スライドあなたのWebサービスはAIに自動テストしてもらえる？アクセシビリティツリーで読み解く、AIの『視点』Yusuke Iwakiさん(@YusukeIwaki)による、AI時代のブラウザテスト自動化に関する発表です。重要なのはアクセシビリティツリーで、独自実装のアコーディオンやアイコンフォントなど、人間には問題なくてもAIには認識困難なパターンを実例で紹介されていました。アクセシビリティが単なる配慮でなく、AI自動テストの実用性に直結するという視点が新鮮でした。参考情報スライドRailsによる人工的「設計」入門Yasuko Ohbaさん(@nay)による設計を体得できない人を強制的に設計へ導く「逆算メソッド」の提案です。完成したシステムを先に想像し、ゴール（本質）を見定め、「それには何が必要か」を逆算的に考える、デザインパーツを仮置きしながら全体像を構築する、といった具体的な手法が紹介され、設計を教える側にも、知る側にも学びのある発表でした。ActiveRecordの関連やパラメータ構造など、デザインパーツを意識的に使いこなすことの重要性を再認識しました。参考情報スライド2重リクエスト完全攻略HANDBOOKShoheiMitaniさん(ShoheiMitani)による2重リクエストの回避に関する発表です。基本的にはサブミットボタン制御 + PRGパターン + 排他制御 + テーブル設計で十分なケースが多いが、発生時の被害とメリットを想定して適切なアプローチを選択すべきということでした。参考情報スライド履歴 on Rails: Bitemporal Data Modelで実現する履歴管理Makoto Chibaさん(@hypermkt)による履歴管理とBitemporal Data Modelの紹介です。ActiveRecord::Bitemporalというgemを使えば、複雑なSQLを意識せずRailsで実装可能だそうです。実際の運用課題（timestamp型からdate型への変更など）も紹介され、実践的な知見が得られる発表でした。参考情報スライド階層構造を表現するデータ構造とリファクタリング 〜1年で10倍成長したプロダクトの変化と課題〜Yuhi-Satoさん(@yuhi)による階層構造データによるパフォーマンス改善事例の紹介です。解決策として、全経路を保持するClosure Tableへ移行することで、最大931倍の高速化を達成できたそうです。Rails 7.2からのwith_recursiveによるRecursive CTE活用や、規模に応じた手法選択の指針が紹介され、学びのある発表でした。参考情報スライド非同期jobをtransaction内で呼ぶなよ！絶対に呼ぶなよ！Yuto Urushimaさん(@alstrocrack)による、『たまに謎の非同期jobエラーが起こる』、Rails非同期job実装の落とし穴に関する発表です。対策として、jobをtransaction外に記述、after_commit_everywhere gem利用、Rails 7.2以降のenqueue_after_transaction_commit設定の3つが紹介されました。enqueue_after_transaction_commitというずばりそのものな新機能を活用することで、チーム全体のコード品質向上につながるという、有益な知見が得られました。参考情報スライドドメイン指定Cookieとサービス間共有Redisで作る認証基盤サービス@kokuyouwindさん(@kokuyouwind)による、認証基盤サービスの実装方法についてのお話です。興味深いのはgem（leaner_authenticatable）による共通化です。各プロダクトでの認証ロジックの重複を排除し、設定を渡すだけで使える抽象化レイヤーを提供しているということです。参考情報スライドrails g authenticationから学ぶRails8.0時代の認証Shinichi Maeshimaさん(@willnet)による、Railsの認証ジェネレーターの解説です。生成されるコードを読み解きながら、has_secure_passwordの仕組み、bcryptによるパスワードハッシュ化、セッション管理の考え方など、認証の本質を学べる内容でした。「何を使えばOK」という答えはなく、継続的な学習が必要だという指摘は重要な視点だと感じました。参考情報スライド基調講演 Building and Deploying Interactive Rails Applications with FalconSamuel Williamsさん(@ioquatix)によるキーノートです。Ruby用Webサーバー「Falcon」に関する内容でした。Shopifyでの本番導入では1日300億リクエストを処理し、数千台のサーバー削減に成功したとのことでした。Active Recordのファイバーモード設定、Async Jobによる高速なバックグラウンドジョブ処理、HTTP/2対応のAsync Cable、systemdのプロセス準備プロトコルサポートやKubernetesでのデプロイ方法まで、実用的な内容が盛りだくさんでした。ライブコーディングでは、Claudeに『Kaigi on Railsゲーム』を作らせるデモが披露されました。参考情報FalconFalcon::Railsまとめ昨年に引き続き、今年も現地参加することができました。セッションで紹介された新しい取り組みやチャレンジに触れ、私自身も新たなことに挑戦したいという気持ちが強く湧いてきました。来年の開催も楽しみです！

Kaigi on Rails 2025の参加レポート

NaClの俵です。今年の本社インターンシップは5日間、2回での開催でした。インターンシップ概要今年度のインターンシップの題材は「Rails Tutorial で作成したWebアプリの機能追加」です。昨年と同じテーマですが、日数が半分なので、課題として取り組んでもらう部分をミニマムにしています。参加人数:1週目: 9名2週目: 8名日数: 5日間内容: Rails Tutorial で作成したWebアプリの機能追加以下のスケジュールで開催しました。去年の講義パートが好評だったので踏襲するようなスケジュールでの開催です。1日目: 自己紹介、インターン説明、開発環境構築、会社案内、ランチ会、Gitについての講義2日目: 開発3日目: 開発4日目: 開発、まつもとさんを囲む会5日目: 発表会、お茶会情報共有ツールとしてDiscordを利用しました。1日目段取りと感想まず、最初に自己紹介とインターンシップ概要です。今年は各週とも同じ学校から参加してくれた人も多く、初めから和気あいあいとした雰囲気でした。その後しばし休憩を挟み、本社の紹介と社長の前田より会社説明を行いました。初日の昼はアイスブレイク・社員との交流のためのランチ会を行いました。午前中のちょっとした時間では、私たちもインターン生同士もお互いに人となりまでは分かりません。午後からは開発環境構築とGitについて講義を行いました。インターン生の感想今まで使ってきたGitやGithubの仕組みについて整理がついてすっきりした。コンフリクトについて初めて知った。ブランチを分けて作業することの必要性が分かった。2日目段取りと感想今年は２日目からチームを分けて開発を行いました。各週で試行錯誤してみましたが、短い開発期間ではやはりメンバーの役割分担が上手くできるかが重要になるようです。その点で行くと今回のインターン生はみんな自然と分担ができていて、どのチームもすぐにうまく回るようになっていました。インターン生の感想たくさんエラーに遭遇したが、社員やチームメンバーに助けてもらって目標まで進められた。Railsアプリについて、構造と構文の面で知らないことだらけで難しかった。3日目段取りと感想１週目は３日目の午後からまつもとさんを囲む会を行いました。こちらについては２週目は４日目に実施したので、翌日の振り返りにまとめます。３日目の開発は、各週ともオリジナル機能の実装に本格的に着手していました。この頃になるとチーム内での意見交換や議論も活発になっており、よりチーム開発らしさが出てきた印象です。ところで、今回のインターンを通してのトピックとして、開発における生成AIの活用と難点が挙げられそうです。こちらとしてもAIが生成したコードを含めることを制限せず、またどのチームも少なからずAIを使用し、実際にスピード感のある開発を実現していたと思います。一方で、生成されたコードの内容を詳しく検分しないままコミットしてしまったチームもあり、結果として意図しない変更による大きな手戻りが発生したケースもありました。AIが質問の文脈についてどこまで把握しているか？生成されたコードを利用する場合、その正しさはどのように担保するか？...などなど、生成AIを開発に活用しようとする場合、利用する側の知識やノウハウも必要とされる場面が存在します。インターン生の感想簡単そうな機能でも、実際には考慮しなければいけない点がたくさんあることを実感した。オリジナル機能のための調査を通じて、昨日よりいっそう理解が深まっている。4日目段取りと感想４日目は引き続きオリジナル機能の実装です。サポートに入っていても、この数日間で彼らのRubyやRailsへの理解が深まっていることを感じさせてくれました。２週目は午後からまつもとさんを囲む会を実施しました。各週を通して多かったのは、AIについての話題です。またインターン生からの質問ということで、仕事としてのプログラミングへの携わり方という部分についても関心が向けられていました。質問と回答(抜粋)AIがプログラムを書けるなら、自分が今勉強していることは無駄になるのではと不安に思うAIの生成物を評価するための知識は必要AIには身体性が無いから困ることができない = 問題について自発的に改善の必要を見出せるのは人間だけRubyを使ったプロダクトが普及しているのを見るとどう感じる？自分のものではないが、誇らしさは感じる子どもの活躍を見ているような気持ちかも仕事でやりがいを感じたとき自分が携わった仕事が実際に世に出たときただし、何年も残り続けるものってそう無いからさみしくもあるどんな人と仕事がしたい？怒らない人同僚が怒られているのを見るだけでも能率が下がるという研究があるどんなSF作品が好き？テッド・チャンの『理解』が面白い！インターン生の感想まつもとさんからAIについての今後の予想を聴き、とても興味深かった。開発最終日になってようやくRailsに慣れてきた。読む力をもっと身に着けたい。5日目段取りと感想５日目、午前中に準備してもらい午後からNaCl社員にむけた一週間の成果発表をしてもらいました。実際、作業に当てられた時間で見ると非常に短い開発期間だったと思います。総じて、１週目・２週目ともに学生の能力の高さを実感し、私たちも感心させられ続けたインターンとなりました。成果発表会の後、お疲れ様の意を込めてささやかながらお茶会を催しました。ちなみにこのスケジュールは、例年終わり際があわただしくなっていたとのことから企画されました。参加者の声(抜粋)タスク難易度難しかったが、社員のサポートがあったのとチームとして取り組んだので達成できた。序盤の課題の時点で、前提となる基礎知識についてもっと解説が欲しかった。楽しかった・うれしかったことチーム開発が経験できたこと。並行して進めていた作業が合流して一つのものが完成した時がすごく楽しかった。自分のアイデアが実際に機能させることができたこと。不明点をすぐに質問できる環境だったので、安心して進められたこと。残念だったこと・期待と違ったこと期間が短く感じた。理解してきたと思った頃には終わりが来てしまった。リファレンスとして提供されたドキュメントに誤りがあったのは残念だった。社員との座談会のような、直接質問できる機会がもっと欲しかった。RubyやRailsについて、もう少し基礎から教えてほしかった。Links2023年インターンシップ2024年東京支社インターンシップ2024年松江本社インターンシップ

2025年度夏季インターンシップ in 松江本社

NaClの西田雄也です．中学生の長女が最近プログラミングに興味を持ったようで，娘らには言いませんがうれしい限りです．REDMINE JAPAN vol.4で登壇しました．REDMINE JAPAN vol.4は前回に引き続き，弊社NaClもSilverスポンサーをしておりました．発表公募の枠があったため， Redmine×Solid Queue: 安心簡単キュー構成として枠をいただき，おおむね次のようなお話をしました．RedmineでキューアダプターにSolid Queueを使う方法具体的な手順はredmine.orgのWikiに記載もっと簡単に導入するためのプラグインを作成発表資料は以下です．発表資料は発表直前にslide.rabbit-shocker.orgに上げていましたが，作成したRedmineプラグインのリポジトリーはREADME.rdocやinit.rbが bin/rails generate redmine_plugin したままの状態でした（詰めが甘い）．日曜にそのあたりを修正して，v1.0.0としました．拍手してほしいタイミングで拍手をうながすようなことも練習していましたが，無駄な練習であったと思えるぐらいに拍手をいただき，話しながら感動しておりました．ご来場の皆様，スタッフの皆様ありがとうございました．

REDMINE JAPAN vol.4で登壇しました #RedmineJapan

NaClの前田です。筆者が開発しているTextbringerというgemのリリースを rake bump コマンド一発でできるように先日自動化したのですが、少しはまったポイントがあったので記事にまとめます。前提Textbringerの開発はGitHubで行っているのですが、Trusted Publishingという仕組みでGitHub Actionsでgemのリリースを行うことができるため、もともとタグをpushした時にリリースできるようにしていました。タグをpushした時にリリースするワークフローただ、バージョン番号を上げるpull requestを作成して、マージ後にタグを作成してpushをする作業を毎回手でやるのが面倒になってきたため、手元で rake bump コマンドを実行するだけでバージョンを上げてリリースできるようにしました。rake bumpの実装lib/textbringer/version.rbに記載されているTextbringer::VERSIONをインクリメントして、GitHubへのpushとpull requestの作成を行うようにしました。task :bump do  require_relative "lib/textbringer/version"  version = Textbringer::VERSION.to_i + 1  puts "Bump version to #{version}"  system "git checkout main" or exit(1)  system "git pull" or exit(1)  system "git checkout -b bump_version_to_v#{version}" or exit(1)  File.write("lib/textbringer/version.rb", <<~EOF)    module Textbringer      VERSION = "#{version}"    end  EOF  system "git commit -a -m 'Bump version to #{version}'" or exit(1)  system "git push" or exit(1)  system "gh pr create --title 'Bump version to #{version}' --body ''" or exit(1)  system "git checkout main" or exit(1)endversion = Textbringer::VERSION.to_i + 1 というコードを見て大丈夫か不安になる方もいるかもしれませんが、TextbringerはLatestVerというバージョニングポリシーを採用しており、バージョン番号は1桁なので問題ありません。GitHub Actionsのワークフロー(失敗例)当初は以下のようなワークフロー(.github/workflows/tag_version.yml)を追加し、lib/textbringer/version.rbの変更がmainに入ったら v6 のようなタグを作成するようにしました。name: Tag versionon:  push:    branches:      - main    paths:      - 'lib/textbringer/version.rb'permissions:  contents: writejobs:  tag_version:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: k1LoW/github-script-ruby@v2        with:          script: |            require "./lib/textbringer/version"            repo = "#{context.repo.owner}/#{context.repo.repo}"            tag = "v#{Textbringer::VERSION}"            github.create_ref(repo, "refs/tags/#{tag}", context.sha)しかし、この方法ではタグは作成されるものの、肝心のTrusted Publishingのワークフローが実行されませんでした。GitHub Actionsのワークフロー(成功例)すべての処理を一つのワークフローで行ってしまえば他のワークフローをトリガーする必要はないので、 bump_version_to_v* というブランチが作成された時に以下の処理を実行してしまうことにしました。ブランチのオートマージ (gh pr merge --merge --auto "$PR_URL")タグの作成 (git tag "${tag_name}")gemのリリース (uses: rubygems/release-gem@v1)1はあらかじめオートマージできるようにリポジトリを設定しておく必要があります。修正後のワークフローは以下の通りです。.github/workflows/push_gem.ymlまとめ当初の目論見通りgemのリリースを自動化できました。GitHub Actionsではpersonal access tokenを使うなどしないと他のワークフローをトリガーできないので注意が必要です。バージョン番号なんて飾りです。偉い人にはそれがわからんのです。再修正(2025-06-05追記)上記でうまくいったと思ったのですが、pull requestのブランチ上でタグを作成したことで、pull requestのマージ後にブランチが削除されてタグがリポジトリ上のどのブランチにも所属しない状態になり、そのせいかGitHub Releasesのドラフトを作成する時に直前のバージョンからの差分ではなく最後にmainからタグを作成してリリースしたバージョンからの差分になってしまったため、GitHub Actions上でのタグ作成はあきらめてローカルで作成するようにしました。task :bump do  require_relative "lib/textbringer/version"  version = Textbringer::VERSION.to_i + 1  tag_name = "v#{version}"  puts "Bump version to #{version}"  sh "git checkout main"  sh "git pull"  File.write("lib/textbringer/version.rb", <<~EOF)    module Textbringer      VERSION = "#{version}"    end  EOF  sh "git commit -a -m 'Bump version to #{version}'"  sh "git push"  sh "git tag #{tag_name}"  sh "git push origin #{tag_name}"endもともとpull requestにしていたのはオートマージを有効にしてmainへのpushを禁止していたからなのですが、RulesetのBypass listにRepository adminを追加して自分はmainにpushできるようにしてしまいました:(

gemのリリースを自動化する

NaClの西田雄也です．RubyKaigi 2025に関するXのポストについて，日付・部屋ごとにまとめました．posfieでまとめております．URLはそれぞれ以下です．Day1 (2025-04-16)Main Hall (#rubykaigiA)Sub Hall (#rubykaigiB)Pearls Room (#rubykaigiC)Day2 (2025-04-17)Main Hall (#rubykaigiA)Sub Hall (#rubykaigiB)Pearls Room (#rubykaigiC)Day3 (2025-04-18)Main Hall (#rubykaigiA)Sub Hall (#rubykaigiB)Pearls Room (#rubykaigiC)セッション外Day<=0 (~2025-04-15)Day1 (2025-04-16)Day2 (2025-04-17)Day3 (2025-04-18)Day>=4 (2024-04-19~)

RubyKaigi 2025のXポストまとめ

2025年4月16日(水)～2025年4月18日(金)に開催されたRubyKaigi 2025に本社からは井上、まつもと、前田、高尾、西田、高田、原、佐田、岸野が、東京支社からは後藤、小倉、早川が参加しました。基調講演まつもとTRICKまつもと、原LT前田Ruby Committers and the Worldまつもと、前田、後藤この記事では小倉、高田、佐田、早川がそれぞれが印象に残ったセッションの感想をお届けします。初日のLunch Breakに集合写真を撮影しました。RubyKaigi会場でのNaClメンバーの集合写真は中々レアな気がしますね。(撮影時にいなかった原は後ほど1人で撮影して合成しています。最近の加工技術はすごいですね！)1日目楽しみすぎて会場が開く前についてしまった小倉は初日から道後温泉まで散歩してきました。会場と道後温泉が近くてとてもよいロケーションでした。Ruby Taught Me About Encoding Under the Hoodmari imaizumiさん によるキーノートです。文字コードの歴史の話から始まり、Unicodeの課題と解決策に焦点を当てた話へと続きました。現在@ima1zumiさんはRubyコミッターになり、RubyでのUnicode15.1.0と16.0.0への対応作業を進めており、Unicode正規化への対応が今後の課題であるというお話でした。見た目は1文字なのに実際は7つのコードポイントで構成される家族絵文字を例に、書記素クラスタの概念の説明と修正にいたるまでの流れが説明され、Unicodeの奥深さを感じられるキーノートでした。参考情報スライド(早川)Automatically generating types by running testsTakumi Shotokuさんによる自作のRBS::Traceについての発表でした。 RBS::Traceはテストを実行するだけでrbs-inline形式の型定義を自動で追加してくれるものです。rbs-trace mergeで結合することもできるそうです。参考情報スライド(小倉)Goodbye fat gem 2025Sutou Kouheiさんによる、Fat Gemへの問題提起のお話でした。Fat Gemには以下の3つの問題があると述べられました。最新のRubyへの対応遅延: Fat Gemは新しいRubyバージョンごとに更新が必要で、一つでも対応していないFat Gemがあると最新Rubyが使えない状況になるセキュリティリスク: 特にバインディング系のFat Gemは依存ライブラリも含むため、脆弱性が見つかった場合、Fat Gem作者の更新を待つしかないメンテナンスの負担: 開発者は44種類もの環境に対応したFat Gemを作成・メンテナンスする必要があり、メンテナンスコストが非常に高い解決策として「RubyGem Requirement System」という新しいGemを作成したことが紹介されました。発表の中では、Gem開発者の負担を減らすことでよりよいエコシステムを考えるという事を、開発者だけの問題ではなく、Gemを使う側の人たちも考えなければならないというメッセージが伝えられました。参考情報スライド(早川)State of NamespaceNamespaceの開発者の Satoshi Tagomori さんの発表でした。RubyKaigi 2024 から RubyKaigi 2025 までは不具合修正を主に作業されてきたとのことです。最初に Namespace の説明で、グローバルから分離された名前空間に変更されたというお話しがありました。グローバルな名前空間: Ruby のプロセス内で全てのクラス/モジュールが共有分離された名前空間: apps/libs を分割された名前空間にする上記の変更をするため、Ruby の RClass と rb_classext_t に変更をおこない、各 Namespace で classext のシャローコピーするようにされたそうです。また、複数の Namespace で同じ拡張ライブラリを dlopen で読み込もうとすると、一度しか読み込まれないため、拡張ライブラリをコピーして別ファイルとして読み込むことで対処されたそうです。参考情報スライド(佐田)TRICK 2025: Episode I一日目の最後が TRICK(Transcendental Ruby Imbroglio Contest) でした。難解プログラミングのコンテストにもかかわらず開始時刻が近づくとメインホールに続々と参加者が集まり、スタッフから満員が予想されるので席を詰めてくださいと声がかかりました。TRICK では puts 'Hello, World' のように単に 'Hello, World' を出力するのはダメなコードと言われます。例えば 'Hello, World' をアスキーアートにしたり趣向を凝らすのだそうです。難解プログラミングの練りこまれたアイデアを実装したコードが評価されるコンテストです。セッションでは、TRICK 2025 の応募作品の中から高得点を獲得した受賞作品が発表されました。弊社のまつもと、原が審査員として登壇しました。プログラムに "Feel, don't think." と書かれていますが、TRICK の楽しみかたの解説がありました。TRICK の楽しみかた実行する眺める読み解く今回、mame award: "Most shifted" (もっともズレているで賞)を受賞した弊社、原の作品で試します。原の作品を実行すると、画面に表示される文字が動きズレていきます。コードを眺めますが、読めません。会場でコードの読み解きがありました。メソッドがズレているようですが、原は満足そうです。Ruby のソースコードの sample ディレクトリには過去の TRICK の受賞作が同梱されています。TRICK 2025 の受賞作もバージョン 4.0 になるかもしれない次の Ruby のリリースにサンプルとして同梱されるそうです。参考情報tric/trick2025(佐田、高田)2日目前夜の Official Party の余韻も感じつつ 2 日目が始まろうとする会場です。Dissecting and Reconstructing Ruby Syntactic Structuresparse.yとLramaのメンテナでLR Parser GANGSのydahさんによる文法規則の構造を再構築することでparse.yの保守性を向上させたお話でした。コードの重複の除去再利用性の向上保守性の向上可読性の向上今後はさらに整備していき将来の拡張がやりやすくなるよう活動を続けられていくそうです。複雑なパーサーに挫けず共通化を進めていく姿勢がかっこいいです。関西Ruby会議08を開催されるそうです。楽しみですね！参考情報スライド(小倉)Writing Ruby Scripts with TypeProfRubyのフルタイムコミッタで、TRICKの審査員の Yusuke Endoh さんの発表でした。型システムのしくみ ― TypeScriptで実装しながら学ぶ型とプログラミング言語」が販売されることについてご紹介がありました。IRB宝探しについてもご案内がありました。TypeProf は Ruby Editor Support で幾つもの機能(エラーレポート、定義ジャンプ、アノテーション、など)が提供されているとのことです。今回はユースケースへのためにおこなわれた改善や不具合修正について説明がありました。diagnostic_severity: TypeProf のレポートのエラーレベル("error", "warning", "info", "hint")を変更analysis_unit_dirs: 各指定ディレクトリで解析を分けるように設定Ruby の定数参照が複雑なため、型指定を型推論で全て自動生成するのは難しいので、自動生成するのと手動で書いていく両方が必要では、というお話しもありました。参考情報スライド型システムのしくみ ― TypeScriptで実装しながら学ぶ型とプログラミング言語IRB宝探し(佐田)MicroRuby: True Microcontroller RubyPicoRubyの開発者の Hitoshi HASUMI さんの発表でした。また、プロジェクトの開発はまつもとさんからメンタリングを受けながら進めているとのことです。PicoRuby と MicroRuby は、以下のような構成で動作しているそうです。PicoRuby: picoruby-compiler + mruby/cMicroRuby: picoruby-compiler + mruby上記のような構成のメモリ消費を比較した場合、一般的に mruby の方が mruby/c よりも多くメモリを消費すると言われているとのことです。puts 'Hello, World' のような単純なコードではなく、実際のプロダクトに近いコードで比較した場合には、そこまで大きな差が生まれないのではという仮説を考えて確認されたそうです。R2P2+PicoRuby: 78KBR2P2+MicroRuby: 109KBその結果、R2P2 on MircoRuby が現実的なメモリ消費で動作するようになったとのことでした。参考情報スライド(佐田)Making TCPSocket.new "Happy"!shioimmさん による Happy Eyeballs Version 2 (RFC8305) (以下、HEv2) の Ruby のソケットライブラリ Socket.tcp と TCPSocket.new への実装の発表です。HEv2 は IPv4 と IPv6 のデュアルスタック環境で速やかに TCP コネクションを確立するための仕組みです。前回の RubyKaigi 2024 で Ruby で書かれた Socket.tcp への HEv2 の実装を発表されたのに続けて、その後の1年になされた Socket.tcp の再実装と C で書かれた TCPSocket.new への HEv2 の実装が報告されました。Socket.tcp を再実装したのは、IPv6 で接続する状態、IPv4 で接続待ちなどの状態遷移に実装が寄り過ぎだったためで、再実装の結果、よりシンプルな実装になったそうです。また、Ruby による Socket.tcp の実装をベースにしつつも、C で書かれた TCPSocket.new への HEv2 の実装にあたり対処された C に固有の問題が報告されました。そして、Ruby 3.4 に TCPSocket.new の HEv2 の実装が取り込まれるタイミングで Rubyのコミッターとなられた経緯を紹介されました。Ruby Comitters and the World で舞台の上のコミッターと客席の距離は思っているほど遠くないと客席の参加者を作る側に誘っていたのと同じようなメッセージを感じました。参考情報スライド(高田)Lightning Talks弊社の前田が LT に登壇しました。Textbringer は前田が開発する Ruby で動く Emacs-like なテキストエディタです。初日の mari imaizumiさん の基調講演とつながる LT で、文字を正しく表示したり編集する大変さを感じました。参考情報shugo/rubykaigi2025lt(佐田、高田)Agileware Drinkup at RubyKaigi 2025一部のメンバーはアジャイルウェアさんの Drinkup に参加しましたが、Zigによる拡張ライブラリの作成についてLTで西田が発表しました。参考情報スライド(佐田、高田)3日目3日目にもなると大分疲れてきますね。。、ANDPADさんブースのコーヒーがとてもありがたかったです。The Ruby One-Binary Tool, Enhanced with KompoahogappaさんによるKompoの改善に関する発表です。以前の実装では、requireをオーバーライドする方法を採用していましたが、これにはいくつかの問題がありました。オートロードとの相性が悪く、例外が発生することがあったユーザーが任意のタイミングで埋め込まれたファイルを取り出せなかったディレクトリ構造を含む階層的なデータ構造に対応できなかったこれらの課題を解決するため、新しい実装では以下のアプローチを採用されました。バイナリ内に仮想ファイルシステムを構築実ファイルシステムとバイナリからの読み込みを切り替える機能の実装これにより、Railsのような大規模なRubyプロジェクトもワンバイナリ化できるようになったそうです。現在は追加インストール不要という部分は対応済みで、クロスプラットフォーム対応などは今後の課題となっているそうです。Rubyがワンバリナリ化されてどこでもポチっと起動するだけで動く、というのはとても魅力的だと感じました。クロスプラットフォーム対応されることでどこでもRubyスクリプトが動くようになるというのも、とてもワクワクするお話でした。参考情報スライド(早川)Toward Ractor local GCRubyのフルタイムコミッタでRactorの開発者である Koichi Sasada さんの発表でした。現在の Ractor は、各 Ractor が独立したオブジェクト空間を持ち、他の Ractor はそのオブジェクト空間に対してアクセス(read/write)できません。ただし、全ての Ractor は並列処理で実行されているため、並列処理でそのような共有可能なオブジェクトの参照状態を保つのが難しいとのことです。最後にベンチマークの性能改善の結果をグラフで表示しながら紹介されました。参考情報スライド(佐田)Porting PicoRuby to Another Microcontroller: ESP32Yuhei Okazakiさんによる、発表です。ライブラリ作成、プロジェクトビルド、標準入出力対応、mrbgemをESP32向けにポーティングという手順を踏むことでESP32への移植が実現されたそうです。今回解説された移植の手法は他のマイコンにも応用可能ということで、Rubyの世界が広がる可能性を感じる発表でした。これをきっかけにマイコンに入門するRubyistも増えるのではないでしょうか。参考情報スライド(早川)Programming Language for AI age最後の基調講演は まつもとさん でした。最初に、「次の RubyKaigi の開催地を事前に知っているのでは？」と尋ねられるけれど基本的に事前には知らないとのことでした。今回の基調講演のテーマに AI を選んだのは、AIの話題が世界を席巻している中で今回の RubyKaigi に AI をテーマにする講演が見当たらなかったからだそうです。まず AI には得意なことと苦手なことがあり、AI は決められたことを実行するのが得意だが、仕様などが決められていないことをするのが苦手な印象を持っているそうです。以下のような Alpha Syndrome を例に挙げて、AI の苦手なことを人が代わりにやっているうちに、AI が人の主人のようになり、Ruby が大事にするプログラミングの楽しさを見失うことになるのではないか懸念している。何を任せて何を自分たちでやるか考えるときでないかと語られました。Alpha Syndrome: 犬を大事にし過ぎると、犬が自分を群れのリーダー(アルファ)だと勘違いして吠えたり噛んだりするようになる。Reverse Alpha Syndrome: できないことをやっているうちに上下関係が逆転してしまう。Ruby の開発は楽しさのためにしているそうです。講演は言語の話に移っていき、数学が自然言語よりも簡潔かつ論理的で数学の記述に適していたから発展したように、コンピューターに指示を与えるには自然言語は冗長すぎるので、プログラミング言語が発展したことを挙げてから、AIの時代には人間がプログラムを書き、AI がプログラムを書き、互いにプログラムを修正すると続けました。そして、静的型があれば型チェックで間違いを検出できるが、静的型を持っていることが本当に必要だろうかと問いかけ、論理のミスや仕様のミスが重要で型エラーはあまり重要でないという見方もあると語りました。AI が簡単な型の間違いをするか考えると、AI が適切に処理することで静的型の重要性は下がるのではないか。AI 時代のプログラミング言語にとって Concise(簡潔)であること、Expressive(表現力)があることや Extendable(拡張性)があることが重要だと考えると、どこかで聞いたことがある感じで牽強付会かもしれないが、Ruby は AI の時代に合う言語ではないだろうかと Ruby の未来を語りました。また、最後に多分 Ruby 4.0 をリリースすると発表がありました。 (佐田、高田)TOKIUM & mybest Drinkup at RubyKaigi 2025 Day3一部のメンバーは TOKIUMさんとマイベストさん合同の Drinkup に参加して、LTで西田が発表しました。西田はRabbit に変更を加え、LT で音を鳴らして盛り上げました。参考情報スライド(佐田、高田)感想RubyKaigi は活気に満ちていました。たくさんのセッションを聞き、そして RubyKaigi だから会うことができた方々と話すことができました。RubyKaigi は想像以上でした。(高田)Ruby の開発の最新情報を知ることができて楽しかったです。(佐田)大分久しぶり(10年ぶりぐらい？)のRubyKaigiでした。新人のころに一緒にお仕事をした方に再会できたりオンラインでしか会ったことのない方にリアルでお会いできたり、またRubyistの熱量に触れることができ自分も何かをしたくなってくるとても楽しいイベントでした。(小倉)2年ぶり2回目の参加でした。前回はまったく何もわからない…という状態だったのですが、今回は入念に予習をしたおかげもあり、セッションを興味深く聞くことができ、とても楽しかったです。(早川)今年もインターンシップやります！今年もインターンシップをやります！、ということでスポンサーブースにあるノベルティ置き場にチラシを置かせていただいていました。まつもとさんとの交流会もあるので学生のみなさんこちらからエントリーよろしくお願いします。

RubyKaigi 2025参加レポート

NaClの佐田です。本記事では、スモウルビープログラミング甲子園2024 決勝大会の開催日の様子についてまとめました。スモウルビープログラミング甲子園2024とは以前、島根県さんの主催で「スモウルビープログラミング甲子園」というプログラミングコンテストが開催されていました。しかし、コロナ禍等の影響もあり2020年を最後に休止となっていました。スモウルビープログラミング甲子園2024は、学生ならば誰でも参加できるプログラミングコンテストです。マップ上には複数のアイテムやトラップがあり、対戦相手のキャラクターよりも多くの加点アイテムを集めてゴールできれば勝利となります。より詳しく知りたい場合は、公式マニュアル がありますので、そちらをご参照ください。以下は開催情報です。学生さんにとっては嬉しい賞金額ですね。スケジュール予選大会： 2025年1月16日(木)決勝大会： 2025年3月20日(木・祝)参加資格20歳以下（2004年4月2日以降生まれ）の学生応募期間2024年7月1日～2025年1月15日各賞・副賞優勝： 副賞 10万円準優勝：  副賞 5 万円第3位： 副賞 1 万円特別賞： 副賞 3 万円予選大会多数の参加申し込みいただき、大変ありがとうございました。予選大会はNaCl社内で行いました。応募されたAIプログラムを運営が用意したAIプログラムと複数回対戦させ、高得点を獲得した上位24組が決勝進出となりました。決勝大会の準備スモウルビープログラミング甲子園2024 決勝大会の当日、会場となる松江オープンソースラボにて準備をしました。会場のスクリーンやモニターへの映像を映して、インタビューでのZoomやYouTubeの配信の準備をしました。1回戦、2回戦1回戦、2回戦は進行の都合で試合時間を短く抑える必要があり、ハイスピードで対戦が進んでいきました。運営スタップとしては、配信のための映像・音声の切り替えや、試合ごとにAIプログラムや対戦マップの切り替えなどを行いました。予選大会では順位が低かったAIプログラムが、高い順位のAIプログラムに決勝大会で勝つという番狂わせもあり、会場の見学席は盛り上がりました。会場では、勝敗がきまるたびにトーナメント表をリアルタイムで更新していきました。準決勝準決勝になると1ターンの時間も長くなり、じっくり対戦が楽しめるようになりました。例えば、減点アイテムを避けつつ加点アイテムを取得できるよう、ダイナマイトで効果的に壁を壊していくAIプログラムが現れました。3位決定戦、決勝3位決定戦、決勝の試合はどちらもトーナメントを勝ち抜いてきた優秀なAIプログラムの試合となり、ハイレベルな戦いとなりました。結果発表スモウルビープログラミング甲子園2024 決勝大会の結果、以下のチームが表彰されました。優勝： minorex17準優勝： ねぶた祭りの申し子第３位： 残業団特別賞： 島根県立情報科学高等学校　松代慧斗実行委員長から表彰があり、今大会の総評が述べられましたYouTubeによる配信決勝大会はYouTubeで配信しました。ぜひ決勝大会の模様をご覧ください。YouTube