koicの日記

RubyWorld Conference 2024 に登壇します

RubyWorld Conference 2024 に『Rubyプログラミングスクールからの採用と育成』というタイトルで登壇します。初日 12月5日 (木) の出番です。

2024.rubyworld-conf.org

以下に通過したプロポーザルの概要テキストをそのまま記載します。


即戦力のエンジニアの採用が容易ではない一方で、エンジニアへの業界転職という動きが見られて久しいです。

Rubyを採択している企業においてもエンジニアを育てていく流れとなっており、プログラミングスクールからの採用という形式は、業界として珍しいものではなくなっています。私の勤務先でも警察官、獣医、教師など多様な背景を持った受け入れをしてきています。 この登壇では、プログラミングスクールからの採用から育成への取り組みなどについて取りあげます。また、AI時代の採用への心構えの変化や、多様な背景に対してカバーする際のポイントについても近年のリモートワークを前提とした背景を含めてお伝えします。

新卒を数十人規模で採用して同期育成を進められる大企業ではない、老舗中小企業での運営事例として、比較的小さな運営母体を持つようなRuby企業様などへの参考として届けば幸いです。


登壇スライドはこのような内容に準拠した構成で提出済みで、スポンサートークとのダブルヘッダーの予定です。

来月松江でお会いしましょう。

Kaigi on Rails 2024に参加した

有明で開催された Kaigi on Rails 2024に参加した。

kaigionrails.org

ざっとになるものの感想です。2日分まとめてこちらに書きます。

1日目 (2024-10-25)

乗り換えでやや道を迷ったのもあり、ぷぽさんがいわれているとおり想像の3倍くらい遠い感じのところ、スポンサートーク2本目に入っているところで到着。

このエリアは、日本Rubyカンファレンス 2006 (RubyKaigi 2006) という、Ruby カンファレンスはじまりの地であると同時に、そこで DHH が「制約が自由をもたらす」キーノートをした地でもあった。また江渡さんが題材にされた「インターネット物理モデル」が今年でクローズされるうえ、さる筋の情報によるとその江渡さんは現在は DHH の故郷であるデンマークにいるかもしれないということで、時空を超えて Kaigi on Rails に集約されていく壮大な背景にイメージを膨らましつつ参加した。

オープニングキーノート

palkan のオープニングキーノートで出てきた「Think as a framework author, not a custom application developer」というフレーズは、今回 Kaigi on Rails 2024 で自分が過ごした全体をとおして一番響いたフレーズでした。

OSS をメンテナンスしていると、作者の気持ちを読む重要さや、作者のプロダクト方針を汲み取る力が求められるけれど、DHH とその背後にある Matz の圧倒的なデザイン力のうえに我々は乗っかっているんだなあというのを思い出されました。

個人的には、12月の RubyWorld Conference の登壇準備で、広い意味で「Rails とは何か?」というテーマで悩んでいたタイミングということもあって、行間から色々と創発を得たトークでした。

夜には palkan にも本人に直接伝えられる in-person しぐさができて良かったです (yahonda さんフォローありがとうございました) 。

RailsのPull requestsのレビューの時に私が考えていること」

yahonda さんの話は特に後半に出てきた、OSS メンテナーとしてのコントリビュータからの PR への対応といった関心事や優先付けといったものに共感を持ちつつも、yahonda さんのお気持ちが入っているあたりなんかは特に興味深く聞くことができました。

JRubyのパワーを解き放つ:パフォーマンスと多様性向上のためのRailsアプリ」

竜堂さんの発表は JRubyOracle ということもある以上に、事前にパッチを見ていたことも含めながら聞いていました。自分の場合はまだ Ruby (というか Rails) の市民権がビジネスで今ほど強くなった頃に、MRI をランタイムにインストールできないけれど、JVM で動くということで JRuby なら OK という案件に携わったこともあり、そのあたりの体験を踏まえて聞いていました。

たしかに JRuby は起動が遅いものの、いちど起動すれば (メモリ消費量はトレードオフに) 高速に動く環境を手に入れられるというポイントがあって、そのあたりの特色をうまくまとめられたお話でした。あと、発表の最後に JRuby 開発者の headius への支援というのを呼びかけていたあたり、竜堂さんの優しさと Rubyist の繋がりが出ていて良かったなあ。

夜には Oracle enhanced adapter のリードメンテナーの yahonda さんから竜堂さんに、Oracle enhanced adapter のリポジトリ状況を伝えてもらう機会を作れて良かったです。

そのほか

カフェスペースで ogijun のコーヒーを楽しみながら、yahonda さんや kamipo さんとパッチ会的な感じの話をしたり、近況やはじめましてをしたりして過ごしていました。ogijun のコーヒーでは多彩な味わいをいただいてごちそうさまでした。

あとはひたすらテックトークなどを肴にした夜でした。モリスさんが namespace の test-all をパスしたお祝いは、Ruby 4.0 にまたひとつ近づいたということで、キーマンを囲んだマイルストーン達成をお祝いできて良かったです。公式パーティーや2次会ではいろいろな人と話せた気がします。

ちなみにこれは2次会のワンシーンで、オープニングキーノートの palkan に声かけをしてくれたのは、ydah さん。彼はすっかり Ruby コミュニティになくてはならない存在ですね。

2日目 (2024-10-26)

このワトソンさんの「明日も対戦お願いします( ˘ω˘)」ツイートから一夜明け2日目。前日の飲み過ぎのダメージを引きずってスタート。ydah さんの発表に間に合うように頑張った。

「作って理解する RDBMSのしくみ」

ydah さんの発表は、予想と違ってコードが出てこずに、データベース実装のデザイン概略とアルゴリズムの性質とその歴史といった感じのお話でした。データベースの気持ちを知るにはデータベースを作るのが一番という意味では、ydah さんの話をきっかけに、そういった人が現れる足がかりになると面白そうですね。

お昼に a_matsuda さんと「そういえば分散ストレージの Fairy と Roma というのがかつて Ruby 製でありましたねえ」とインターネット老人会の方でも、往年の Ruby 製データベースを思い出すきっかけになるお話でした。

「Importmapを使ったJavaScriptの読み込みとブラウザアドオンの影響」

同僚の swamp09 のトーク。Kaigi on Rails という現場での地に足が着いた「面白いトーク」というプロポーザルという意味では、弊社でもっとも相性が良さそうな話と思いながら当日聞いていて、実に Kaigi on Rails っぽい話という趣で聞いていた。

本当はもっと Importmap まわりでの悩みを参加者と一緒に考えられる感じだと良さそうと事前に話していたけれど、そのあたりを公式懇親会で満足できたのかな?

「omakaseしないためのrubocop.yml のつくりかた」

エクスパさんの話は、タイトルから呼び出しされている感じだったので、きちんと最前列に着席して聞いていました。EM として RuboCop をプロジェクト (メンバー) に迎えるにあたるステップを丁寧に説明されていました。個人的にはタイムボックスとアカウンタビリティがしっかりしている話だなあと聞いていて、15分という枠の中でしか同期的に行わない。投票は非同期で行える Slack。アカウンタビリティが希薄になるリスクのある持ち回りではなく、自分が前に進める。というのがマネジメント感あるポイントで良かったです。話のくくり方としても「文化を omakase しない」というのは、良いフレーズだなあと思いました。

余談ですが、エクスパさんとは RubyKaigi 2024 で「終まで飲んで」いたひとりで、その際に EM としての話を聞いていたことから「エクスパさんの (考え方の) 話」としても関心を持って聞いていました (その際にもちろん ydah さんもしっかりといました) 。カンファレンスは繋がっていますね。

「Identifying User Identity」

そして去年の個人的ベストスピーカーの moro さんの話。今年もプロポーザルが採択されたというツイートの時点から楽しみにしていました。

User という曖昧な名前で終わらせないというユーザーストーリー的な話から始まり、User に相当させるテーブルには id しか持たせない (human_id と created_at くらいはあっても良い) というのは、個人的にそれを実践でやっているっぽいのがさすがなところでした。たとえば Devise なんかはビジネス情報と認証情報をごちゃまぜにする重厚なテーブル設計になる悲しみの代表例だと思っているけれど、そういったものではなく「正規化とは何か?」「情報の分類とは何か?」といったデータベース設計のあり方を問われているような話でとても良かったです。とりわけ一つのテーブルに「公開して良い情報」と「秘匿情報」が混ざっていると、そういった情報管理の部署から提出を求められた際の分別が面倒だったり、本番環境ベースのデータをステージング環境に、センシティブな秘匿情報をカスタマイズして投入などいった際の、人為的ミスへのリスクを減らす足場になりそうで良い話でした (これも「混ぜるな危険」パターンのひとつと言えそう) 。

また scope :withdrawn, -> { where.missing(:credential) } とか、意図を伝えるためのこれ以上削りようのないシンプルなコードで最高にクールな書き方 (で、それができるようになっていっているのが Rails の素晴らしさ) だと思っているのですが、そういった Ruby のキメ方を実現するためにもデータベース設計は大事というメッセージが伝わってきました。話を聞き終わったあとに yancya さんと「moro さん本人は言っていないのに、論理削除を避けようという話も背景に含まれていたね」という感じで、たくさんの行間を考えさせられるとても良いお話でした。来年の発表も楽しみにしています!

クロージングキーノート

最後のクロージングキーノートの島田さんのお話。良い Rails アプリケーションを書き続けられるようにするお手本は、Rails そのものを知るというのがオープニングキーノートの palkan のトークとも繋がっている感じがあって良かったです。Rails で仕事を始めた当時に角谷さんが「rails g scaffold で生成されたコードはこれ以上削りようのないシンプルなコードで、このコードを基準にシンプルさを維持するように頑張ろう。アプリケーションは放っておくと複雑性を増すので、気をつけよう。」といったことを話していたことを思い出したり、Rails 20 周年イヤーの Kaigi on Rails クロージングキーノートとしてとても良かったです。

Rails World 2024 での DHH も「私が心を込めて書いたコードだから良いコード」になっているといった感じの話をしていたようなので、コードアーティストでもある DHH のブレのなさが Rails 20 年の歴史に繋がっているんだろうなあと、今回のカンファレンス全体を通して感じたその締めくくりでした。

そのほか

Kaigi on Rails 2024 記念に RuboCop Rails 2.27 をリリースしておきました。内容的に 2.26.3 のどちらで出すか悩んでいたバージョニングでしたが、記念なのでマイナーバージョンを上げることにしました。

github.com

ジョーカーさん的にはこんな絵面だったようです。なるほど。

そんな感じで非常に楽しい時間を過ごすことができたカンファレンスでした。来年の会場は東京駅直結のようで、個人的には最高のロケーションでいまから楽しみです。

会期中に a_matsuda さんと「20年続く Web アプリケーションフレームワークは本当にすごい」と話していたのですが、カンファレンスとしても RubyKaigi 2006 から日本で続く多様な Ruby / Rails のカンファレンスのひとつのいまの「体験」と「共有」の場に参加できて幸せでした。

スタッフのみなさん、登壇者のみなさん、交流してくれたみなさん、そして今回も美味しい珈琲を提供し続けてくれた ogijun さん、どうもありがとうございました。

rubocop-rails-omakaseとは何か?

Rails 7.2 で rails new した際に搭載される rubocop-rails-omakase について、それがどのようなもので、どのように使うことを期待されているかを書き記しておきます。

github.com

rubocop-rails-omakase は DHH が著者となる Ruby コーディングスタイルルールです。

一次情報はあくまで作者である DHH 発信のものとしてもらいたいですが、私自身も rubocop-rails-omakase や Rails 7.2 の RuboCop 関連機能にコントリビューションしていることもあり、比較的オリジンに近いことを述べることができると思います。また RuboCop のコミッターをしているため、たぶん RuboCop の世界にちょっと詳しい方でしょう。

とはいえ、いろいろな考え方がある領域であることも承知しているため、ひとつの考え方としてご参考ください。

なぜこの記事を書くに至ったか

Rails 7.2 で rubocop-rails-omakase が標準搭載されたことに伴い、これまでプロジェクトで育てた .rubocop.yml を rubocop-rails-omakase に置き換えるというものをいくつか見てきています。妥当な理由もあれば、そうでない理由もあるため考え方を整理しておく意味で書くに思い至りました。

rubocop-rails-omakaseはgofmtのようなものではない

まず rubocop-rails-omakase の特徴は、軽量な Ruby コーディングルールになっています。RuboCop のデフォルトルールが重量級であることと対比的です。

RuboCop の構成にはコインの表と裏のような切り離せない原理があり、軽量ルールはうるさくない反面、検知してもらいたかった問題を発見したりオートコレクトできません。その反対も然りで、見つけたい問題以外の余計な提案までされうるのが RuboCop のデフォルトルールです。

つまり rubocop-rails-omakase は銀の弾丸というわけでも、万能というものでもありません。

rubocop-rails-omakaseはスタート地点

もしこれまで自前で自分たちにフィットする .rubocop.yml をメンテナンスしてきたプロジェクトであれば、基本的にはその .rubocop.yml をメンテナンスするのがおすすめです。

rubocop-rails-omakase は Rails が提供する Linter, Formatter のスタート地点の構成であり、すでにスタート地点の先に行っているルールを使っていれば、それを使い続ければ良いためです。

Rails 7.2 へのアップグレードによって、スタートからやり直しというのは理にかなったアプローチにはならないでしょう。

rubocop-rails-omakaseに置き換えできないの?

もし、これまで自分たちで育ててきた既存の .rubocop.yml よりも rubocop-rails-omakase の方がクールだぜ。という場合は置き換えるのはひとつのアプローチです。ちょっと悲しい気がしますが。

その場合は、もちろんこれまで検知できていたものやオートコレクトできるものは rubocop-rails-omakase ベースに強制され直されるのと、おそらく大量のスタイル変更 diff が入った Pull Request と向き合うことになります。そのため自分たちで既にルールを組み上げている場合は、個人的にはあまりお勧めしないコースです。

逆にこれから Linter, Formatter を導入しようという場合は、スタート地点のひとつになると思います (rubocop-rails-omakase で気に入らないルールはカスタマイズできます) 。

rails/railsリポジトリとの関係性

rubocop-rails-omakase は rails/rails リポジトリの .rubocop.yml と異なるコーディングルールです。Rails フレームワークRails アプリケーションが地繋がりという考えがあるとすると、コーディングスタイルのルールという側面でこれらは繋がっていません。

rubocop-rails-omkase のルールは固定されていますが、rails/rails の .rubocop.yml 設定は折に触れて更新されます。

フレームワークとアプリケーションでルールを揃えたい場合は、rails/rails リポジトリのルールをトレースしている rubocop-rails_config の利用などを検討してください。

github.com

また、このような理由から rubocop-rails-omakase は rubocop-rails_config (とそれを継承したスタイル) を置き換えるものでもありません。

結局rubocop-rails-omakaseとどう向き合えばいいの?

rails new の後の bin/rubocop の実行に対して、何らかの .rubocop.yml の設定が必要ですが、自分たちがルールを持っていない場合のスタートラインとして、軽量なルールセットとして使えます (さすがに RuboCop のデフォルトルールを Rails アプリケーションユーザー全体のデフォルト とするのは重量感あると思います) 。rubocop-rails-omakase のルールセットとして、気に入ればそのまま使い続けることもできますし、この設定を元に更新していくこともできます。このあたりの向き合い方については rubocop-rails-omakase の README に詳しいです。

またコーディングルールの更新はユーザーのプロジェクトサイドでのみ行われることが期待されています。rubocop-rails-omakase は現時点でルールが固定されており、ユーザーからのコーディングルールのフィードバックが期待されていません

例えば、配列リテラルについて [ foo, bar, baz ] といったブレースの内側にスペースを強要する設定で、私が見る限り Ruby では現状マイノリティのコーディングルールですが、これは意図的な設定です。気に入らなければユーザー側でルールを更新しましょう。

また既に自分たちのルールを組み上げていればそれを使い続ければ良く、スタート地点のrubocop-rails-omakseへの切り替えは基本的に考えなくて良いと思っています (お仕事では他に考えるべきことがいっぱいある) 。

rubocop-rails-omakaseとは何か?

端的にいうと、standard, rubocop-rails_config, rubocop-github, rubocop-airbnb など数あるカスタムルールセットのひとつです。Ruby のコーディングルールは gofmt のように大統一できるものではないという哲学が RuboCop にあるように、多様性のひとつとして捉えるのが良いと思います。

rubocop-rails-omakase は、軽量な開始地点をデフォルトとして提供されているというあたりが、とても DHH らしい感じです。また Ruby の Linter, Formatter として、どのようなルールセットとして育てていくかユーザーサイドに omakase されているあたりも The Rails Doctrine みあるなあと思っています。

このあたりの話は先日の Ruby セミナー 東京でも触れておりますので、よければあわせてご参照ください。

そんな感じで今日はここまで。ハックを続けましょう。

RuboCop 1.67.0 の目玉機能

RuboCop 1.67.0 がリリースされました。

github.com

多くはバグ修正などの改善となりますが、その中でも個人的に今回の目玉機能と思っているのは以下の3つです。

この記事では、それぞれについてざっくり記しておきます。

RBS::Inline 形式のコメントを許可するオプションを提供した

@tk0miya さんによる RBS::Inline 対応のパッチ三部作です。

github.com

github.com

github.com

RBS::Inline での attr_reader :name #: String といったコメント形式 #: を受け入れるオプションを提供しました。

先日の Rubyセミナー 東京で神速さんが「RBS::Inline 対応へのパッチが RuboCop に出ている」と話していたもののリリースという位置付けにもなります。

www.ruby.or.jp

これでコメント行の開始を表す # の後ろにスペースを強制するため #: を記述できないといった問題を解決できるようになったと思います。

サーバーモードで .rubocop.yml と .rubocop_todo.yml を変更検知するようにした

これまで rubocop --server といったサーバーモードが自動で再起動するように検知していたのは、RuboCop 自身のバージョン変更と Gemfile.lock の更新のみでしたが、いくらかの RuboCop の構成変更にも対応するよう .rubocop.yml と .rubocop_todo.yml の変更も検知できるようにしました。

これはいくつかの LSP クライアントは、.rubocop.yml と .rubocop_todo.yml の変更を検知してサーバー再起動をできるようにしているのと同様の機能提供となります。思っているよりもサーバーモードは使われていそうなのと、それによるキャッシュの弊害というのはありそうなので対応しておきました。

Lint/SafeNavigationConsistency cop を仕様変更した

いつか見直そうと思っていた Lint/SafeNavigationConsistency cop について仕様変更しました。実装も先月個人旅行で鹿児島に足を運んだ際の飛行機でスクラッチしました。

これまでは x&.foo && x.bar といった xnil でないであろうことが自明なケースでも x&.foo && x&.bar常に safe navigation を使うよう一貫させるのを強制するものでした。しかも Lint という部署で冗長な safe navigation を強制的に書かせられるのは厳しい。

今回のリリースで x&.foo && x&.bar のようなケースは、最初の条件の xnil でない前提とできるなら、後ろの条件は safe navigation をしない x&.foo && x.bar とする。一方で x&.foo || x.bar のような最初の条件が nil の可能性があるなら、後の条件にも safe navigation した x&.foo || x&.bar とする。つまり safe navigation の利用を過不足ないよう一貫させるという仕様にしました。Cop の名称変更や部署変更は breaking change なので容易にできず、一貫の意味を変えるという苦肉の策。

いずれにしても、これで不要な safe navigation を強制させてくることはなくなったと思います。

以上が 1.67.0 の主だった変更です。リリース後の状況としては、とりわけ Lint/SafeNavigationConsistency cop の仕様変更によって、他の Cop のバグが見つかってきている (おかしな仕様だったせいで、まわりも色々とおかしくしていたらしい) ようなので、次のリリースではそのあたりの修正が入っていく予定です。

そんな感じで今日はここまで。ハックを続けましょう。

Ginza.rb 第84回

『Ginza.rb 第83回 - Campfireのコードを眺めるぞ』に参加した。会場はメドピアさん。今月もありがとうございます。

Ginza.rb 第84回 - Campfireのコードを眺めるぞ - connpass

当日は willnet さんのファシリテーションによる Campfire の鑑賞会が行われた。

once.com

Campfire は 37signals による買い切りの Rails アプリケーション。今回は (ライセンス用途確認済みの下で) そのコードを読んだ流れになる。そういった理由から商品の性質上、突っ込んだ感想は書きづらいものの、書ける範囲での感想を書いておく。

まず、これは当たり前ながら 37signals がどのように Rails のコードを書いているかがわかる。いわゆるサンプルではない、Rails 本家の 37signals の生きたコードが読めるというのは価値だと思う。音楽性などでのツッコミどころがあるのは音楽性なので置いておいたとして、全体としてはもとつねさんの感想になる。

とりわけ個人的に面白いと思ったのは Rails.env の切り方と、アプリケーション起動の仕組み (データセットアップと絡めて面白いことをしていた) 。当日までのコードリーディングで、このあたりに着目していた willnet さんも流石だし、割り切りというか「これが Rails だよなあ」という設計がされているのは DHH 肝煎り企業のコード感があった。git ディレクトリは手に入らないようだったので、どのコードをいつ誰が書いたかまではわからないのはミーハー的には惜しい点。とはいえ、興味がある人は観賞用コードとして購入してみても良いのではという面白さがあった。

次回の Ginza.rb は11月15日(金) に Rails 8 の Solid Trifecta を取り上げるようです。 自分は予定が被っているため参加できず残念。また年末か年明けに。

XP祭り2024で『Tidy First?』のお話に参加した

XP祭り 2024で、かくたにさんが「Kent Beck の新刊『Tidy First?』についてお話しましょう」といわれていたセッションに参加した。

confengine.com

スライドはなく、かくたにさんの話に対して Discord でのチャット中心でワイワイしたり、質問を拾ってもらったりする面白い試みのスタイルだった。

本編で話されていたようにキーワードとしては Tidying, Kent Beck, XP の3つ。そのあたりを踏まえつつ、セッション内でよく参照されていた記事は以下。

beetroot.co

ここではソフトウェアを変更できる人を "changers" と呼び、要求を出して変更を待つ人を "waiters" と呼んでいるものの、かくたにさんはこのあたりの名称を使うことに配慮して言葉を選んでいる感じだった。おそらく XP の Whole Team に対して、分断を呼んでいるような構図だったのが引っ掛かっていたのかなと聞いていたけれど、時間も限られていたので質問はせずにいた。このあたりはまた別途話す機会があると嬉しい。

自分が拾ってもらった質問は以下の2つ。

Q1. Refactoring ではなく Tidying を前面にしている意図はあるでしょうか?

Refactoring は意味の希薄化が進んでいる部分のある用語であり、誤解がないよう Tidying という語彙が選ばれているという理解をしました。 (あっているのかな?)

bliki-ja.github.io

また Refactoring は Test-First Development や Test-Driven Development といったテスト文脈がついてくるが、そういったテストコードありきの話ではなく、もっとそんなに腰を据えずカジュアルにちゃちゃっとできるレベルのコードの「お片付け」を日常的に行えるものを Tidying と指しているようでした。ソフトウェアを通じた人間の繋がりを良くしていく、個人レベルからの始め方のひとつとして本書サブタイトルの「A Personal Exercise in Empirical Software Design」はなるほどと思いました。

Q2. タイトルが「Tidy First?」と疑問符で終わっているのはなぜでしょうか?

Kent Beck のキャラクターが現れているというのが面白い解釈として聞いていました。「まず片付けから始めるんだ」と決め打ちで押し出すのではなく、「まず片付けから始める?それとも?」みたいな疑問として投げかけるのが本タイトルへのあらわれ。実際のところソフトウェアの仕事は自問自答の繰り返しの中にあって、「片付けから始める」のは選択肢のひとつとして「?」をタイトルで表すのはセンスのあらわれとしてよく理解できました。また、ここでボブおじさんだったら、もっと語感が強い感じになっていたかもというのはさらに面白い解釈でした。執筆者重要。

hasumikin さんの言葉を借りれば「だらっといい話」を聞けた45分でした。楽しかったです。

そのあとはライトニングトークスに同僚の amapyon が出ていたので聞いていたのですが、amapyon の LT はテーマ一本の単語をきっちり肉付けしていくタイプで、今回も「勘違い」について非常に学びになるトークでした。

余談ですが私は『Tidy First?』の原書の紙版を Amazon で購入していたのですが、発送遅延の通知がちょくちょく来て、どうもベルギーからの発送で3週間くらい掛かっていたような (同僚の iepyon と同じくほとんど未読) 。手元に原書を持ってみようという人への参考までに。

スポットでの参加となりましたが、楽しい XP祭り2024 をありがとうございました。

Findy Engineer LabさんのOSS開発記事に寄稿した

「あなたのキャリアのなかで、特に印象に残るPull Requestは何ですか?」をテーマにしたFindy Engineer Labさんの記事に寄稿しました。

findy-code.io

他の執筆者がどなたか知らない中で執筆したのですが、蓋を開けてみたら錚々たる顔ぶれの中で恐縮の至りという気持ち。良い経験になりました。

今回のテーマにあるように、印象に残る Pull Request はいくつかあるものの、選定が難しいところでした。Pull Request 一発でのインパクト的には、RubyKaigi 2018 の LT で話したものも浮かびましたが、こちらは動画を見てもらえれば良いかなということで候補から外しました。そして蓋を開けてみたら笹田さんも執筆されていることを知り、なんというかオープンソースの世界な感じですね。

さておき、そんなこんなで今回の Pull Request を最終的に選んだ理由としては、そもそもの RuboCop への Pull Request を送るようになったきっかけや、ユーザー影響への大きさなどを加味したものにしました。

本文の長さもあり入れなかった裏話をひとつ。Pull Request を戦略的に送っていくというオープンソースしぐさは、kamipo さんから学んだことでした。特に (マージ権をまだ得ていない) コントリビュータ時代の kamipo さんからは、Active Record への Pull Request で絶対にコミッターにマージさせるぞという気概の強いものは、Pull Request を送る手順が重要ということをリアルタイムで見聞きしており、そこから学んだことの実践のひとつが今回の記事の背景にありました。

実際のところオープンソースは決して広いわけではない人間関係の中で行われているので、実際に OSS 開発者と会う機会に恵まれることもあれば、その中で学びにつながる話を得ることもあります。本編には書ききれなかったことですが、Pull Request の背後にある人間性というものを感じ取ってもらう機会になれば幸いです。

また今回の執筆について、中薗さんにはお声掛けから記事レビューまで、前回の Findy Engineer Labさんのインタビューに続きお世話になりました。ありがとうございます!

findy-code.io