＞＞＞＞関連記事
RIZAP がRubyKaigi 2023に初参戦！【新卒メンバー現場レポート】はこちら

入社４年目／梅田智大の感想まとめ

 入社４年目、現在フロントエンドエンジニアをしています、梅田智大です。
（＞＞＞梅田さんが登場する記事はこちら）
自分は会期中、８本の講演を聴いてきました。いずれも刺激的な内容でした…！

①Learn Ractor （Masatoshi SEKI）

アプリケーションの速度を向上させるRactorについての機能、実装法、利点などについて包括的にお話をいただきました。
Ractorは、Rubyプログラミング言語の並行性モデルであり、Ruby 3.0から導入された新しい機能です。Ractorは、並行プログラミングをシンプルかつ安全に実現するために設計されています。 
従来のRubyにおける並行処理は、スレッドを使用して実現されていましたが、スレッドの使用は複雑さや競合状態のリスクを伴います。Ractorは、これらの問題を解決するために導入されました。

講義の中でも、Ractorはデータが変更されるまでは共有されたデータを参照することでコピーのオーバーヘッドを最小限に抑えるのでメモリの観点で有利であること、単純なケースではスレッドのように書けることが利点であるとお話されていました。
ただ、Ractorは比較的新しい機能であり、すべてのケースで有効に働くわけではありません。
次のケースのように、１万回ループさせるといった処理にRactorを使うとより有効に働くようです。

 所感
「Concurrency is everywhere」 
この言葉が非常に印象に残りました。普段プログラミングをしていると、一つ一つの処理が順番に実行されている、つまり逐次実行されていると考えがちです。しかし、逐次実行は特殊なケースであるということを強調してお話しされていました。Ractorのような並列実行の活用により、処理速度を何倍も早くできるケースは少なくありません。

しかし、逐次実行のイメージに固執していると、並列実行が可能なケースでも見落としてしまい、サービスの品質を低下させる可能性があります。
本講義の最後に、登壇者が自作のポケモンカードの検索エンジンにRactorを導入するケーススタディーがありました。１週間ごとに使われたデッキ構成を分析する機能を追加した際に、１週間単位でRactorを作成し、並列に分析が走るようにしたとのことです。

何も考えていなければ、１週間ごとに順番に分析を実行していくところですが、並列処理を前提にしていれば、このような発想が生まれます。また、１週間ごとにデッキ数にバラつきがあるため、並列処理をしても１番デッキ数が多い週に影響して処理速度が遅くなる可能性があるため、この点をどう解消するかという次の発想につなげられます。
エンジニアとしての視点をかなり高めていただけた講義でした。

②Implementing "++" operator, stepping into parse.y （Misaki Shioi）

Rubyでインクリメント演算子を使えるようにするための試行錯誤についての話でした。
 Rubyでは、+は単項演算子として解析されます。+の後には数字が続くことが期待されているため、インクリメント演算子++の２回目の+が
読み込まれると構文エラーとなります。 
構文エラーを回避し、++をインクリメント演算子として機能させるために、以下の試行が行われました。

試行１：++を解析できるようにする。+の後に+が続いた場合に条件分岐を行い、++をメソッドとして扱えるようにする。  
→ 問題として、i = 0とした場合、i++を実行すると最後のiが1ではなく0となる。 

 試行２：__plusplus__メソッドを定義し、i++の場合には内部的にi.__plusplus__が呼び出されるようにする。  
→ レシーバは変数であることが期待されているため、変数以外のケース（例: 1++）ではうまく動作しない。 

 試行３：シンプルに考えると、+=1ができれば良いため、i++の場合にはi += 1と全く同じ動作をするようにする。一つ目の+で+=を返し、二つ目の+で整数値の1を返すことで、+= 1と同じ挙動とする。
→++の後に他の演算子が続くケース(例: i++ * 2)で、演算子の優先度の影響で期待された値が得られない。 

 試行４：++を+= 1に置き換える。i++という構文を許可し、i++の場合にはi += 1の構文と同じアクションが行われるように定義する。
→ i ++ 1のように予期しない場合に構文エラーとなるため、Rubyで++をどのように扱うかの定義が必要。 

所感
Rubyに新しいメソッドを追加する場合には、どのような思考やアプローチが行われるのかについて非常に興味深い話が聞けました。上記は要点をまとめたものですが、実際の講義ではRubyの構文解析や処理のタイミングについて、具体的な方法がどのように適用されるかについて詳しく説明されました。 
普段、メソッドを使用する際には、裏側でどのように解析され、処理が行われ、値が返されるのかについてあまり意識していませんでした。単なる構文エラーでさえも、どの部分で解析が行われ、エラーが発生するのかを考えると、新たな視点が開けると感じました。

また、講義の結論として、インクリメント演算子++をRubyでどのように定義するかが重要であり、++メソッドを追加した場合、その言語はRuby++と冗談交じりに話されていました。
しかし、メソッドの定義一つで言語が大きく変わると考えると、冗談として受け流すだけではなく、非常に興味深い話となります。

言語は一つの思想であり、どのような考え方の下で作られたかを一つ一つ理解することが重要であると、再認識させられる素晴らしい講義でした。

③Fix SQL N+1 queries with RuboCop （Go Sueyoshi）

ISUCONという主にWebアプリケーションのパフォーマンス改善や最適化に焦点を当てたコンテストに参加するため、rubocopの中でSQLのASTをparseしてN+1クエリを自動修正するgem（rubocop-isucon）を作ったというお話でした。 

通常、rubocopはRubyのソースコードを解析し、RubyのASTを取得して違反の検出や自動修正を行います。しかし、rubocop-isuconでは、RubyのASTだけでなく、SQL文字列もパースしてSQLのASTを取得し、違反の検出や自動修正に利用しています。

copがデータベースに接続してスキーマ情報を取得し、それを解析に利用する方法を採用したそうです。 

N+1クエリの検出自体は難しくありませんが、rubocopをデータベースに接続することで、DBのスキーマ情報を解析できるようにしたというのが大きなポイントとのことです。 

所感
rubocopをデータベースに接続することで、違反の検出や自動修正の範囲を大幅に広げられるという点が興味深いと感じました。 
実際にrubocopがどのように解析を行い、違反を検出しているのかについては、詳しく知りませんでしたので、内容は難しい部分もありましたが、rubocopには多くの可能性が秘められているということを知れて良かったです。
N+1クエリの問題を検出するための有名なgemとして「bullet」がありますが、bulletとrubocop-isuconの解析方法やアプローチにはどのような違いがあるのかについても、さらに深く調べてみたいと思います。 

④Introduction of new features for VS Code debugging （Naoto Ono）

VSCodeのデバッグにおいて、Trace Inspectorという新機能を使用することで、開発体験が向上するという内容の講義でした。 

冒頭で、「コードリーディングの際にデバッガーを使用していますか？」という質問が投げかけられましたが、私は恥ずかしながら使用していなかったため、手を上げられませんでした。
コードリーディングの際にデバッガーを使用すると、処理の流れがより明確になります。

いっぽうで、これまでは複雑なコードの場合にわかりづらく、ステップ実行中に以前のメソッドを忘れてしまったり、ステップ実行をやり直さなければならないといった問題がありました。この問題を解決してくれるのがTrace Inspectorです。
Trace Inspectorには、行ごとに実行結果を確認できるラインベースのトレースログ、実行されたメソッドを確認できるターゲットログ、および返り値を確認できるGithubトレースログという三つのログがあります。 
これにより、より多くの情報を得るだけでなく、特定のログを簡単に見つけられます。

所感
率直に言って、今すぐにでも使いたい機能だ！と感じました。
そもそもコードリーディングの際にデバッガーを使用するという発想は持っていなかったので、今後はフル活用するようにしていきたいですし、デバッガーの使い勝手も悪いと感じていたので、それを解消する機能が開発されていることに驚きを感じました。

エンジニアとしてのスキルを向上させるためには、単に知識を増やすだけでなく、便利な機能をフル活用し効率的な開発を行うことも重要です。
自分自身、便利な機能を十分に活用することが苦手であり、普段も効率の悪い開発をしていると自覚しています。しかし、どのような便利な機能が存在し、それをどう取り入れていけば良いのかという情報を得るのに苦戦していました。この講義は、その点での一つのきっかけとなりそうです。
自分自身の開発体験を向上させる機能があるのかを探し、実際にいろいろと試してみる意欲を持ちました。

⑤Eliminating ReDoS with Ruby 3.2 （Takashi Yoneuchi）

 ReDoS攻撃の問題が注目される中、Ruby3.2でその対策が導入されており、その内容を中心に講義が展開されました。
ReDoS攻撃は、正規表現を悪用してWebアプリケーションやサービスを攻撃する手法です。大量の繰り返しやバックトラッキングを引き起こすことにより、サーバーの応答時間を低下させます。 

例えば、(a|a)*という正規表現があった場合、aの数だけ左と右のaを選択していくので、無数に分岐してしまいます。このような「良くない正規表現の書き方」をすると、パフォーマンスが低下してしまいます。こうした問題に対して、Ruby 3.2では正規表現エンジンの内部に大幅な更新が導入されました。

ソースコード側では、ネストされた正規表現や前後にスペースがある場合に問題が発生するようですので、ネストを避けるかスペースを取り除くなどの対策が取られました。
アプリケーション側では、キャッシュを効果的に利用して高速化を図ったり、タイムアウトを設定して問題が悪化しないように対処しているとのことです。

所感
正規表現については初心者が理解に苦戦するポイントかと思います。私もまだまだ理解が甘く、本講義で話があった正規表現エンジンの改善点についてもほとんど理解できませんでした。
ただ、正規表現には脆弱（ぜいじゃく）性が存在し、特にユーザーに正規表現を入力させる場合は重大な問題となる可能性があることを知りました。

ReDoS攻撃が起こりうるケースについて調査し、実務でも正規表現を使用する際に脆弱（ぜいじゃく）性に注意して実装できるように勉強していきたいです。 

⑥Revisiting TypeProf - IDE support as a primary feature （Yusuke Endoh）

 TypeProfは、Rubyプログラミング言語の静的な型解析ツールです。Rubyは動的型付け言語であり、変数の型は実行時に決定されますが、TypeProfを使用すると、静的な解析によって変数の型を推論できます。 
v1 では解析速度に大きな課題がありましたが、v2では解析速度の向上に取り組んでいるとのことで、その進捗（しんちょく）報告がありました。

解析速度の向上のために行ったのは、変更された場合に差分だけを検出して解析する方法です。
v1ではコードに変更があった場合にはコード全体を再解析する必要があり、速度に問題がありましたが、v2では変更された箇所のみ型推論を行うようにしたとのことです。 

これにより、コードの変更時の解析速度が大幅に改善されました。
0.1秒以内に処理が完了すると体感的にスムーズに実行されていると言われています。その0.1秒以内を目標としていたそうで、計測した結果は0.029秒となり、いったんの目標を達成できたそうです。 

所感
私は、RubyやJavaScriptなどの動的型付け言語を学んだ後に、TypeScriptなどの静的型付け言語を学んだため、正直なところ静的な型付けには煩わしさを感じてしまいます。
一般的には、大規模なアプリケーションでは厳密な型付けをすることで、型の違いによる不具合が起きにくくなり、その恩恵を受けられると言われていますが、私は小規模なアプリケーションの開発しか経験がないため、そのような場面にはまだ出会っていません。

Rubyで静的な型解析がどのような場面で必要とされているのか、そして登壇者がTypeProfの開発を始めた背景や、どのような問題解決に取り組んでいるのかについて知らないため、この発表の素晴らしさを理解できず悔しい思いです。 動的型付け言語と静的型付け言語の違い、そしてどのようなケースでどちらを選択するのが良いのかについて、学び直したいと思っています。

⑦Build Your Own SQLite3 （Hitoshi HASUMI）

 はじめにSQLite3についての説明がありました。
SQLite3は、高速かつ効率的なオープンソースのRDBMSであり、実行ファイルは非常に小さく、リソース消費も少ないため、iOS/Androidアプリやカーナビ、ブラウザなど、リソースが限られている環境でも効果的に使用できます。 
今回はMiconで動作するPicorubyでSQLite3を動作させる方法を中心に講義が展開されました。
SQLite3でRubyのメソッドを実行する仕組みについての説明がありましたが、正直なところ、内容を完全に理解することは難しかったです。 

最後に、この仕組みを使って独自のキーボードを作成するデモが行われました。キーボードが押下されたときに、そのキーと時刻をSQLite3に記録していくことでデータを蓄積し、どのキーがどのタイミングで使用されているかなどを分析していきます。
そして、分析結果から最も効率の良いキーボードの配置を導き出します。例えば、"RUBY"とタイプする場合、"R"と"U"、"B"と"Y"が左右に分かれていたほうが早くタイプできます。この仮説と分析結果を基に、キーマップを生成していきます。

結果として作成されたキーマップでは、'h', 'j', 'k', 'l'が人さし指の部分に集中することになりました。これは登壇者が頻繁にvimを使用しているため、vimのキーとなる文字がタイプしやすい人さし指の近くに集中してしまい、本来の意図とは異なる結果となりました。

所感
MiconでSQLite2を動かすことの意義として、「誰もやってはいないけどできそうだからやった。できそうなことはやってしまえば、使い方は後から誰かが見つけてくれる」と話されていました。 

もちろん、世の中の課題を解消するために開発をする人も多いと思いますが、この方のようにできそうなことがあれば片っ端から手を出していくという発想を持っている人がいるということが新鮮でしたし、その考え方が非常に素晴らしいと思いました。

OSSの開発者は雲の上の存在というイメージで、どんな考えの下、日々開発を行っているのかというのはあまり着目されません。だからこそ、RubyKaigiで開発者がどういった意図で活動しているのかというのを知ることは非常に有意義なことだとも改めて感じました。 

普段の仕事でも、課題を洗い出し、それを解決するアプローチになりがちですが、できそうで面白そうなものにいったん手を付けてみるというアプローチも一つの手段だと思います。そこから新たな発見が生まれることもあるということに気づかされる講義でした。

キーボードの自作という趣味の領域から始まった開発かもしれませんが、それがRubyKaigiで何百何千人の前で発表される内容になっていることが素晴らしいと感じました。

⑧Ruby + ADBC - A single API between Ruby and DBs （Sutou Kouhei）

 「Embulk」というJavaで実装されたバルクデータローダーがあり、これはJRubyをサポートしています。しかし、EmbulkはJRubyのサポートを徐々に縮小する計画にあることを発表しています。 
この講義では、Embulkに代わる次の可能性として「ADBC」を取り上げ、その特徴や利点について話されていました。

ADBCはデータベースへのアクセスのための共通APIであり、RubyにおけるActive RecordやSequelに相当するものです。その特徴としては、多言語対応をしていることや、大規模な列指向データの最適化に向いていることが挙げられます。 
「大きな列指向データ」とは、具体的には一つのカラムに100万レコード以上存在する場合を指し、例えば整数値のカラムが一つだけで1,000万レコードある場合、libpqと比較して2倍ほど速い処理が可能です。

また、ADBCは接続先のデータベースが異なっていても、libpqドライバーが抽象化を担当することで、同じAPIを使用できる便利な仕組みになっています。

所感
講義の後半では、PostgreSQLでFlight SQLを使う方法やその有効な使用場面についての話がありましたが、具体的な使用方法や用途についてまでは、理解が追いつきませんでした。

近い将来、ADBCを使用してRubyで大量のデータを読み書きできるようになったり、ActiveRecordを介してADBCを使用できるようになるということは漠然と理解しました。

この講義でADBCやEmbulkの存在を初めて知りましたし、大量のデータを読み書きするための最適な方法がいくつか存在することも、私にとって新しい知識でした。

正直なところ、難しい内容でしたが、Rubyでデータの読み書きを行う際にどのような仕組みが使用されているのか、どの方法を使うと効率的になるのかという点について、ADBCを含めて知識を広げていきたいと思います 。

新卒１年目／大杉貫剛の感想まとめ

はじめまして。新卒１年目の大杉貫剛です。
自分は13本の講演を見てまいりましたが、その中から６本の感想を以下にまとめました！ 

①RuboCop's baddest cop（Genadi Samokovarov ）

スピーカーのGitHubに存在する、あらゆるRubocopのエラーとその改善案について実演形式で紹介いただきました。
Rubocopの性能は、コードに書かれる「（）」の存在、特に書かれる位置によって大きく左右されると説明されていました。印象的だったのは再三出てきた言葉「Ambiguous（曖昧）」でした。細かなコードの書き方の違いでRubocopのエラーが発生することに、ついイライラしてしまうユーザーの裏で、この「Ambiguous（曖昧）」を改善しようとする開発者のトライandエラーを見られたのは非常に貴重でした。

そして改善に対する行動が非常に印象的で、最後の言葉を特に覚えています。「We ran robocop only git changed.（Gitを変化させたときにしか、Rubocopは稼働しない）」 

そう、だから彼は１対１のGitHub対Rubocopの結果を講演で見せ続けていたのだと思います。本当に伝えたいのはきっと、こうして一つ一つ動かして、Rubocopの性能向上に一緒に取り組んでいこう、ということ。そのために彼は旗を振っている、叫んでいるのだと感じました。彼のスライドの作り方、話の段取り、それらはすべてここに集約されている気がしました。 

② Understanding the Ruby Global VM Lock by observing it （lvo Anjo）

Rubyの実行速度が遅いのは、多数のメソッドを走らせることに起因しています。それを実際に可視化して、示してくれる講演でした。Rubyの積年の課題である実行速度という問題について、一つの側面からとらえられました。 
特に可視化して描画のスライドで示されていたことが非常にわかりやすかったです。「実行したいのに実行できない」そんなスレッドが詰まっている状態があることがわかりました。 

そして、この「実行したいのに実行できない」の時間はスレッドが多くなるにつれて延びることがわかりました。強調したいのは、遅いのはスレッドの処理そのものではないということです。 

さらに興味深いのは、Rubyのスレッドはオペレーションシステムと1:1ということです。実はこの「実行したいのに実行できない」の時間を持たないカウンタースレッドがあるらしいです。これはおそらく、オペレーションシステムごとの相性によるものだそうです。これを見つけられたら、Rubyの世界の境界線がまた一つ広がるのじゃないだろうかという将来性を見据えた講演でした。

 ③UTF-8 is coming to mruby/c （ Mari Imaizumi ）

大きなトピックは「絵文字の数をカウントしたいけれど、できない」という問題でした。 
絵文字.sizeでカウントできるかと思われたそれは、絵文字のByteをカウントしてしまうためにうまくいかないという実行と理想の乖離（かいり）が起こっていました。 

前提として、StringがByte列なのでエラーが起こります。ただByte列は、それぞれ先頭の列がByteによって決まっています。よって、このByte列から、何文字あるのかを割り出せます。そんな論理だった計画と実行で、課題を解明していく内容がわかりやすかったです。当たり前に使うUTF-8が存在しない世界があったことにも驚き、さらにそれを実装する中身を具体的な課題の中で認識できたことが何よりも面白かったです。 

④Power up your REPL life with types （ Tomoya Ishida ）

irbの予測検索を作成したという内容の講演でした。 
従来はメソッドチェインが長すぎて、予測を上げだせばきりがないので、実装しないことがトレンドになっていました。この課題を解決するために開発したのが「katakata.irb」というGemでした。 

作り方は３ステップありました。 
その１：irbはそもそも不完全なコードを書くので、意味のある部分だけを抜き出せるようにすること。 
その２：RBSを使って、メソッドチェインを評価すること。 
その３：irbの完了を上書きして、忘れないようにすること。 

これらステップの具体的な内容までは非常に難しく理解が及びませんでした。普段何気なく使用する予測検索の裏側がどれほど高度な内容で作られているのか、それを肌で感じられたことがとても貴重な機会でした。 

⑤Optimizing YJIT's Performance, from Inception to （ Maxime Chevalier-Boisvert ）

こちらはキーノートの講演でした。YJITの開発者が登壇され、その誕生から最適化されるまでの変遷をお話しいただきました。 

まず課題感としては、やはり早くて正確なものを作りたいという思いからでした。しかしYJITの前身として作られたマイクロJITなどは、やはり実験的なものに過ぎず、十分な成果を上げられずにいました。これを解決するためのキーワードが「Benchmarks」でした。この「Benchmarks」を適切に設定することで、問題の所在を顕在化させ、徹底的に改善し最適化できるようになったといいます。 

具体的な「Benchmarks」の例として、Headline Benchmarks, Other Benchmarks, Micro Benchmarks などが挙げられており、その具体的な改善方法は難解だったものの、このプロセスはとても印象的でした。YJITの今後の課題としては、やはり継続的に速さの改善とメモリ使用量の部分が挙げられていました。 

「あなたが推測できないものは、改善できない」という言葉がまとめの部分で紹介されていましたが、やはり課題の所在を推し量れなければ、改善することはそもそも不可能であるという、エンジニアの世界以外にも共通する教訓を得られたことは、とても貴重な機会でした。  

⑥The Adventure of RedAmber - A data frame library in Ruby（Hirokazu SUZUKI）

RedAmberというRubyで書かれたデータフレームライブラリについての講演でした。データ学習（機械学習）といえばPythonなどが有名ですが、Rubyでもできないかと初めてOSSの開発に着手した挑戦の結果を紹介いただきました。 

RedAmber の特徴的な部分は主に四つありました。 
一つに、同じ型のデータ（ベクター）を作って並べ２次元データにしていること。これはSQLのテーブルとほぼ同じです。次に、ラベルには唯一性を帯びさせること。そして欠損値にnilを持るようにしているそうです。
三つ目にRubyの配列やハッシュで返してくれるようにすることで、Rubyらしさを実現していること。これがRedAmberの何よりの特徴で、Rubyらしく感覚的にコードが書ける、扱えることにこだわったそうです。最後にベクターを変化させることのできるメソッドを多数用意していること。 

作成して終わりではなく、使ってもらうことがゴールだと話していたことが非常に印象的でした。

新卒１年目／高城友梨香の感想まとめ

 同じく新卒１年目の高城友梨香です。
私は８本の講演を見てきました。正直、まだわからない話が多くありましたが、いつかこれが全部わかる日がくるよう頑張ります！

①DIY Your Touchpad Experience: Building Your Oun Gestures （Kohei Yamada）

Linuxでタッチパッド操作が可能となるfusumaというGemを紹介していただきました。
Fusumaの使用方法や、ジェスチャーとアクションのカスタマイズについての説明や、どのようにしてこのFusumaを作成したかについてのお話がありました。
その中でも１番印象的だったのは、作成方法の一つとして挙げられたジェスチャー認識に関してです。 libinput-toolsでは、指の認識に関して実際の出力を見ました。何本の指で触っているかや、どのくらいの面積でどの程度触っているのかを検知したものが実際に画面出力されていてとても面白かったです。 

感想 
自分の手になじむツールを自分で作る！！という言葉が印象的でした。タッチ操作一つをとってもおのおの使いやすい方法などは違います。それを自らカスタマイズできるようにしていたのがとても魅力的でした。 

②Develop chorome extension with ruby.wasm （Yuma Sawai）

Ruby.wasmを利用したchrome拡張機能を楽に実装するためのフレームワーク、「unloosen」の開発についての紹介でした。
chromeの拡張機能を使えば、ブラウザの機能をもっと自分で使いやすくできます。その中で、unloosenを使用するメリットとして、シンプルに書け、スクリプトをすべてアプリケーションに入れられるためファイル数を少なく管理ができる、毎回読み直す必要がないなどがありました。
拡張機能の実装においてRubyで実装することにより、インポートすることが不要なため簡単に拡張できたりと、Rubyの良さが伝わりました。

Manifest.jsonからRubyのVMを起動し、chrome各省機能で必要なファイルはすべてRubyで記述できるようになっていました。スピーカーである Sawai Yuma さんは作った感想として、ライブラリの設計が難しかったことや、まだまだ改善の余地が見込めるためフィードバックをたててくれるとうれしいとおっしゃっていました。Ruby言語の可能性の大きさを感じられました。 

感想 
今回参加した講義の中で１番の盛況ぶりでした。座れず立ちながら視聴しました！！
そしてなんと、スピーカーであるSawai Yumaさんはまだ大学３年生であると聞き驚きました。去年初めてRuby会議に参加したときRubyがブラウザで動くオンラインデモを見たことがきっかけとなり、自分が登壇することを目標にしたそうです。それを１年でかなえられたそうです。驚きの速さで、私も負けていられないなと思いました。 

③The future vision of Ruby Parser （Yuichiro Kaneko）

現在はLALRパーサを利用しているもののこれには保守性と使いやすさの点でいくつか問題点があることがわかっています。そこで開発したLramaというパーサについての紹介がありました。 

不足したトークンを挿入することで、補間処理を可能にし、natural attributesとBisonを組み合わせることでバージョン交換を行い、ユニバーサルパーサを実現することに成功したという内容でした。 

感想 
そもそもパーサというものを知らなかったので、事前に予習していきました。 パーサにもいろいろなものがあるとは知っていましたが、自ら開発し問題点を解決したものを作成していて圧倒されました。 

④Lightning Talks

そもそも私は、予習をするまでLightning Talkというものを知りませんでした。調べてみるとライトニングトーク（Lightning Talk）とは、約 ３ 分から 5 分にかけて行われる短いプレゼンを指すと書いてありましたが、プレゼンテーションの一言では収まりきらないほどの熱量でした。

始まると5分ごとにRubyに関しての成果や思いなどをそれぞれが熱く語っていて会場も大盛況でした！　内容が全くわからないものもあったのですが、その熱量だけは毎回伝わってきました。

中でも私が印象に残っているトークは、あおいゆらさんの「RubyKaigi2022で転職」です。RubyKaigiのDrinkupでお話しした人にブックウォーカーに入りたいと相談したところ、なんとたまたまブックウォーカーの方だったらしく、そのまま転職採用が決まったらしいです。RubyKaigiでのつながりの偉大さを感じました。
また、転職先でプロジェクトの仕様がわからないものでもリファクタなどは自分だったらできると行動したことから、簡単なところから少しずつ事業改善を行い実装していくことの大切さについてお話されていたのも印象的でした。

感想
RubyKaigiに参加したことがきっかけで転職が決まったというなんともドラマみたいなお話でした。この話を聞いて自分もイベントや、このような多種多様な人が集まる場で積極的に動いていくことでもしかしたらチャンスをつかめるかもしれないという可能性を見た気がします。

また、私はまだ入社して１カ月と少ししか経っていない未熟者です。実際自分は、まだ実務には携われていないですが、少しずつ自分のできることを見つけ自ら積極的に働きかけていくことで仕事の幅を広げていきたい思いました。
 

⑤Yet Another Ruby Parser （Kevin Newton）

 既存のパーサを書き換えたYARPという新しいパーサの紹介でした。エラートレランス、ポータビリティ、メンテナンス性を向上させたいという思いを反映していました。不足しているトークンやノードを補ってASTを得て、さまざまなランタイムに対応したユニバーサルパーサを目指したと話されていました。今後としては、トークンの先読みやメモリの削減を目指すそうです。

感想
この講義では、私が参加した講義の中で初めてのオンライン講義でした。ですが、やはりオフラインのほうが実際にお会いできるという点や、質問などがしやすかったりとオフラインとオンラインを交えたことで両サイドのメリット、デメリットを改めて感じました。
この講義もパーサのお話でした。現段階でパーサが抱えている問題点にアプローチしていて、さらにトークンの先読みやメモリの削減をしていくことで有用性を高めていて素晴らしいと思いました。純粋にこのパーサを使いたい！と感じました。

⑥The Resurrection of the Fast Parallel Test Runner （Koichi ITO）

並列テストの重要性と実現方法やtest-queueに関するお話をいただきました。 
高速なテストを行うためには、お金を投じてＣＰＵやメモリを増強したり、チューニングをして早くする方法などがあるが、今回の講演では、並列処理でそれらを実現する方法について紹介されました。 
並列テストを行うことにより、テストの実行時間を大幅に短縮することが可能になります。 

並列処理の方法についても四つご紹介されていました。 
一つ目は、Rubyのフレームワークであるminitestを利用する方法。二つ目はRails７を利用する方法。
そして事前にテストを分割し、parallel gemを利用して並列処理を実行する方法、最後にtest-queueに関して紹介されました。
中でも、test-queueのお話が興味深かったです。テストをqueueにいれ、workerがそれを取り出して処理することで分割しなくとも実現できます。
しかし、このtest-queueは当時メンテナンスがされていなかったため、スピーカーがメンテナになることを決意したことで、４、5年ぶりにメンテナンスが再開されました。 

感想 
どうやって並列処理がされているのか普段全く考えていなかったので、勉強するきっかけになりました。テストを書くということも大事ですが、根本どうやってテストが実行されているのかというところにも注目していくことでさらに理解が深まると感じました。 

⑦Multiverse Ruby （Chris Salzberg）

Rubyのコードを限定したモジュール内でのみ展開を行い、競合がないポータブルな共有を可能とするImというGemについての紹介が行われました。
名前の競合に関しては、適宜課題感を得ていたため、解決しようと至ったとおっしゃっていたところ、それに同意している観客の方が多くいらっしゃいました。

ImはRuby3.2の新機能である二つを利用してモジュール先を指定してコードをロードしたり定数の変更をキャッチしたりできるgemです。この方法でロードすることでコードの各ユニットが独自空間に配置され、名前の競合を避けることが可能になります。 
名前の競合を解決するにあたり、知っていくうちにその仕様の理解が深まったことも利点に上げていて、課題解決だけでなく過程も大事にしていることにとても感銘を受けました。

感想 
純粋にImというGemを使いたいと感じました。名前の競合に課題感を得ているのが納得できたほか、そこで自ら開発に至り成功させているのが
と感じました。会場の雰囲気も明るく、笑いも何度が起こっていてプレゼンテーションもわかりやすく、全体的に満足のいく講演でした。 

⑧Find and Replace Code based on AST （Richard Huang）

ASTを使って、コード検索や置換を行うツールであるSynvertに関しての紹介でした。 

まずASTのメリットについて、正確であることと、複雑な置換ができることを上げていました。発表者は、もともとRailsのアップデート作業を楽にするためにこのツールを作成されたそうです。SynvertはいくつかのGemに分かれている構成になっていて、NodeQuery 、NodeMutation、SynvertCoreがありました。Synvertは、Web上のPlaygroundで気軽に動かすことが可能だそうです。 

Rubocopとの比較では、Synvertの機能をRubocopでもほぼ同じように使用できるが、Synvertは通常のコードと同じような感覚で使えることがとても有用だそうです。 

感想 
そもそもASTを知らなかったため事前に予習をしてこの講義は参加しました。予習のおかげでおおむねこの講義を理解できたと思います。このSynvertは実際にWebのPlaygroundで利用できるそうなので、少し触りました。 この講義を経て、実際にその後の自分の行動へと移せたことは開発者としての１歩だと感じました。 

学生インターン／ 大塚和哉の感想まとめ

 こんにちは。学生インターンの大塚和哉です。
（＞＞＞大塚さんが登場する記事はこちら）

私は６本の講演について、レポートをまとめました。
非常に勉強になりました。とにかく面白かったです…！

①On Ruby and ꝩduЯ, or How Scary are Trojan Source Attacks（Martin J. Dürst）

トロイソース攻撃の脅威とその対策についてのお話です。
トロイソースというのは、トロイの木馬という有名なマルウェアに由来しており、一見なんの問題もないソースコードに実は脆弱（ぜいじゃく）性が仕込まれているといった攻撃です。

通常セキュリティーの話は外部からの攻撃についてが多いように感じますが、トロイソース攻撃はソースコードを書いているプログラマーによる内部犯行の可能性が高く、普段とは違った視点でとても興味を引かれました。

講演の中ではいくつか例題が出され、例えば

というコードがあった場合、白が正解なら左、黒が正解なら右を挙げるよう言われました。これならRuby初心者の私でも簡単です。正解は白！左手を挙げます。

しかし正解はなんと黒！
実は、３行目の左辺にあるwhіtеはіとеがそれぞれキリル小文字で書かれた偽物のwhiteだったのです。そのため、本物のwhiteに6.5を足した数は偽物のwhiteに代入、本物のwhiteは40のままなので、結果としては黒が正解です。これはホモグラフ攻撃という、肉眼では判断できない文字でだます攻撃です。トロイソース攻撃以外にも、URLをだますフィッシング攻撃に使われます。
これ以外に他の攻撃手法を使った例題でもすべて白と思わせて正解は黒、会場にいたほとんどの人がだまされて笑いが起きていました。

この講演のスピーカーであるMartin氏は日本国内の大学で教授をされているとのことで、受講している人たちを飽きさせないプロの工夫があり、英語をあまり聞き取れない私でもわかりやすく、とても面白かったです！

②Build a mini Ruby debugger in under 300 lines（Stan Lo）

 タイトルには300行と書かれていますが、実際の講演では200行未満のコードを手軽にデバッグできるツールの紹介でした。
(講演に使われたツールはこちらです)
このmini-debuggerのdemoを見せながら、デバッグがどのように実装されているかを解説、それを把握した上で他のデバッグツールとの違い、どのデバッグツールを選べば良いのかという説明をされていました。

私自身、デバッグツールはエディターやブラウザで軽く触れたことがあるくらいで、ほとんどデバッグというものを意識したことがありませんでした。強いて言えば、エラー発生時のバグ特定で、どこまで正しく値が入っているのかを追うためにputsメソッドを使って出力していたくらいです。（講演の最後に知りましたが、このputsを使う方法も立派なデバッグなのですね！「printデバッグ」とも言われるそうです。）

これを機にデバッグツールを使ったデバッグを私も試してみたいと思います！

③Make Regexp# match much faster（Hiroya FUJINAMI）

Regexpとは正規表現のことで、この講演のスピーカーであるFUJINAMI氏は、Ruby3.2.0で新たに最適化された正規表現マッチングを実装した功績から、学生ながらにしてRubyコミッターへ参画されたとてもすごい方です。

Ruby3.2.0以前は正規表現マッチングによる脆弱（ぜいじゃく）性を利用したReDoS攻撃の脅威にさらされていました。この脅威を取り除くために、どのように正規表現マッチングを最適化、ならびに高速化させたのかについて詳しくお話しされていました。

私自身、Rubyの学習過程でメタ文字を使った正規表現を触ったことはありますが、簡単なパターンでも理解するのに少し時間がかかるくらい私にとっては難しい内容です。そのためこの講演において、使用した関数などの詳しい実装部分はあまり理解できませんでしたが、FUJINAMI氏のゆっくり丁寧な解説のおかげもあり、これまでの課題と解決点、今後の課題についてだけでも理解することはでき、とても面白かったです！

既にエース級の活躍をされていますが、まだ新しくRubyコミッターに参画されたばかりということで、今後さらにRubyでどのような実装をしていくのか、FUJINAMI氏の今後を追いたくなる素晴らしい講演でした！

④"Ractor" reconsidered（Koichi Sasada）

 本講演のスピーカーである笹田さんが開発したRactorについてお話しされていました。RactorはRuby3.0で導入された、Ruby上で並列コンピューティングを行う仕組みで、「Ruby3をRuby2の３倍速くする」ことを目標に掲げている「Ruby3×3」の軸の一つである「並行処理」を行うために開発されました。

ベストケースであれば３倍どころか４倍近く処理が高速化するようですが、現状では逆に２倍遅くなってしまうケースもあるようでまだまだ課題は山積みのようです。課題解決の鍵として、M:Nスレッドによる性能向上を挙げていました。M:Nスレッドについては理解が及ばない概念なのですが、昨年のRubyKaigi2022で発表されていたようなので、チェックしてみようと思います。

今後、うまく開発が進んでいけば、Rubyがまた一つ進化しそうな予感がするので非常に楽しみです。

⑤Load gem from browser（SHIGERU NAKAJIMA）

Ruby3.2.0からWebAssembly（以下Wasm）がサポートされました。Wasmとは、ブラウザ上でJavaScript以外のプログラミング言語を動かせる仕組みのことです。Rubyでは、ruby.wasmを使うことで、Rubyスクリプトを動かせるようになります。

ruby.wasmを使ったサンプルアプリケーションを見てみると、さまざまなアプリケーションを作れることがわかります。

しかし現状、ruby.wasmはruby.wasmが用意した読み取り専用のファイルシステムのみ使用できます。つまり、標準ライブラリのみ使用できて、サードパーティー製のgemは使用できません。本講演は、サードパーティー製のgemもruby.wasmで使えるようにしようというお話です。

かつてはJavaScript（以下JS）も、あるJSファイルから他のJSファイルを読み込んだりなどはできませんでした。しかし、Node.jsの登場からモジュールという概念が登場し、ES2015ではブラウザに標準対応しました。そして現在はimport-mapsという、パッケージをダウンロードするURLにエイリアス名を付ける仕組みが登場し、外部パッケージを容易に管理できるようになっています。

このJSの歴史になぞらえ、今回はrequireやrequire_relativeを駆使して、サードパティー製gemを使えるようにしていました。

ブラウザ上でRubyを動かせるのは、環境依存が低減されて非常に魅力的です。サードパーティー製のgemも駆使できるようになれば、ブラウザ上だけでかなりクオリティーの高いWebアプリを作れると思うので、とても興味が湧きました。

⑥Unleashing the Power of Asynchronous HTTP withRuby

「Async::HTTP」というRubyで非同期HTTPを行うためのライブラリについて、その用法やベストプラクティスのお話です。

本題に入る前に、まずはHTTP/0.9からHTTP/3にかけて、クライアントとサーバー間のインターフェースの変移について詳しく解説されていました。かなり長い歴史のお話になってしまうので詳細は省きますが、GETメソッドのみサポートされ、コンテンツはテキストのみしか受け取れず、それも１回のリクエストが終わるまで次のリクエストを送れなかったような時代から、どのようにしてHTTPが進化し、リクエストの多重化と非同期通信ができるようになっていったのかを説明していました。

HTTPの歴史を踏まえ、スピーカーのSamuel Williamsさんが開発に携わっている「Async::HTTP」ライブラリを使用して、Rubyによる非同期HTTPを実装、ライブラリの内部に関しては詳しく説明されていませんでしたが、このライブラリを使って書かれたコードにはHTTP33年分の複雑さが隠されているとおっしゃっています。

また、ベストプラクティスとしては、共有インスタンスを使用することで、既存のHTTP接続を再利用した永続的な通信を行うことなどが挙げられていました。

初めはテキストしかやり取りできなかったHTTPですが、HTTPの進化に伴い、さまざまなコンテンツがサポートされたことで、コンテンツの円滑なやり取りのために非同期通信は必須のものとなりました。今回のようにRuby単体で非同期通信を行うような機会はあまりないと思いますが、この講演のおかげでそもそも非同期通信がどういう仕組みで行われているのかについて、HTTPの歴史に沿って学べたことが良かったと思います。

メンバーの感想は以上となります。
もりだくさんの内容で、大盛況に終わったRubyKaigi2023。
ここで得た学びを若手メンバーがどのように生かしていくのか、今後のRIZAPにご注目ください！