NaCl

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日の開催が決定しているということで、是非また参加したいと思います！

Kaigi on Rails 2024の参加レポート

NaClの岸野です。今年もインターンシップが10日間本社で開催されました。Links2023年インターンシップ2024年東京支社インターンシップインターンシップ概要今年度のインターンシップの題材は「Rails Tutorial で作成したWebアプリの機能追加」です。参加人数: 8名(県内4名、留学生1名)日数: 10日間内容: Rails Tutorial で作成したWebアプリの機能追加主な担当: 諸星、岸野、瀬崎サポート: 加納、完山、俵面談: 伊東、田中参加者のうち3名は前週のRuby合宿にてほとんど初めてRubyに触る、残りの5名は学校の授業などで数年プログラミングをしているということでスキルのギャップがありました。以下のスケジュールで開催しました。去年の講義パートが好評だったので踏襲するようなスケジュールでの開催です。赤字は東京支社とのオンラインセッションです。1日目: 顔合わせ、インターン説明、開発環境構築、会社案内・事前質問解答（前田）、Webアプリとは（伊東）、ようこそランチ会2日目: たのしいRuby（西田）、Git/HTMLについて（加納）、開発3日目: 開発、まつもとさんを囲む会4日目: 開発5日目: 開発、超絶技巧プログラミング（TRICKの紹介）（原）6日目: 開発、社員交流ランチ会7日目: 開発8日目: 開発9日目: 開発、発表準備10日目: 発表準備、発表会、事務処理情報共有ツールとしてDiscordを利用しました。今年は画像・リンクの共有のほかにレビュー依頼通知のために頻繁に活用しました。1日目タイムテーブル10:00 - 10:30 自己紹介・インターンシップ概要10:30 - 10:45 本社案内・書類確認11:00 - 11:30 会社説明（前田）11:40 - 12:40 昼食交流会13:30 - 15:00 環境構築15:00 - 16:00 WEBアプリについて（伊東）16:00 - 16:30 環境構築16:30 - 17:00 日報・連絡段取りと感想まず、最初の自己紹介とインターンシップ概要です。はじめ方と進行がいまいちでぬるっと始まってぬるっと終わったしまった気がします。あるいは、リモートワーク続きで自然な会話が減ってしまっているのも要因の一つかもしれないので、数営業日前から出社して会話の慣らし運転をするのも手でしょうか。その後しばし休憩を挟み、社長の前田より会社説明を行いました。結構面白い質問でしたので、事前に社内でも多少議論が行われていました。事前にいただいていた質問レガシーなプロダクトの抱える技術的負債とどのように向き合っておられますか? また、新規のプロダクトの開発において技術的負債を遺さぬために気をつけておられるところはありますか?Ruby の開発に携わる社員への評価はどのようにして決まるのですか?ずっと話ばっかり聞いているのも退屈なので、午後一番は早速環境構築ということで皆さんに手を動かしてもらいました。一昨年あたりまではここが鬼門だったイメージですが、インターン用のリポジトリがだいぶ整備されてReadmeが親切になったおかげでかなりすいすいと進みました。Readmeの改修まで必要かというと若干疑問ですが、少なくとも横についてライブコーディング形式でセットアップを進めるという手法をとっても良かったかもしれないです。環境構築で参考にしたサイトWSL installhttps://learn.microsoft.com/ja-jp/windows/wsl/installRuby installhttps://github.com/rbenv/rbenvWSLの場合、aptでrbenvをインストールするとよさそうVSCode での WSL 接続https://learn.microsoft.com/ja-jp/windows/wsl/tutorials/wsl-vscode講義その1。Webアプリについての講義でした。そのあとの開発に直結する話なので概念だけでもあるとありがたいですね。反面、ほかの講義は横にコードがありきで進むので聞いていて直感的にわかるのですが、この講義は横に具体的なコードがあまりなく話が進むので、作業と結び付けづらいというのが一つ課題だと思います。残りのちょっとの時間環境構築の続きをやりつつ1日目終了。2日目タイムテーブル10:00         朝の連絡10:00 - 10:25 Git/HTMLについて - Git編（加納）10:30 - 11:10 Git/HTMLについて - HTML編（加納）11:15 - 11:35 Git/HTMLについて - Rails編（加納）11:40 - 13:00 休憩・加納さんのコードをみる会13:00 - 14:10 たのしいRuby（西田）14:20 - 14:30 開発やり方説明14:30 - 16:30 開発16:30 - 17:00 夕会段取りと感想講義その2。Git, HTMLに関する講義です。Gitの講義については個人的にはかなり良かったと思います。この講義が功を奏したのか、開発フェーズに入った時にGitの質問はほとんど飛んできませんでした、すごい！社員としても他の社員が個人で作成している作品やWebサイトはそう頻繁に見ることはないので興味深かったです。この辺で担当者で集まりチーム分けについて議論しました。「スキル」をベースにチーム分けする理由として、前年までのインターンシップの傾向として、チーム内でスキル差があるとスキルがない人は開発に携わりづらく、かつ我々からもスキルが一番ある人以外の評価が難しいという点がありました。これを一旦別の視点で見るために同じスキル同士が固まって開発するという方向性を一つ作りました。今回はスキルのばらつきが顕著な場合にスキルごとにチーム分けをしたらどうなるかという試験的要素から「スキル」に応じたチーム分けにしました。講義その4。西田のたのしいRubyです。こうやって教えればいいのかと自分の中でも勉強になるところが毎回あります。開発やり方講座。これまた開発がぬるっと始まってしまうと思い、急遽用意したコンテンツです。いろいろなチュートリアル的行事を終えていよいよ開発が始まりました。夕会について、土壇場でやはり東京とつなごうと提案しましたがこれが良い選択肢でした。3日目タイムテーブル10:00         朝の連絡10:00 - 12:00 開発12:00 - 13:00 休憩13:00 - 14:00 開発14:00 - 15:10 まつもとさんを囲む会15:20 - 16:30 開発16:30 - 17:00 夕会段取りと感想午前中から開発作業が開始しました。初心者向けのIssueは皆さんわかりやすかったようで開始時点でほとんど終わっていました。Railsを扱うに際してどこから見ていけばいいかという「とっかかり」は初心者の方にとっては鬼門だと思うので、Issueを一つ取り上げて、ホワイトボードを使いながらひとつずつ流れを説明していきました。質問と解答体調で気をつけること夜更かししない散歩(天気がいいと8000-9000歩、東京だと10000歩)腰・背中のこりあまり凝らないたまに整体行く分割式キーボードとかもあまり使わないガジェットのお気に入り2020年にデスクトップを買ってそれっきりノートPC使う頻度は減った(コロナ禍で動かなくなったから)こだわりはないが、ノートPCはThinkPadキーボードはTEX Shinobi言語を作るときどんな機能が欲しかったすべてが例外なくオブジェクトの言語少ないルールを広く適用できたらいいLISP LikeSmalltalkからまねできるものはまねたいRubyに付け足したい機能ほしいものは過去30年でほぼ入れたnamespacedecorator, attributeメタ的な情報を付加する（アノテーション）記号が足りないMethodオブジェクトを取り出す機能プログラミングをどう上達したか愛着(犬に芸を教えるみたいな)学生時代に勉強したほうがいいことコンピュータサイエンスにいくらでも触れられる環境を活用してRubyを学ぶおすすめの本・教材チェリー本たのしいRubyRubyが広まっていることについて最初はこんなに広まるとは思わなかったTechnical Debtが生まれる原因早く作らなければならないからあってはならない自分ができる範囲で最大の品質を技術トレンドの変化仕方ない可能であればモジュール全部を書き換えるとか機能を追加していって気づかぬ間に大きくなってしまったソフトウェアの構成を考えていれば影響範囲を考えられる考えて設計していれば減らせる情報工学科を出たのに情報を生かせない会社につくことについてよくあること問題解決のエキスパートとしての側面はどの仕事でもプラス職業に直結しやすいジャンルなのでもったいないと思われがちできること・得意なことと組み合わせて答えを出すといいRubyの名前の由来Perlから宝石の名前にしたかった英語がどのくらい喋れたらいい読めるととても良い(翻訳されたりする前に情報を得られるとよい)4日目タイムテーブル10:00         朝の連絡10:00 - 12:00 開発12:00 - 13:00 休憩13:00 - 16:40 開発16:40 - 17:00 夕会段取りと感想3日目の続きの説明をホワイトボードを使いながら主にしながら、コードレビューをしていました。教えながらだとどうしても全部見きれないところを諸星がサポートする形でのコードレビューでした。5日目タイムテーブル10:00         朝の連絡10:00 - 12:00 開発12:00 - 13:00 休憩13:00 - 15:00 開発13:00 - 15:00 インタビュー（伊東）15:00 - 16:00 超絶技巧プログラミング（原）16:00 - 16:40 開発16:40 - 17:00 夕会段取りと感想今回のインターンシップでは、参加者の気持ちを直接うかがうために伊東・田中により2回に分けてインタビューを行いました。期間中にインターンの進め方についてもフィードバックを得られたので進め方の改善につながりました。講義その5。超絶技巧プログラミングです。TRICKのコードをいくつか紹介していただきました。相変わらずぱっと見ではよくわからない奇妙なコードばかりで面白かったです。5日目ということで東京支社とのインターンシップとの並走はここで終了しますが、松江本社は折り返しということでさらに難しい課題へのチャレンジが見られるようになってきました。6日目タイムテーブル10:00         朝の連絡10:00 - 12:00 開発12:00 - 13:00 ランチ会13:00 - 16:40 開発16:40 - 17:00 夕会段取りと感想5日目のインタビューでのフィードバックを受けて、わからない人向けに今までの作業のおさらいをしてわからないところを埋め合わせる時間を設けてみました。体感として、git addやgit pushはおおむねわかっていたのですが、git commitとgit pushの違いや、git rebaseでのブランチの動き、git stashやコンフリクトなどの比較的イレギュラーな時の対応についていまいちこちらの説明が行き届いていなかったように感じました。次に、Railsでの機能開発を一緒にやってみてどういう順序で実装するかを確認しました。例として、マイクロポストの詳細画面を作成して確認しました。そして昼休みはまた、初日と同じところのお弁当を食べながらキッチンで交流会をしました。今回は社員含めて17名での交流会でした。今後の反省として部屋を分けたり、社員の数を減らしてでも上限を決めて人数を絞るべきだと思いました。反省すべき点はたくさんありましたが、ランチ会を期にDiscord上での会話が活発化したのでやはりそういった交流機会を増やすという面では良かったかと思います。7日目タイムテーブル10:00         朝の連絡10:00 - 12:00 開発12:00 - 13:00 ランチ会13:00 - 16:40 開発15:00 - 16:40 インタビュー（田中）16:40 - 17:00 夕会段取りと感想7日目に残りの5名のインタビュー時間を設けました。初心者向けティーチングに関してもおおむね6日目の続きという感じで行いました。今回は7日目から時間に余裕が出てくるパターンでした。一通り初心者向けティーチングをしたあとはおおむねコードレビューのみという流れでした。8日目タイムテーブル10:00         朝の連絡10:00 - 12:00 開発12:00 - 13:00 休憩13:00 - 16:40 開発16:40 - 17:00 夕会段取りと感想7日目に引き続きライブコーディング形式で教えました。8日目はRailsメインで行いました。やはりこのやり方だと板書よりも「こうしたらこうなる」というリアルタイムな動きがわかりやすく、良かったです。9日目タイムテーブル10:00         朝の連絡10:00 - 12:00 開発12:00 - 13:00 休憩13:00 - 16:40 開発14:30 - 発表準備16:40 - 17:00 夕会段取りと感想最後の開発ができる9日目です。ずっとチームBで原因がわからなかったダークモード機能での画面のちらつきについて説明できるように手元で実装して確認してみました。(実装コード)後々、諸星よりturbo:loadでの呼び出しだと処理のタイミング的に遅いのでturbo:renderを使うとよいのかも、というstimulusを使わない場合のアプローチの提案がありました。作品の最終調整を終えたのち、発表準備へと移っていきました。10日目タイムテーブル10:00 朝の連絡10:00 - 12:00 発表準備12:00 - 13:00 休憩13:00 - 15:00 発表準備13:00 - 13:30 接続確認15:00 - 16:10 発表16:10 - 17:00 提出物作成（中央会）、インタビュー（ジョブカフェ）、アンケート段取りと感想ついに成果発表の日となりました。各グループの発表がAチームから行われていきます。AチームIssueを途中までこなせたマイクロポストの詳細画面を作ったBチームIssueほとんど終わったダークモード機能を実装したCチームIssue全部できたハッシュタグ機能を実装したスキルごとにチーム分けしたおかげで、各チームそれぞれなりの工夫や頑張りが見られて良かったです。発表後に今年はインタビューがあると聞いていました。まさか私が対応するとは思わず、引き受けましたが若干段取りがずれて集合写真を取り忘れるなど、最後の書類整理の時間がバタバタしてしまいました。参加者の声(抜粋)タスク難易度難しいけど最終的にコードの内容が理解できるようになったある程度オリジナルの要素も組み込むことが出来てちょうど良いと感じました講義について高専で習った内容もあったけど全体的に興味深い内容でとても面白かった。もっと講義の数を増やしても良かったかも。夏目漱石の小説を弄くり回す講義は楽しかった 続きも見てみたかった初めて聞く内容などばっかり興味深かかったです。特に魚釣りのサイトの講義が面白かったですインターンを通じてインターン内で、Railsをいじれるようになったことが一番うれしいです。成果発表会でも発表した通り、前々からどうにかサークルの情報共有をどうにかできないかと思っていたのでそれが解決できそうなので、希望を持つことができました。楽しかったのは、みんなとあーでもないこうでもないみたいな感じで機能についていろいろ相談できたことです。チーム開発がこんなに楽しいものだとは思いませんでした。チーム開発が体験できたこと。社員の方々にコードをレビューしてもらったり、いろいろな質問ができたこと。褒めてもらえたこと。かわいい犬と猫の写真がたくさん見れたこと。残念だったことではないのですが、長時間に及ぶものだったのもあり、体力的にきつかったです。やっぱりIssueを全部達成できなかったことと、レビュー依頼を出していなかったことです。あとで、ほかのチームのレビュー依頼を見てこんなにアドバイスをもらえるんだとかなり損をしていたことに気付きました。本インターンから見えた全体的な課題Issueはもう少し少なくていい我々が用意したIssueをこなすことでほとんど手いっぱいになってしまい、せっかくの時間をクリエイティブに使いづらい。もっとチュートリアルっぽくてよいスキルでチーム分けしたのは大成功でした！まんべんなく全員が作業で来ていたので、今後もこの方法は取り入れようと思いますなにごとも段取りをもう少しちゃんと考える時間が必要でしたLinuxかるたを取り出したのはいいのですが、いざやろうという時間がない（学生の皆さんは開発期間中は開発に熱中しているため）30分くらいの微妙な時間は何度かできていたのでそこの穴埋めで次回からはつかえるようにしていきたい筆が乗らない場合を考慮すると、この記事を書くために1人日以上必要です

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

NaClの鈴木です。何度も開催し成功させてきた本社のノウハウを参考に、なんとか無事に終了しました。インターンシップ概要インターンシップの題材は「Rails Tutorial で作成したWebアプリの機能追加」です。昨年の本社での開催で、業務に近い題材として実施されたのがこの題材でした。また、支社の開始日を本社と合わせることで、オンラインで繋いでイベントをシェアしたり、交流の機会を設けることができました。参加人数: 1名日数: 5日間内容: Rails Tutorial で作成したWebアプリの機能追加主な技術担当: 早川、鈴木実際のスケジュールは下記のようになりました。開催期間 5日間の内、開発している時間は実質半分ほどでした。1日目: 本社と繋いで自己紹介タイム、インターン説明、会社案内（前田）、ウェルカムランチ会、開発環境構築、オンライン講義「Web アプリとは」（伊東）2日目: オンライン講義「Git/HTML について」（加納）、社員交流ランチ会、オンライン講義「たのしい Ruby」（西田）、開発3日目: 開発、社員交流ランチ会、オンラインイベント「まつもとさんを囲む会」4日目: 開発、社員交流ランチ会5日目: オンライン講義「超絶技巧プログラミング（Quine や TRICK の紹介）」（原）、社員交流ランチ会、発表準備、支社成果発表会情報共有の為のツールは、Discord を利用しました。常にそばに控えている社員がいた為、支社内でのコミュニケーションは直接行っており、主に本社との情報共有として利用しました。1日目インターン初日。インターンの説明を終え、前田からの会社説明タイム。NaCl についてのお話を興味深く聞いてくれていました。オンラインでのやり取りを終え支社の施設を紹介した後、出社していた社員みんなと「ウェルカムランチ会」に繰り出しました。支社のある秋葉原周辺は美味しいランチのお店がたくさんあるので、色々食べに行けて良いですねとのこと。たしかにランチの豊富さは仕事のモチベーションアップにも繋がりますよね～。食事中は社員の当時の就活事情や、好きなことを仕事にするということの良し悪しなどについて話していたような気がしますが、ステーキが美味しかったです。ランチの後は開発環境の構築をしました。初めての Docker でしたが、Dockerfile や、docker-compose.yml 等、コンテナを立ち上げる為の準備はこちらで用意していた為、コマンドをインストールした後、割と時間がかからずに開発用のコンテナを立ち上げることができていました。環境構築が 1時間程でできてしまった為、午後予定していた講義の時間までけっこう時間が余ってしまうという事態に。せっかくなので開発を始めてみることにしました。Web アプリってそもそも何？というところから、Rails の MVC アーキテクチャについてじっくり伊東が解説しました。仕組みを知ると、与えられた課題を解決するためにどこを修正したら良いのか？ ということのあたりがつくようになるので、大事ですね～。初日はこれで終了。2日目インターン 2日目。HTMLについてはある程度の知識があった為、HTML の講義はラジオ的に聞かせてもらいつつ、昨日の続きから開発作業に入ってもらうことにしました。インターン生さんが 1人ということもあり、実は期間中ずっと社員数人と秋葉原ランチに行っていたりします。このタイ料理のお店は数日続けて食べても良いくらい美味しいです。インターンについてや、就職先に求めることなどから、学校での話などをもぐもぐしつつ聞かせてもらったようです。午後はオンライン講義「たのしい Ruby」から始まります。1つ1つやりたいことをコマンドで実行していき、成功したらそのコマンドたちをまとめてスクリプトにしていく。少しづつ一括で実行できることが増えていき、最後にイチから一括でスクリプトを実行する。すると、「おーーーー！」となって何やら一体感が生まれていました。西田の人柄もありますが、大変盛り上がっていてライブコーディングはとても良い時間になりました。その後は2時間ほど開発の時間でした。私はこの日リモート参加だったのですが、プルリクエストのレビューが 4個ほどきていたのでびっくり。いくら難易度「初心者向け」とはいえ早いなーと思っていたら、出社していた早川が付きっきりで不明点を解消してくれていたようです。参加者 1人だと社員に質問しやすいというメリットはありますよね。課題をこなしていく中で、少しづつ難易度が上がりわからないことが増えてきているようです。あと Git と Docker に振り回されているよう。概念がピンとこないと難しいですよね～。3日目インターン 3日目。「初心者向け」と「やさしい」の違いは簡単に言うと複数箇所の修正が必要かどうかです。MVC の構成が頭に入っていないと繋がりがわからない為、修正箇所のあたりがつかないことが難しい要因のようでした。周辺のランチの中でも、比較的安くてボリューミーなのに美味しいので普段から良く行きます。過去のインターンの話とか、就職とかプログラミングとかぜーんぜん関係ない雑談とかしつつ、午後の作業に向けておなか一杯にします。午後の開発の合間に待ちに待ったオンラインイベント「まつもとさんを囲む会」開催！プログラミング言語を開発するというだけでもすごいのに、それが世界中で現役で使われているというのはものすごいことですよね。神のような存在の方ですが、実はとてもきさくで話しやすい素敵な方です。この「まつもとさんを囲む会」は、実は NaCl で毎月開催している社内イベントの出張版として開催して頂きました。3日目はこれで終了。4日目インターン 4日目。これまで実装してきた内容の復習になる課題がちょうどあったので、それをできるだけ 1人で開発してみようとお願いしてみました。初挑戦の難易度「ふつう」ですが、チームメイトもいない中、1人で 1日で開発するにはギリギリの線かな～というところ。美味しいと好評だったのでもう一度行っちゃいました。前回行ったときに気になっていたメニューを食べれて満足されていた様子。この日も就職についてやらサッカー日本代表戦についてやらもくもくしながらお話ししました。4日目はこれで終了。5日目インターン最終日。太くてもっちもちの麺をラー油入りのつけ汁につけて食べるアウトローな蕎麦を食べつつ、この一週間の思い出を語りました。夕方の発表会の前にとても興味深いオンライン講義が開催されました。Quine 」 や「 TRICK 」の紹介） 」。オンラインで開催したので、出社している社員はもちろんリモートワーク中の社員も集まる中、この 5日間に学んだことや開発作業について渾身のスライドで発表してくれました。インターン生 1人だけということで大変だった部分もあったと思いますが、それ以上にメリットを十分に活用して頑張ってくれたんだなーとしみじみ。これで最終日終了となりました。本当にお疲れ様でした。ご参加ありがとうございました！参加者の声(抜粋)課題の「初心者向け」から「やさしい」への難易度の上がり方がきつかった。チーム開発を経験したかった。講義だけでの理解は難しかった為、事前に予習できたら良かった。会社の勤務形態が自由で良いと思った。社員の雰囲気が良くリラックスして通えた。本インターンから見えた課題Git や Docker のコマンドなどをいつでも確認できるよう、チートシート的なもの用意すると良かった。講義を受けた後でも、Rails の繋がりがなかなか頭に入らないと思うので、MVC 構成について図解を確認できるようにしておくと良かった。コミットとプルリクエストのテンプレートを、最初から用意しておいたほうがより業務的に作業できて良かった。今回のように1名の参加の場合に、人数の多い本社のインターン生さんとの距離を感じない工夫が必要。

2024年度夏季インターンシップ in 東京支社

NaClの早川です。大阪Ruby会議04に参加しました。大阪Ruby会議04大阪Ruby会議04は、大阪の中之島フェスティバルタワーで開催されました。スポンサーブースもありました。Keynote: 最高の構文木の設計 2024年版Yuichiro Kanekoさんによるキーノートです。構文木の使われ方の変遷から始まり、ユースケース毎の抽象構文木の扱い方の違い、さらに抽象構文木の先にある具象構文木の説明、実装についての解説がされました。構文木の詳しい解説や最新の事情というのは中々聞く機会のない話なのでとても興味深かったです。参考情報スライドRuby Parser開発日誌 (20) - 大阪Ruby会議04で基調講演をしてきた ~ 大阪の一番暑い日 ~ - かねこにっきdRuby 入門者による あなたの身近にある dRuby 入門makicamelさんによるdrubyを用いた身近なプロダクトの紹介です。分散オブジェクトシステム、と聞くと何やら複雑で縁遠いものに感じてしまいますが、ActiveSupportや、るりまといった、まさに日頃お世話になっているものにもdRubyが使われていて、色々な技術の上に成り立っている日々なのだなぁと実感しました。参考情報スライドRubyKaigi公式スケジュールアプリ開発で得た、Hotwireの使い方kinoppydさんによるHotWireに関する知見のお話。Hotwireというと比較的新しい技術なので、実際に開発で得られた知見が共有されるのはありがたいという方も多いのではないでしょうか。来年のスケジュールアプリ開発を既に見据えているということだったので、松山ではそちらにも注目したいですね。参考情報スライドRe-line 〜 IRB・Reline 複数行編集の裏側ぺん！さんによるRe-lineのレンダリング改善にいたるまでのお話。TypeScriptで書かれた線香花火が衝撃的でしたが、本題はRe-line。まとめにあった「当たり前のことを当たり前にやるとソフトウェアは確実に良くなる」という言葉も実直で素敵だなと思いました。参考情報スライドSponsor LT: データベースだけじゃないN+1とその対策freeeの川原翔吾さんによるN+1問題の対策に関するお話。攻め編の最後に『「これが正しい」というものはなく要件や周辺環境次第で選択する必要がある』というお話があり、N+1という有名なアンチパターンですら銀の弾丸は存在しないのだなぁと設計の難しさを感じました。参考情報スライドSponsor LT: LR で JSON パーサーを作る永和システムマネジメントのjunk0612さんによるパーサー3分クッキング！次回(?)は構文木の生成についても解説が入るそうで、3分で構文木入門したい人は見逃せない内容になりそうです。参考情報スライドRustで作るTreeSitterパーサーのRubyバインディングjoker1007さんによる、TreeSitterのRust製Rubyバインディング作成およびRustでRubyGemを開発するお話。特にGC周りは複雑なようで、GCによって何が解放されるかを理解する必要があるというお話をされていました。私も一度腰を据えて勉強しなければと思いました。参考情報スライドtree_house競技プログラミングでみる Ruby の豊かさharuguchi-yumaさんによる、競技プログラミングを通じてRubyのコーディングの柔軟さを見てみましょうというお話。可読性、拡張性、保守性の価値観を捨て、あえて読みにくく複雑で短くしたコードが紹介されるのですが、終始笑いの起こる楽しい発表でした。参考情報スライドMinify Ruby CodeKoichi ITOさんによる、RubyのコードをMinifyするお話。Minifyの可能性を探るところから始まり、実際のGemに落とし込むまでの話かと思いきや、図らずも自身の開発するRuboCopとのマッチポンプが完成したという面白いお話でした。参考情報スライドMinify Rubyをリリースした - koicの日記Sponsor LT: 株式会社ナレッジラボのご紹介急遽スピーカーが変わったということで、okeyseaさんによるナレッジラボの紹介が行われました。Sponsor LT: 労務ドメインを快適に開発する方法 〜日本語コーディング編〜SmartHRのykyuki21さんによる、複雑な属性名を日本語コーディングで解決したお話。コーディングに日本語を持ち込むのはちょっと…という感覚があったのですが、実際のコードの様子はとてもスマートに感じました。参考情報スライドstrscanなしで文字列をスキャンする弊社社長の前田さんによるstrscanを使わずに文字列をスキャンするお話です。strscanを使わなくてもString#scan、String#indexなどで文字列をスキャンできるのですが、最後までまとめてスキャンしてしまう、マルチバイト文字でパフォーマンスの問題が出るといった問題があり、解決策としてString#byteindexが登場します。最終的にはstrscanを使えばいいというまさかの結論にいたってしまいましたが、何事もやってみなければわからない、ということですね。前田さんお疲れ様でした！参考情報スライドどうしてこうなった？から理解するActive Recordの関連の裏側willnetさんによる、Active Recordの不思議な挙動を発見しそれを解明していくお話です。双方向関連付けにもメリットがあり、当然使いたいタイミングもあるため、そんな方のためにデバッグ用ツールを公開されたそうです。参考情報スライドsave_chain_inspectorSponsor LT: devise-two-factorを4.xから5.xに上げた話Ruby開発のznzさんによる、deviseで2FA認証するためのGem、devise-two-factorのバージョンアップのお話。バージョンアップで動かなくなることがあるのは何故？と思っていたのですが、メソッド名が衝突するというのはなるほど現実に起こり得るんだなぁと感じました。参考情報スライドSponsor LT: PHPerが転職してRubyを3ヶ月使った感想インゲージの久保 慶輔さんによるPHPとRubyの比較と感想のお話。等価比較やfalsyな値、emptyの扱いなど、比較してみると様々な違いがあることがわかりますね。Keynote: 令和の隙間産業——PicoRubyはどこから来て、どこへ行くのかHitoshi HASUMIさんによるキーノートです。『同じ題目でも人によって発表が違い、その人の人生が出る』といった主旨の発言があったのですが、『その話は誰かがどこかで既にしているんじゃないかな』といった尻込みの仕方をする私には、自分らしく発表すればそれでいいのかもしれない、という前向きな気持ちにさせられました。まとめ知らないこと、わからないことの情報量に圧倒されつつ、知りたいこと、やってみたいことをたくさん与えてくれる、素晴らしいカンファレンスでした。運営のみなさん、登壇者のみなさん、そして参加者の皆さん、お疲れさまでした。