RubyKaigi 2022 09/09(2日目) 参加レポート

# はじめに

RubyKaigi 2022に参加してきましたのでそのレポートです。

[RubyKaigi 2022](https://rubykaigi.org/2022/)

## 前日のレポートはこちら
https://qiita.com/yoshiki-0428/items/b3a64e2f03efc9394f39

# Event

RubyKaigiではKeynote以外のイベントがありました。多くの企業の協賛やノベルティを配っていました。

[https://rubykaigi.org/2022/events/](https://rubykaigi.org/2022/events/)

![Screenshot_20220908-092014.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/8b61206d-e6bc-8cd1-8715-999450eb9060.png)

## ○×クイズ

賞金10万アマゾン券をかけた○×クイズ、弊社の一人が最後まで当てていて1万円を手に入れてました。（いいな）

![PXL_20220909_033452626.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/fed6b272-d94c-59f1-2f85-3eb0e6033f5d.jpeg)

## スポンサー企業一覧

サインかっこいい、、、！

![PXL_20220909_042949368.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/8903246a-ae02-adba-a94a-094329288190.jpeg)

## Findyさんのガチャガチャ

１等は高性能充電器で普通に嬉しい

![PXL_20220909_035819390.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/f010dd11-0b5c-1c21-84c0-592f1d28f3c5.jpeg)


## スタンプラリー

![PXL_20220909_040956887.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/79c32193-80e9-c26e-8777-bdedbf9e3c23.jpeg)

# Today’s Schedule

![Screenshot_20220909-093228.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/bbee32e6-99e1-e51f-217c-0f8c760c605a.png)

# Matz Keynote

[Matz Keynote](https://rubykaigi.org/2022/presentations/yukihiro_matz.html#day2)

![Untitled.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/08b18555-ac34-afcc-c68e-cb735998a31f.png)


## 色々な人にアドバイス（文句）を貰った

### Ruby is too good to be a scripting language

スクリプト言語としてRubyは良すぎるｗ

### Scripting languages do not need OOP

スクリプト言語にはオブジェクト指向はいらない

### You shouldn’t have created Ruby We should focus on Perl.

あなたはPerlを作るべきだった。

### Ruby is slow / Web age is over / Ruby is dead yearly

遅い、ウェブの時代は終わった、ルビーは毎年死んでる

## 全部フェアな批判ではない

データに基づいた批判ならわかる

## 言語を使ってるだけの人からRubyは死んだと言われる

データのない批判・文句を言いたいだけの人は無視をして我々は先に進もう

## Rubyの価値とは？

- 生産性が高い
- コミュニティ
- 喜び
    - 色々なところで使われてて嬉しい
- お金
    - 2001年のカンファレンスは34人しかいなかった
    - 2022年は色々な人が集まってきた
    - Ruby自体がお金の価値を生むようになった
    - Top Ruby Companies
    
    [Top Ruby Companies](https://t.co/gq6ZhGQL8e)
    
    [A Roundup of the Top 28 Ruby on Rails Companies in 2022](https://distantjob.com/blog/ruby-on-rails-companies/)
    
    - 企業価値でRubyが使われてる会社は52%で上位
    - 価値があるのだから親切な人達の意見は無視しよう、前に進もう
- Bugs / Fixing/Implements / Documentation / Gems
    - こちらに [https://bugs.ruby-lang.org](https://bugs.ruby-lang.org)
    - 大抵はRejectされるけど頑張ってね
    - [https://github.com/ruby/ruby](https://github.com/ruby/ruby)
    - Gemは特殊な名前がある / nokogiri / kaminari

## What’s new Ruby 3.2?

- Ruby on WASM
- YJIT on Rust
- Shaping Thread
    - 100万スレッド作れるかも
- Data object
    - Data 定数が使えるようになった
- Syntax gems
- error highlight
    - RubyMine, Solargraph, Rubocop

## 質問

- 最近面白いと思ってる新しいプログラミング言語はありますか？
    - ergという言語が面白そう
    - [https://github.com/erg-lang/erg](https://github.com/erg-lang/erg)
- ユーザーからのFeature Requestsを取捨選択する基準はありますか？
    - 既存機能にあるか
- 以前のお話で、ASTクラスを公開したのはツールのため、というお話だったかと思うのですが、今後機能強化をする予定はありますか？
    - 具体的にはまだない、前段のparserはなんとかしたい
- RustはMRI（Matz Ruby Implementation）に入るのでしょうか？それについて葛藤などがあったのであれば教えてください
    - 開発者のベロシティを向上させるために許可した
- LSP の拡充以外で足りないと思ってるツールってありますか？
    - typeof, steepでもっと強化できないか
    - RuboCopのルールを選ぶのがたるい

# Do Pure Ruby Dream of Encrypted Binary Protocol?

[Do Pure Ruby Dream of Encrypted Binary Protocol?](https://rubykaigi.org/2022/presentations/yu_suke1994.html#day2)

[JavaScript is not available.](https://twitter.com/yu_suke1994)

## 何の話？

- 暗号化されたバイナリープロトコルの夢を見るか？
- QUICのことを指す RFC 9000 UDPで実装
    - [https://www.fastly.com/jp/blog/quic-is-now-rfc-9000](https://www.fastly.com/jp/blog/quic-is-now-rfc-9000)
- TCP
    - 信頼性は高い
    - 効率性は悪い
- UDP
    - 効率は高いけど、再送制御がなく信頼性が低い
    - 音声通話などに使われる
- UDPの上にTCPを実装することで両方の良いところをとる
- 去年はRactorで実装してみた
    - 今年はやらない、通信プロトコルがそもそも難しい、Ractorも新しく情報がすくない、ppも使えない

## QUICの実装

- 通常は
    - message が届いたら理解して送り返す { ‘text’: ‘aaa’, ‘hoge’: ‘Hello!’ }
    - これを繰り返す
- QUICはバイナリーデータで送られてくる
    - Rubyはバイナリ変換後がStringで帰ってくる
        - 2進数を再度変換できてしまうのでミスが増える
    - JavaはByteBuffeという型があるので間違えることが少ない
    - Rubyには専門の型がないからミスが増える
        - ライブラリが存在する
            - [https://github.com/msgpack/msgpack-ruby](https://github.com/msgpack/msgpack-ruby)

### 速度比較

RubyはIntegerのほうが早い、Rustはもはや見えない

![PXL_20220909_020754449.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/9c0012b5-9c1e-0a08-8762-1f24f3974167.jpeg)


## Pure Rubyという選択肢がなくなると？

- Rubyでないのであれば
    - C, Rustでもよいのでは？

## RubyにByteというクラスが追加される？

それはRubyにはもはや作ってほしくはない、そもそもbyteというGemsがあるし

[https://rubygems.org/gems/bytes](https://rubygems.org/gems/bytes)

## まとめ

- 標準ライブラリのみではすべてStringとして扱われる
    - 速度が不利
    - バイナリデータに対して同じ処理を行えてしまう
    - ミスがしやすい設計
    - 解消するにはxorに複雑になる
        - それに長けた言語で実装するべき（C, Rust）
- なぜRubyを選んだのか
    - これから導入されるRactorやマルチスレッドとの問題を避けるため

# ****Make RuboCop super fast****

[Make RuboCop super fast](https://rubykaigi.org/2022/presentations/koic.html#day2)

@koic OSS Programmer

- Rubocopは世界中の開発者で作られている

## 早くするために工夫

- デフォルトでRubocop Cacheがきいている
- Multi core対応
    - autocollection pallarel run
    - 6倍くらい早くなる
- 未使用のrequireをへらす
    - すべてのCopが
- rubocop/server だけで使うものだけで限定するように
    - 850xに！

## rubocop-deamon

- rubocop-deamon startでバックグラウンドで実行される
- 実行中のため高速化される、効率良い
- 開発体験が良さそう
- [https://github.com/fohte/rubocop-daemon](https://github.com/fohte/rubocop-daemon)
- 既に rubocop/rubocop に導入されている
- require ‘rubocop/server’という軽いものを用意した

<aside>
🔥 コードにしたものとコードにしなかったものがプログラミング

</aside>

## なぜrubocop-deamon作ったのか

- 今使われているコマンドでまた新しいコマンドをつけたくない
- Option化したほうが良いと思った

## 使い方

- Server mode option
    
    `rubocop --server`
    
- 起動したときのプロセスはレポジトリ/dirごとにプロセスが起動する
    - hogeA/ruby
    - hogeB/ruby
- rubocop --stop-server
    - 不安定なときに使ってほしい
    - Gem Update / Installしたときなど
- rubocop --restart-server
    - 変な動きがあればrestartする
- server modeのプロトコルについて
    - TCP/IPが使われている

## Useful option

rubocop —server

rubocop —restart-server

# ****How fast really is Ruby 3.x?****

[How fast really is Ruby 3.x?](https://rubykaigi.org/2022/presentations/fujimotos.html#day2)

## Talker

Fluentdのメンテナー

## 何の話？

Ruby 3のパフォーマンスについて話す

- Ruby 3x3（Ruby3を3倍早くしようという計画）
- 過去の比較の話をする

## YJIT

去年Ruby 3.2に入った。まだ使われていない。限られた範囲でデプロイしている状態

まだ使われていないので是非使ってほしいとのこと。

## Intro Fluentd

NginxからのログをElasticsearchAPI, PostgresSQLに投げる役割

![https://abicky.net/assets/20171023/fluentd-architecture-faa0125437b95b2d4a53a95d6035100ea470c96b51e3c6b32ad6b79200d859f91920a452f862006aff2f189026c9cb9e21200282a27f9d443ba373aa9876103e.png](https://abicky.net/assets/20171023/fluentd-architecture-faa0125437b95b2d4a53a95d6035100ea470c96b51e3c6b32ad6b79200d859f91920a452f862006aff2f189026c9cb9e21200282a27f9d443ba373aa9876103e.png)

Fluentdのレコード処理は1秒あたりに1万件、日だと4~10億ぐらい流れている

決して多くはない。普通の量。FluentdはRuby Runtimeを使い倒している

## 過去の比較について

大抵の比較記事はRailsと比較している。RailsはDBアクセスが発生するので、Ruby自体はまっている時間が多い。処理の大半はRuby Runtimeで費やされている。

Rubyが早くなっても意味はない。

![PXL_20220909_051945048.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/f4a3258b-1ccc-c008-878a-97912e8ece36.jpeg)

[https://www.youtube.com/watch?v=qKQcUDEo-ZI](https://www.youtube.com/watch?v=qKQcUDEo-ZI)

## つまり

Fluentd は非常にRuby Runtimeに依存している

Rubyのバージョンごとにスナップショットがあるので安定

## 今回の検証

Largeファイルを読み込ませて行に展開し、カウントする

![PXL_20220909_052234332.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/5e91b369-5144-efed-d608-b02cd5aa25de.jpeg)

バージョンが上がるごとに読み込める行数が増えている。初期と3.2.0+YJITと比べると約3倍に上がっている

![PXL_20220909_052323719.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/75b327f2-9a19-9fde-1f6f-641bd640a594.jpeg)

Ruby3はRuby2の3倍早くなるとMatzが言っていた。

実際FluentdでRuby3x3は実現できた！！

## 言語比較をしてみた

言語候補は `Lua/ Lua JIT / Perl / Ruby3 / Ruby3+JIT / Python`

---

結果的には Ruby3が一番遅かった

![PXL_20220909_053228695.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/9ad6f7bf-36e5-9063-62f9-348ddc9918b8.jpeg)

<aside>
🙀  Ruby3 < Ruby3+YJIT < Lua < Perl < Python < LuaJIT

</aside>

## ここまでのまとめ

- Ruby3x3は実現された
- 他言語と比較すると決してRubyは早くはない
- Fluentdでは Ruby 3.2 に対応している (2022/05)

# ****Packet analysis with mruby on Wireshark - dRuby as example****

## Talker

[https://github.com/shioimm/](https://github.com/shioimm/)

[Packet analysis with mruby on Wireshark - dRuby as example](https://rubykaigi.org/2022/presentations/coe401_.html#day2)

## パケットキャプチャの教科書

この本を見てると話がわかる

[パケットキャプチャの教科書 (Informatics&IDEA)](https://amzn.to/3qsjQqu)

## 何の話？

WireSharkとは非常に広く使われているネットワークアナライザー

WireSharkは非常に多くのプロトコルをサポートしている

- https/ http / tcp / udp / quic
- RubyでDessectorを作る方法
- 実際に使ってみる

## Packet Dessectorとは？

- パケットの解剖者
- 自分でオレオレパケットを自作できる

## Rubyでdissectorを作成した

[https://github.com/shioimm/wireshark_with_mruby](https://github.com/shioimm/wireshark_with_mruby)

![PXL_20220909_055748534.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/5c53872e-7d2c-ff66-6bb3-33ef76f0b51f.jpeg)

WiresharkはCで作成されているのでデフォルトではRubyを知ることはできない

Wiresharkのリポジトリにmrubyのリポジトリを入れることで読み込ませることができる

> mrubyとは [https://www.ipa.go.jp/files/000046423.pdf](https://www.ipa.go.jp/files/000046423.pdf)
> 

## dRuby = Distributed Ruby

離れたPCでもクラスの送信と実行が可能

## つまり

- やってみたことはdRubyを使って端末間通信をWiresharkで見てみようという内容でした。
    - druby://{hogehoge} をWiresharkで見ることができた。
- DemoではStringとIntegerの送信を送っており、監視することができた。
- プロトコルの開発者にとっての便利ツールとなりそう
- 限定空間でプロトコルを作って誰にも見られたくないときにあるとよさそう

# ****Create my own search engine.****

[Create my own search engine.](https://rubykaigi.org/2022/presentations/m_seki.html#day2)

## 何の話？

自分用の検索エンジンを作ってみた

自分にとって最高のサイトを作った

ポケカとSekiについて話す

[「トレーナーズウェブサイト」](https://pokemon-card.com/)

## 検索の考え方

カードの1枚を単語として考える

文書であれば分割しなければいけないのでシンプル

バリエーションがあるとめんどくさい。同じ効果、同じカードがあるので正規化が必要（イラスト、ミラー加工。。。。）

対戦のときにはカードのレア度は関係ない

属性を抽出してTree構造で辞書を作る

```html
11 => 'でんげき'
21 => 11
22 => 11
22 => 11
12 => 'みず'
51 => 12
52 => 12
```

デッキをベクターで考える

例外があるのでその場合は計算時に数を減らして対応した。

## システム全体の工夫

Herokuを使っている

Dyno VM512MB

Dynoは24時間で再起動するので、初期化時にCleanupと収集処理を入れた

## つまり

自分に必要な自分の検索エンジンを作った。

[https://hamana.herokuapp.com/](https://hamana.herokuapp.com/)

# 参加の感想

- 個人的に一番面白かった発表は「****How fast really is Ruby 3.x?****」でした。
    - 現にPure Rubyを使用しているFluentd
    - バージョン比較で1.9と比較すると確実に3倍になってるとともに言語比較だとPythonにはまだ勝てない
    - Pythonも4年後に5倍を目指すと宣言していてどちらも楽しみになりました。
- 一番期待している技術はRBS、TypeProf、Steepといった静的解析、型付けの技術です
    - Rubyに型が付けば保守も怖くない
    - コンパイルせずに間違いに気付ける
    - 構造変更怖くないでかんたんに動かせて守られている言語として一目置きそうかなと思う
- 新しく学んでみたい事柄としてはパケット通信分析です。（Ruby関係ない）
    - 今回の「****Packet analysis with mruby on Wireshark - dRuby as example****」で通信プロトコルを分析するという普段やらないことに興味を持ちました。
    - まずはパケットを勉強します。[https://amzn.to/3qnX9nl](https://amzn.to/3qnX9nl)

# 最後に

来年もリアルイベントだといいなと思うと同時に半年後のEarly birdなら安く手に入るのでまた行きたいと思います！関わった皆様ありがとうございました。

# おまけ

三重で食べた写真を載せておきます

![PXL_20220908_095827535.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/e54254c1-311a-e08e-580b-13b041f643ce.jpeg)

![PXL_20220908_063828541.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/b878de72-2e35-d5fc-d798-2abf1af94df2.jpeg)

![PXL_20220908_025001272.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/641c16d9-512f-e869-25ce-eb5ddfc8e15a.jpeg)

![PXL_20220909_092201202.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/026d218f-95b9-876c-3c98-2ca35540b96e.jpeg)

![PXL_20220909_115450242.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/1295bbaa-e601-7acb-d84b-dde9184a633f.jpeg)