Precena Tech Book
コーポレートサイト採用サイト
  • はじめに
  • ソフトウェア開発
    • 開発環境構築
      • Homebrew
        • Homebrew用語の意味
      • ngrok
        • ngrokの導入
        • ngrokのアップグレード(v2 to v3)
      • Slack
        • Slackの/remind コマンドの形式
        • 対面での相談を気軽にするためのSlack設定
      • AWS CLI
      • Ruby
      • Scala
      • Prettier
      • zsh
        • zsh-completion
      • Mac
        • M1 Macでの開発環境構築(rosetta 無し)
    • バックエンド
      • OpenAPI
        • OpenAPI 定義ファイル分割のすゝめ
      • Ruby on Rails
        • ActiveRecordのfind_or_initialize_byメソッドにブロックを渡したときの挙動
        • Railsのアプリケーションサーバーのプロセス数とスレッド数の設定方法
        • Railsを6.1系から7.0系へアップグレードした時に調査したこと
        • schema.rbで差分が発生する事例とその復旧について
        • tmux + overmind を利用して、複数システムを1コマンドで起動できるよう設定する
        • Rails Migrationチートシート
        • GithubのプライベートリポジトリをGemfileで参照する方法
        • ActiveSupportのto_jsonメソッドの注意点
        • 危険なJSON出力を禁止するRuboCopカスタムルールの作成方法
      • Scala
        • Validated を直列に処理したい
      • DB
        • PostgreSQLにおける、削除行に対するロック獲得時の挙動
    • フロントエンド
      • React
        • Storybookを利用したビジュアルリグレッションテスト
  • インフラ開発
    • AWS
      • IAM
        • スイッチロールの設定手順
        • AWS CLIでのスイッチロールの設定手順
        • AWS Vaultを使ったスイッチロール設定手順
        • Github ActionsでIAMロールを利用してAWSリソースを操作する
      • ECS
      • SES
        • AWS SESメールボックスシミュレーターにて、カスタムヘッダや添付ファイル付きのテストEメールを送信する
      • CloudWatch
        • Amazon SNS + Slack Workflowを使って、CloudWatch Alarmの通知をSlackチャンネルへ投稿する
      • Lambda
        • lambrollでAWS Lambda関数をデプロイしたときのTips
    • Heroku
      • HerokuのStackの設定
      • Heroku Postgresの運用でよく使うコマンド集
  • セキュリティ
    • Web
      • Same Origin PolicyとCORS
      • 脆弱性診断 2社同時依頼実施記録
  • Mail
    • SPF、DKIM、DMARCを使用した迷惑メール対策
  • データ分析
    • データ分析プロセス
  • SaaS
    • Zendesk
      • 問い合わせフォームの項目をサービスごとに出し分け、各サービス担当者に自動で振り分けてメールで通知する
  • イベント
    • RubyKaigi
      • RubyKaigi 2023 に現地参加しました
    • EMConf
      • EMConfJP2025_参加レポート
  • やってみた
    • IoT
      • Raspberry Pi + PaSoRi + Python で、勤怠打刻マシンを作ってみた
  • Precena Tech Book 管理
    • コンテンツ執筆時のルール
  • 関連リンク
    • プレセナエンジニア公式Twitter
GitBook提供
このページ内
  • はじめに
  • 印象に残ったセッション
  • The Resurrection of the Fast Parallel Test Runner
  • Revisiting TypeProf - IDE support as a primary feature
  • Implementing "++" operator, stepping into parse.y
  • Make Regexp#match much faster
  • Multiverse Ruby
  • おわりに

役に立ちましたか?

PDFとしてエクスポート
  1. イベント
  2. RubyKaigi

RubyKaigi 2023 に現地参加しました

前へRubyKaigi次へEMConf

最終更新 9 か月前

役に立ちましたか?

はじめに

5/11(木)~5/13(土)に、長野県松本市のまつもと市民芸術館にてが開催されました。

弊社からは4名のエンジニアが現地で参加しました。

この記事では、RubyKaigi 2023に参加したエンジニアの中で印象に残ったセッションをピックアップして紹介します。

印象に残ったセッション

The Resurrection of the Fast Parallel Test Runner

弊社ではRailsで作っているシステムはRSpecでテストコードを書いています。そのため、「ある箇所で破壊的な修正をしても、他のところでテストが落ちて気づいて救われる」と、テストコードの効果を実感しています。

テストコードのリファクタリングも随時行っているものの、基本的にはテストコードはプロダクトの成長とともに増え続けています。

その結果、最近、CIでのテスト実行時間が増えてきていることに対して課題感が出てきました。

  そんな中、このセッションの説明に

I will share some lesser-known parallel testing insights I've gained in reviving the test-queue. And explore possibilities of parallel programming in Ruby.

とあったため、並列テストに関して何か得られそうだと思い参加しました。

  セッションで印象に残ったのは、 parallel_tests と test-queue の仕組みの違いでした。

parallel_tests は事前にテストを分割してから各workerで並列実行するため、テスト全体のスループットは一番遅いworkerに引っ張られるとのことでした。

一方、 test-queue は空いているキューにテストを入れていくため、parallel_tests の問題点を解決しているとのことでした。

ただ、test-queue はテストフレームワーク特有の箇所があるため、もしRSpecが実装を変えたら動作しなくなるという説明もありました。

  他には、セッションの冒頭にて

  • 10分以内のビルドなど、テストの実行時間を短くするのは大切

  • RSpecで遅いテストを見つける方法

  • Database Cleanerのチューニング

についてもお話があり、このあたりの観点でもテストを見直していこうと感じました。

Revisiting TypeProf - IDE support as a primary feature

TypeProf の v2 を作っているというお話でした。

  • v1 はとにかく動作するものを実装する、速度は二の次という前提にしていた

  • 実際に使ってみると本当に欲しかったものは「Rubyの型よりもIDEサポート」ということに気づいた

  • IDEサポートを強化するには解析速度は重要な要素

  • 解析対象のコードは完全なコードではない(書きかけのコード)

  • v2 は解析結果を差分更新して速度を出している

対象としているエディタはVS Codeのようですが、Vimでも動きそうな情報を見かけたので試してみようと思います。

Implementing "++" operator, stepping into parse.y

個人的 one of the best talks on RubyKaigi 2023 です。

実際に"++"を実装する試みが小さなステップで非常にわかりやすく解説されていました。現状の parse.y が i++ というコードをどのように扱っているのかから始まり、具体的に試してみる→できた→まだ問題が…という流れが parse.y 初心者にとってとっつきやすく、自分も parse.y の中身を見てみたいという気持ちが出てきました。

最後の「"++"があるこの言語は Ruby じゃない Ruby++ だ!」というオチに至るまでのストーリーも面白かったです。

Make Regexp#match much faster

なぜ ReDoS が起きてしまうのか、Ruby の正規表現エンジンである Onigmo の特性や、バックトラックにより分岐が指数関数的に増えて行くことをわかりやすく解説していただき非常に勉強になりました。

また、高速化の手法としてメモ化を導入し計算量が線形時間になることや、 Regexp.linear_time? メソッドで正規表現が線形時間になることのチェックが可能であることも知ることができました。

今後の展望として Regexp.linear_time? が false となるような正規表現の場合に警告を出す RuboCop をスピーカー自身で開発するとのことで、弊社でもリリースされたらすぐに導入したいと考えています。

Multiverse Ruby

匿名モジュールを用いて名前空間の衝突を避けようという話でした。

匿名モジュールの名前空間の挙動はこのセッションを聞くまで知らなかったので興味深く聞くことができました。

また、オートロードを匿名の名前空間上で行うために Zeitwerk をフォークして Im という gem を作成した話もありました。リリースインフォに載らないような Ruby の改善をどのように用いて課題を解決したのか、という一連の流れが特に面白かったです。

Public な gem を開発することがなかなかないのでセッションの内容をすぐに活用することは難しいと思いますが、自分も細かいものも含めて Ruby の改善をキャッチアップしてみたいと思わせてくれるようなセッションでした。

おわりに

弊社のエンジニアたちは東北から関西まで様々な地域で暮らしているため、基本的にフルリモートで勤務しています。

日頃はSlackやGatherなどによるオンラインコミュニケーションを取っている一方、オフラインで直接会話する機会がなかなかありません。

そのため、今回のRubyKaigi 2023は、弊社のエンジニアたちが集まってランチを一緒に食べたり直接会話する良い機会となり、とても楽しく過ごせました。

  最後になりましたが、RubyKaigi 2023を運営してくださったみなさま、本当にありがとうございました。

これからは来年沖縄で開催される RubyKaigi 2024を楽しみにして過ごしていきます。

とはいえ、RSpec3のサポートに加え、以下のプルリクにある通りRSpec4.0(dev)もサポートしていることから、社内のコードを使って test-queue を試してみるのも良さそうと感じました。

本サイトの更新情報は、Twitterので発信しています。ご確認ください。

RubyKaigi 2023
https://rubykaigi.org/2023/presentations/koic.html#day2
https://github.com/tmm1/test-queue/pull/112
株式会社プレセナ・ストラテジック・パートナーズエンジニア公式