RubyKaigi 2023 に登壇した

RubyKaigi 2023 に登壇しました。現地での登壇は3年ぶりです。

rubykaigi.org

当日の発表スライドは以下です。スライドのコード中に出てくる ennd なんかは typo ではなく、松田さんのスライドテクニックで、end がネストしている場合、ネスト分 ennnndとしてコードを圧縮しています。

また例年 yahonda さんに英文レビューをしてもらっていたところ、今回は勤務先の事業部でメンバー全員 ChatGPT Plus がサポートされている流れで、GPT 4 を使ったレビューをベースにしたあたり時代背景としてのひとつの変化かもしれません。

speakerdeck.com

スライド 100 枚を 30 分で話す競技にしてしまったのですが、いま流行りの『タイパ』は良かったかもしれません (通訳さんありがとうございました) 。

本編

すごくざっと話すと、「並列テストランナーとは何か?」から「並列テストランナーの種類」、「並列テストランナーの現在と今後」といった構成で作っています。

とりわけ「並列テストランナーの種類」について、現状で Ruby で実装されているメジャーどころの並列テストランナーのそれぞれの概略と、設計のポイントをまとめておきました。本編で話したのですが、並列テストランナーの機構自体を RSpec などのテスティングフレームワーク自体でサポートできると良いのではというひとつの考えが自分の中であり、そういったコントリビューションを各テスティングフレームワークにしていこうという人がいれば、そのヒントになると良いなあと思っています。

とっかかりとしては本編で話した Minitest と Rails 関係は何らかのヒントになるかもしれません。

そんな感じで、来年の RubyKaigi に登壇に向けてオープンなコードを書くことに目覚める人が増えるきっかけになるといいなあというのが、表紙のサブタイトル "The Force Awakens" に込めたもの。事前打ち合わせで通訳さんから聞かれたものですが、まあ、さすがに読み取れるものではないのでここでの補足としておきます。

プロダクトとしての test-queue

test-queue 自体が様々なテスティングフレームワークの各バージョンをサポートしているのですが、あまりに古い RSpec 2 と Minitest 4 はドロップしたいなあと思っていたところで、会場でアンケートを取ることにしていました。結果として会期中にリリースしたのが、The RubyKaigi 2023 Edition となる test-queue 0.9.0 です。

github.com

0.8.0 の機能はそのままで、新しい Ruby とその周辺環境で使う分には問題がないと思うので、ご活用ください。test-queue 自体は今回でひと区切りつけることができたと思うので、しばらく大きな非互換的な変化はないんじゃないかなと思います。

スローテストは設計改善へのヒント説

本編中で話した仮説です。テストスイートについて、ワーカーが処理する時間が短ければ短いだけ、ワーカーがロックする時間は短いです。つまりテストスイートが速く完了すればするだけ、ワーカー間全体としてスループットが上がるはず。モデル単位でいえばテストスイートとプロダクトコードは大体 1 対 1 の関係なので、スローテストのテストスイートはそもそも Fat モデルだったりするのではというのが起点。E2E テストも適切に分割されていると、理論的には全体のスループット向上に影響する気がします。このあたりのヒントは『プログラマーのための CPU 入門』に書かれているスーパースカラ、スーパーパイプラインからアイデアを触発されたものです。

本編で直接の言及をしていませんし、本発表とは直接的な繋がりはないものの、この書籍からはコンピュータの仕組みという観点からマルチコアを活かした並列での高速化へのヒントを得られるかもしれないので、こちらで言及をしておきます。

その後の会話やフィードバック

その後の会期中に自分の発表への会話で印象に残ったものです。

  • hirocaster さんからは、test-queue のワーカーを数百単位で稼働させて事例を聞けたのは面白かったです。ビルドの足回りだと AWS CodeBuild の 72 Cores がなかなかの量だと思っていたところ、自前で用意しての大型のビルド環境構築は印象的な事例でした。彼からも RSpec 2 はドロップして良さそうという声を聞けたのはちょっとした後押しでした。
  • moro さんは熟練の Rails エンジニア、かつ Cucumber の書籍も書いていたこともあり、test-queue の Cucumber が新しいバージョンで動かない点で困りそうなことはないか聞いてみたところ、いまは Cucumber は使っていないということで、そちらはまあ急がなくて良いかなというのが私個人のメンテナーとしての現状です。そんな感じで UA 起点での E2E テストでは RDBMS に限らず、chromedriver なども並列分起動してマシンリソース使いますね的な話をしていました。そして、E2E はスローテストになりがちなので、ゴールデンパスを中心とするような E2E と、細かな条件分岐とするユニットテスト、それぞれの領域でテストを使い分けるの大事だねみたいな話をしていました。
  • ledsun さんとは、各テスティングフレームワークに並列テストランナーを持つのであれば、それは独自インタフェースではなく、Web サーバー/フレームワークにおける Rack のような中間層のインタフェースを設けると良いのではという話をしました。いやあ、たしかにそれができると良さそう。一方で各テスティングフレームワークにその中間層を売り込みに行く作戦などは立てておけると良いかも?現状の Minitest / Rails あたりがヒントになるのかなあ。少なくとも RubyKaigi 2024 までの間に自分が手を出すことはない気がするので、興味のある人がいればアイデアとしてどうぞ!
  • m_seki さんからは、「そもそもそんなにテストするのが良くないんじゃない?」みたいな話があり、さすが本質を突いてもらいました。テスティングとチェッキングは違うよというものだと思うのですが、たしかに何年も失敗していないテストを毎回実行させる必要はないんですよねえ。このあたり onk なんかとも、毎回のビルドで実行するテストと、1日1回だけビルドするテストは分けて良いかもというような話をしました (つまり常のフルビルドではなくてよいのでは) 。それと何年も落ちていないテスト、もう落ちることないかもですが、ビジネスの先によってアプリケーションの変更がどうなるか予測不可能な部分もあって、 (ものにもよるものの) なかなか捨てるに踏み切れないんですよねえ。

発表後にこういったいろいろな会話をできるのは、オンラインの間はできなかったことで良かったです。特に会場のリアクションは現地で話す際の醍醐味だったので、test-queue 0.9.0 はそういった意味でも "The RubyKaigi 2023 Edition" としてメモリアルカットしています。

最後に、通訳さん、オンライン配信業者さん、そして 1,200 人もの国際大規模イベントを運営されたスタッフのみなさんありがとうございました!

RubyKaigi 2024 に向けてハックを続けましょう!

『研鑽Rubyプログラミング』をレビュアー献本いただいた

『研鑽Rubyプログラミング』をレビュアー献本いただきました。角谷さん、ラムダノートさん出版おめでとうございます & ご献本いただきありがとうございました。

記憶によると勤務先で出展していた『Kaigi on Rails 2021』のオンラインスポンサーブースで、角谷さんから「Jeremy Evans の『Polished Ruby Programming』を翻訳しているんだけど、レビュアーとして参加しない?」と声を掛けていただいたのが切っ掛けだったと思います。とりわけ「第6章 コードを読みやすくフォーマットする」で登場する RuboCop のパートの研鑽へのお手伝いが期待されていることかなと思いながら参加させてもらいました。

6章で個人的に気に入っているのが「詩人」と「哲人」のメタファー。RuboCop の使い方として Jeremy Evans としては DisabledByDefault: true から始めることをオススメ (いうなれば激推し) していて、Jeremy の書籍なのでそこは著者の意思としても、RuboCop コミッターの私としてはデフォルトが使いづらいという声は耳にしています (し個人としてもそれはそう思う) ので DisabledByDefault: true から始めてチームで引っ掛かった Cop を有効にする書籍に載っているアプローチはもちろん有効なひとつ。とはいえゼロベースで有効化してくのも手間という場合は rubocop-rails_config や Standard gem みたいなものに乗るのも選択肢です。この「好みの違いを受け入れる」 RuboCop の哲学については Ruby30 でも話しているのでご参考まで。

@yahonda さんの感想にある「議論を起こす価値のある本」になりえているパートのひとつかもしれません。

また、レビューの最中に RuboCop 本体に対して気づいたバグがあり、RuboCop に以下のパッチをあてたりしていました。

github.com

github.com

github.com

6 章に登場する RuboCop に関する訳注は、書籍レビューが元になったこのパッチの結果によるフィードバックがきっかけになっています。Ruby エコシステムを研鑽するきっかけにもなっててすごい。

そんなわけで Jeremy Evans という本物の超人が執筆した書籍というだけで価値ある書籍ですが、日本語版はプロの Ruby コミッターや現役で Active Record ならびに RDBMS に強い Rails コミッター、Ruby コミュニティで活躍している Rubyist のフィードバックも反映されており、原書にはない付加価値の付いた最高に研鑽された翻訳書です。

最後に TBA になると思いますが、角谷さんと RubyKaigi に向けた販促に関する話をしていて、著者の Jeremy Evans も来日登壇する RubyKaigi 2023 での賑わいのひとつになるかもしれません。とにかくおすすめ!

RubyKaigi 2023 に登壇します

RubyKaigi 2023 に『The Resurrection of 
the Fast Parallel Test Runner』というタイトルで登壇します。そして久しぶりの現地登壇です (3年以上ぶり?) 。

私の登壇は2日目である 2023年5月12日(金) の 13:30-14:00 の予定です。

rubykaigi.org

昨年コミット権を持った test-queue をベースにした、並列テスティングについての話です。ある意味で去年の『Make RuboCop super fast』に続く、リアルワールドプロジェクトでの開発ツールの速度改善に繋がる話です (つまりお役立ち) 。

github.com

並列テスティングへのなぜ何から始まり、並列テストを実現するテストランナーの設計や並列テストランナー界 (?) への今後の展望を主題に、利用者として知っておくと良さそうな話なんかも含めて話す予定です。あと Gem メンテナーを引き継いだ際に行うことやその気持ちなども交えるので、OSS 開発というものに興味のある人にも何かしら持ち帰れるような内容になると思います。

そんなわけで、実プロジェクトで役立つ知識だったり、そうでないマニアな知識を抽出したストーリーを鋭意作成中です。

また、今年の RubyKaigi には勤務先の永和システムマネジメントから同僚の @ima1zumi も登壇します。お楽しみに。

勤務先で『ソフトウェア職人気質』の書籍紹介をした

勤務先のおすすめ書籍の紹介イベントで、『ソフトウェア職人気質』を題材にした話をした。

当日のスライドは以下。

『ソフトウェア職人気質』は『エクストリームプログラミング』の第一版 (たぶん 2023 年現在の世間で広まっていない方) のような、ゼロ年代に台頭していた尖った書籍のうちの一冊。書籍そのものの内容というよりは、その内容と現実世界の仕事とのリンクについて取り上げなどしていた。 発表の話としては前半パートと後半パートで分かれていて、前半パートは自分の前の発表者だった @fkino と話していることが色々と被っていて、なんなら自分の 5 ページ目のスライドはだいたい同じデザイン構成で「示し合わせもなく、なんだこれ?w」展開で面白かった。

後半はいま話題の GPT に関連する話としていて、GPT との共生への展望みたいなことを書いているものの、本編では時間が足りず結構端折って話していた。

個人的には今後パラダイムシフトが起きるとしても、いまの仕事で行っている熟練度がゼロリセットされるものではないと見ているので『ソフトウェア職人』として研鑽していきましょうという感じで締めくくり。アジャイルマニフェストには署名がないものの、XP のシリーズ書籍の著者のひとりであるピート・マクブリーンさんのソフトウェア開発への考え方について、知られる機会になっているといいなあと思っている。

Bliki (ja) の翻訳チームに加わった

Martin Fowler's Bliki (ja) を管理しているリポジトリのコミット権を @kdmsnr さんからもらったことで、翻訳チームに加わった。

github.com

勤務先の永和システムマネジメントでは、『マーチン・ファウラーの会』という Bliki (ja) を読んでディスカッションする会があって、そこで気に掛かったものをプルリクエストにしていたところコミット権をもらった流れになる。Bliki (ja) はタイムレスな記事も多く、自分としてもゼロ年代に本当にたくさん読んで過ごしてきたもので、近代ソフトウェア開発に対する考え方の基礎の多くは eXtreme Programming とこの Bliki (ja) に影響されたものだと思っている。ぼちぼち見ていく気持ちです。

Ruby 30周年記念イベントにLT登壇した

プログラミング言語Ruby 30周年記念イベントに LT 登壇した。

30.ruby.or.jp

当日のスライドは以下。

RuboCop をメンテナンスしている日常の中からの話をピックアップしようと思っていたところ、RuboCop の哲学とかそのあたりを話の背景に入れたり、レビューに参加させてもらっている 角谷さん訳の研鑽 Ruby を元にした『哲人と詩人への自己分析』のスライドがローカルマシンから発掘されて入れてしまおうになったところ、まあ 5 分に収まりませんよね。

元々、銅鑼の音色に散ろうと思っていたので、全スライド到達を目指していはおらず『MatzCop』が最初に出たスライドで終わるといいなあと思っていたところ、王手も掛けることができなかったという。現地登壇だと、銅鑼と同時にスライドを目標ページまで数枚めくって終わるという裏技があるので、無意識にそれを狙っていたところオンラインだと難しいですね。みんな 5 分に収まっていてすごい。

イベントとしては、角谷さんオープニング〜高橋会長の Ruby 30 年の歴史から Matz のクロージングキーノート (プレゼン楽しそう!) まで終始楽しかったです。Ruby 30 周年おめでとうございます!

勤務先で『あなたの知らない超絶技巧プログラミングの世界』の書籍紹介をした

勤務先のおすすめ書籍の紹介イベントで、『あなたの知らない超絶技巧プログラミングの世界』を題材にした話をした。

当日のスライドは以下。

全体としては、鍋谷さんなどが行われている『どう書く』ならぬ、『どう読む』といった体裁での Quine の読み方例を話した。

スライドを作る過程で、ChatGPT に "Quine を Ruby でどう書く?" としたところ、禁じ手の puts File.read(__FILE__) 的なコードを提示したり、そもそも Quine になっていないコードを提示したりして面白かった。まったく別軸では、COBOL で書かれたものはあるだろうかと調べたら c2.com のページ がヒットしたりと、脇道に行ってもちょっとした発見があった。

今回の話は TRICK 2018 の動画 でも確認できる、以下の kinaba さんの言葉が素晴らしくて、それを社内にも伝達したいというのがモチベーションだった。

成熟した文化、例えば音楽でも楽譜を逆さにしても弾くことができる音楽とかそういうものがあって、 (中略) 成熟した文化にはこういったお遊びが発展していて、プログラミングという分野も
成熟した文化になっているといえる...んですかね

そんな超絶技巧プログラミングの世界はこんなイメージ。

ふだんのお仕事とは、ちょっと価値観の異なるプログラミングのおもしろさが広まるきっかけになると良いなと思う。