NaCl

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

スモウルビープログラミング甲子園2024 決勝大会の開催レポート

NaCl東京支社の小倉です。OSSパッチ会の成果一覧RedmineUniqueness of Project model fields is not checked sufficiently で提案したパッチが採用されました。https://www.redmine.org/projects/redmine/repository/svn/revisions/23407"Import issues" and "Import time entries" pages are visible to users without "Add issues" and "Log spent time" permissions で報告したバグ修正が取り込まれました。https://www.redmine.org/projects/redmine/repository/svn/revisions/23178www.ruby-lang.orgRuby公式サイトのニュースの翻訳を行いました。CVE-2024-27282: Arbitrary memory address read vulnerability with Regex searchとRuby 3.0.7、3.1.5、3.2.4、3.3.1のリリースニュースの翻訳が取り込まれました。https://github.com/ruby/www.ruby-lang.org/pull/3236Ruby 3.4.0-preview1のリリースニュースの翻訳が取り込まれました。https://github.com/ruby/www.ruby-lang.org/pull/3310CVE-2024-49761: ReDoS vulnerability in REXMLのニュースの翻訳が取り込まれました。https://github.com/ruby/www.ruby-lang.org/pull/3414Ruby 3.2.6のリリースニュースの翻訳が取り込まれました。https://github.com/ruby/www.ruby-lang.org/pull/3415Ruby 3.1.6のリリースニュースの翻訳が取り込まれました。https://github.com/ruby/www.ruby-lang.org/pull/3343また、RubyリファレンスマニュアルのString#bytespliceの説明をRuby 3.3に合わせて更新しました。https://github.com/rurema/doctree/pull/2881TextbringerTextbringerのwikiを更新しました。https://github.com/rira100000000/textbringer_wiki_working/pull/3https://github.com/rira100000000/textbringer_wiki_working/pull/2ruby-gnomeruby-gnomeのglib2/sample/bookmarkfile.rbファイル中のtypoを修正しました。https://github.com/ruby-gnome/ruby-gnome/pull/1616pagewalkerpagewalkerでGooogle検索のページ様式の変更によりサンプルシナリオが失敗してしまう問題を修正しました。https://github.com/xketanaka/pagewalker/pull/52

2024年OSSパッチ会の成果

NaClの佐田です。皆様にご協力いただいたおかげで、松江Ruby会議11を無事に開催することができました。松江Ruby会議11とは松江Ruby会議は、島根県松江市で開催される地域Ruby会議です。松江Ruby会議11は、NaClのメンバーにもスタッフとしてご協力いただきました。それと、るびまの開催レポートの作成を雄也さん、高田さん、伊東さん、藤井さんにご協力いただきました。また、松江Ruby会議11は発表者を募集させていただき、厳正なる審査の結果、原さんが登壇することが決まりました。詳細は 松江Ruby会議11 の公式サイトをご参照ください。当日準備開催日の午前中は松江オープンソースラボにスタッフに集合していただき会場準備をしました。それから机や椅子の移動をおこない、机がある席には電源タップを利用できるように準備しました。また、前日から高尾さんにはスクリーンやモニターの設定をおこなっていただき、開催日も問題なく接続確認することができました。受付それと、雄也さんに受付をお願いしました。これまでの松江Ruby会議では、本編と懇親会の登録先のDoorkeeperのイベントを分けていましたが、Doorkeeperのイベントのチケットで分けるようにしました。そのQRコードを受付にて提示して欲しい旨を、前日に参加者へメールでお伝えしました。受付では、そのQRコードを読み込んでチェックインしていただく作業をしていただきました。前田さんも受付で懇親会費を徴収していただきました。会場発表が始まったら、私は発表の時間のためのタイムキーパーをしていました。session 1 「Rubyをファミコンで動かすには」原さんはsession 1「Rubyをファミコンで動かすには」と題して発表していただきました。まず、ファミコンでRubyを動かすにはメモリが少ないことが問題になったとのことです。そこでnesrubyを自作することでファミコンでもRubyが動作するようにされたとのことでした。その開発の時にmruby-rubyも作成されたとのことです。nesrubymruby-rubyファミコンのエミュレーターでデモがおこなわれました。発表ではRubyのプログラムの10+20の足し算を、ファミコンのエミュレーターで動作させていました。スライドまつもと ゆきひろ 氏への質問コーナーNaClフェローのまつもとさんの質問コーナーです。高尾さんに司会をしていただきました。事前募集した質問の数はありましたが、まつもとさんが次々に回答していただけたことで、会場の来られた方にも追加で質問していただける時間ができました。るびまの開催レポートNaClのメンバの雄也さん、高田さん、伊東さん、藤井さんにご協力いただき、「るびま」の開催レポートを作成しました。開催レポートの作成では、HackMDを使用しました。るびまの開催レポートに使用する写真は、各レポート担当と写真撮影担当のスタッフに撮影いただいたのを使用しました。まとめ松江Ruby会議11の会場では、ご参加いただいた皆様のご協力のおかげでスケジュールに沿って進行することができました。

松江Ruby会議11の開催レポート

NaClの早川です。Kaigi on Rails 2024に参加しました。Kaigi on Rails 2024Kaigi on Rails 2024は、東京の有明セントラルタワーホール & カンファレンスで開催されました。スポンサーブースも盛り上がっていました。基調講演 Rails Way, or the highwayRailsへの初コミットからちょうど10年の@palkanさんによる基調講演です。講演中にあった『RAILS WAY はあなたの導きの星だ』という言葉はとても印象的で、Railsの設計で迷ったときに思い返したいなと思いました。参考情報スライドRailsの仕組みを理解してモデルを上手に育てる-モデルを見つける、モデルを分割する良いタイミング-五十嵐邦明さん(@igaiga)による、モデルの設計と育て方、分割のお話。モデルを探す方法についてはRailsの練習帳を読んでください、ということでしたが、こちらも大変わかりやすく為になる内容でしたので、改めて読みたいと思います。参考情報スライド[Rails基礎] DBモデリング基礎講座｜Railsの練習帳そのカラム追加、ちょっと待って！カラム追加で増えるActiveRecordのメモリサイズ、イメージできますか?Asayama Kodaiさん(@asayamakk)さんによる、カラム追加で使用するメモリはどのぐらい増えるかというお話私も意外と少ないな、と感じたのですが、そこはいわゆる『ちりつも』で増えていくわけなので、メモリに対する意識を改めさせられる発表内容でした。スライドカスタムしながら理解するGraphQL Connection@yana-giさんによるGraphQLとCustom Connectionのお話。私はGraphQLを「SQLのフォーカスをより絞って使えるもの？」くらいの知識でしたが、実際の業務でどのように使われているのかを知り、勉強になりました。参考情報スライドリリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果Naoyuki Kataokaさん(@katty0324)による、大量のERBファイルをViewComponentに自動変換するお話。サブミッションとしてコツコツ進め、1年半かけて全てのファイルを変換したそうです。参考情報スライドRails APIモードのためのシンプルで効果的なCSRF対策@corocnさんによるAPIモードでのCSRF対策のお話。corocnさんは以前にRails SPAの為のCSRF対策について記事を書いていたそうですが、当時推奨したトークンを使用する方式はもう使わないでほしい！ということです。参考情報スライド現実のRuby/RailsアップグレードYuichi Takeuchiさん(@takeyuweb)によるRubyやRailsをアップグレードするにあたり現実で直面する問題のお話。ビジネス側に理解してもらうために信頼関係を築いておく、アップグレードの説明はエンジニアの説明責任であるという話を聞き、コードを書くだけがエンジニアの仕事ではないなと考えさせられました。参考情報スライドHotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜@haruna-tsujitaさんによるReactからHotwireへ機能を移行するお話。昨年の大場さんの発表内容からヒントを得て解決に至ったというお話には『Kaigiって素晴らしい！』ととても感動しました。参考情報スライド作って理解するRDBMSのしくみYudai Takadaさん(@ydah)によるRDBMSとデータ構造のお話。様々な木構造がそれまでのものの弱点を克服して誕生していく、歴史を感じられてとても面白かったです。参考情報スライドActiveRecord SQLインジェクションクイズ (Rails 7.1.3.4)Koji NAKAMURAさん(@kozy4324)による、SQLインジェクションクイズと正しい対策の解説です。4問目を正解できた人はかなり少ない印象でしたが、Breakmanはこの問題をすべて正解できるということです。参考情報スライドOmniAuthから学ぶOAuth 2.0@ykpythemindさんによる、OmniAuthは何をしているのか？というお話。認証と認可とは？という基本的な話からOAuth2やOpenID Connectの規格、明日から使えるTipsと、初学者にも現在使っている人にも学びのある発表でした。参考情報スライド約9000個の自動テストの時間を50分から10分に短縮、偽陽性率(Flakyテスト)を1%以下に抑えるまでの道のりhatsuさん(@hatsu38)によるCI上のテストのパフォーマンス改善のお話。テストの時間短縮は個人的にとても気になるトピックだったので、大変参考になりました。参考情報スライドHotwire光の道とStimulusYasuko Ohbaさん(@nay)によるHotwireの設計原則のお話です。haruna-tsujitaさんの発表でも感じましたが、Hotwireは今までのRails + JavaScriptの常識を一度捨てないと本当の良さに触れることはできなさそうです。参考情報スライドData Migration on Rails@ohbaryeさんによるデータ移行、変更のお話。Rails consoleからデータ操作するというのは「そんな恐ろしいことを何故？」と思っていましたが、緊急時にスピードを最優先すれば選択肢として上がるのかも、と解像度が上がりました。参考情報スライドomakaseしないための.rubocop.yml のつくりかたShu Oogawaraさん(@expajp)による自分たちのチーム用に.rubocop.ymlを作るためのお話です。問題に取り掛かる前に取り組み方やチームの意識に目を向け、確実に成功するための仕組みを作ったことが成功の要因となるのですが、マネジメントってかっこいい仕事だなぁと感じました。参考情報スライドIdentifying User IdenityMOROHASHI Kyosukeさん(@moro)によるユーザーのアイデンティティに関するお話。usersテーブルにはIDだけを置き、個人情報やサービスに使う情報はそれぞれ別のテーブルに分けましょうという提案と、管理者は「ユーザーとして」いるわけではないというお話、どちらも「なるほど！」と感じました。参考情報Identifying User Idenity - Speaker DeckWHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと島田浩二さん(@snoozer05))による、基調講演です。システム全体を考えること、シンプルさを保つように修復していくことが重要であるというお話があり、最後は『DON'T FORGET TO HAVE FUN!』というメッセージで締めくくられました。まとめ私は昨年はオンラインで視聴していて、絶対次は現地に行こう！と思っていたので、参加できてとても嬉しかったです。次回は2025年9月25日～9月26日の開催が決定しているということで、是非また参加したいと思います！