Ginza.rb 第84回

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

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

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

once.com

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

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

綺麗なコードからしか得られない養分をいただきました…ありがとうございました… #ginzarb

— もとつねの日常 (@daily_mototsune) 2024年10月11日

とりわけ個人的に面白いと思ったのは 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 と同じくほとんど未読) 。手元に原書を持ってみようという人への参考までに。

Tidy First?: A Personal Exercise in Empirical Software Design (English Edition)

スポットでの参加となりましたが、楽しい 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

Rubyセミナー 東京に登壇した

Rubyセミナー 東京に『コミッター直伝 RuboCop実践ガイド』というタイトルで登壇しました。当日のスライドは以下です。

自分の登壇について

某月某日、世界の Shugo Maeda さんから Ruby セミナー登壇へのお誘いのメッセージをいただいて、登壇の運びになりました。その際に頂いたテーマは以下です。

どんな形だとテーマに添えられるかを考えた結果、コミッター視点に加えて、これまで仕事やコミュニティ、オンライン、in-person などで直接間接問わず見聞きしてきたフィードバックに加えて、自分なりの RuboCop への理解などを加えた、ユーザー向けの「考え方」をざっくりとまとめて話した形でまとめてみました。Shugo さんからのオファーに応えられる形になっていたら良いなあというところです。

加えて、何度か勤務先で行っている Rails/OSS パッチ会で、MatzCop の構想を松田さんらと話したことがあった話題について、今回まつもとさんの前で話したところ「膨大な Cop のルールを取捨選択してもらうのはさすがに自分のハートが持たない」のを実感できたし、では MatzCop が The Default としてどの程度で成立するかはわからない (実現しなければそれはそう) 。何年も前から考えたことはある KoicCop 的なものも単純に「自分の好みで作ると例えばシングルクォートがデフォルトだけど？」なので結局のところ、Ruby で gofmt のような The Default は難しいんじゃないかなあと再確認できる機会にもなりました。

あと旬かもしれないあたりでは、Rails 7.2 における RuboCop まわりの情報をざっくりまとめておいたつもりです。

セミナー全体

基調講演のまつもとさんのより良い Ruby にしていくという話の中では、特に Name Space が次の Ruby の目玉としてフォーカスされていたのが印象的なひとつでした。Name Spece の開発を進められているモリスさんに超期待している的なムードもあって、私も楽しみにしています。そのほか今話題のパーサー開発競争について質問したところ、現状だと Ruby のリリース時期までに Prism に致命的な問題がなければそのままデフォルトパーサーとなりそうとの感触。そのあたりの判断は Kevin Newton の方でされるのかな (?) な感じであるものの、実際のところそのあたりも今後どうなっていくのかなというところ。そのあたりも含めて、Ruby ユーザーとしては開発版の Ruby 3.4 をリアルワールドアプリケーションなどに適用して問題がないか見てみて、問題があれば bugs.ruby-lang.org にフィードバックするといったあたりが各人で進められてくと良さそう。今回も受けた「OSS はどう始めたら良いか？」という質問について、個人的なおすすめは最新の開発版の Ruby やライブラリをお仕事のアプリケーションで動かしてみて、問題があればフィードバックするというコースなので、そういった形でも開発版が (Shopify や GitHub 社以外でも) いろいろなアプリケーションで試されていくと良いなあと思っています。

パーサーの話に戻って (?) 、Ruby 3.4 以降で今回のまつもとさんの構想話にあったアノテーションや、かつて一瞬 Ruby の開発版に入った obj.:method_name 構文の改訂版などが新規構文として追加される際、既存構文とコンフリクトがないかのリスクへの回答としては「parse.y で1回試す」というのあたり「あれ？」となりつつ、12月の松江でパーサーモンスターの kaneko さんとまつもとさんと話す機会があるのかなと、今後の動向も気になる感じです (リリース手前!?) 。

Matz「(Prism で新規文法の追加どうするの、という質問に対して) parse.y で動くかどうか1回試してからじゃないと怖くてできないよね」そりゃそうよね…… #ratokyo2024

— D-Swordman (@junk0612) 2024年9月20日

正徳さんこと神速さんはユーザー視点での型の話をされました。その中で特に良いなあと思ったのは、Ruby での型との現状でのリアルワールドアプリケーションでの付き合い方としては、型チェッカーとして使うのがヘヴィであるならば、メソッド補完やコードジャンプに割り切って使うというのが、実践的な話だなあと思いました (とはいえ個人的には、特にアプリケーションレイヤーで Ruby での型は書きたくない) 。このあたり RuboCop も型チェッカー (本編では Steep がベース) のいずれも、導入時のルールや型違反の検知数が導入への障壁なのは共通点としてありそう。

神速さんからはそのあたりを解決すべく、RBS::Inline の型を埋め込んでいく RBS::Trace という自作 Gem の紹介もされていましたが、その実装が TracePoint で取れない情報を、Prism で解析して判断するというあたり、ジョーカーさんやモリスさんみたいな発想っぽくてほっこりしました。

github.com

約5年ぶりの東京での登壇の機会にもなり、フィードバックをもらえたりと楽しい時間を過ごすことができました。スタッフのみなさん、関係者、参加者のみなさん、ありがとうございました！

ちなみに自分の講演タイトルはギター教則DVDなんかにある「〇〇直伝 様式美ハードロックギターの掟」みたいな感じを意識したものでした。Rock Will Never Die.

Rubyセミナー 東京に登壇します

2024年9月20日(金) に品川で開催される Rubyセミナー 東京に登壇します。何気に東京でのオフライン登壇は、平成Ruby会議01でのキーノート以来4年10ヶ月ぶりのようです。

www.ruby.or.jp

日中の業務で使っている RuboCop についての視点を増やすための、業務としても参加しやすい感じの平日の午後開催です。対バンはまつもとゆきひろさんと神速さんで、私は RuboCop の話というオファーから『コミッター直伝 RuboCop実践ガイド』というタイトルで登壇します。

今回は RubyKaigi などで話す RuboCop 内部まで踏み込んだテックトークではなく、これから導入を考えている方や、導入したけれどデフォルトでは使いづらいといった方に、RuboCop との実践での向き合い方を題材にした「考え方」を中心とするソフトトーク寄りの内容になる予定です。先日リリースされた Rails 7.2 で導入された RuboCop の位置付けについても取り上げる予定です。

導入に近い方もターゲットに入っているとはいえ、RuboCop とは何かといった話や rubocop コマンド自体そのものといった README に書いている話は (お互いに面白くないため) 割愛すると思いますので、そもそも RuboCopとは？という方はプロダクトの README やインターネット文献を予めご参照ください。まだ使ったことがないという方は、いちど rubocop コマンドや rubocop -a あたり手を動かしておくと、話の解像度が上がると思います。

github.com

申し込みは Doorkeeper から可能です。懇親会参加の締め切りは9月12日(木)のようです。

rubyassociation.doorkeeper.jp

当日は懇親会まで参加する予定です。品川でお会いしましょう。

Ginza.rb 第83回

『Ginza.rb 第83回 - Rails7.2のマイナーフィーチャーを学ぶぞ』に参加した。会場はメドピアさん。いつもありがとうございます。

ginzarb.connpass.com

当日は willnet さんのまとめ資料を元に進行した。

Rails7.2のマイナーフィーチャーで気になったところ · GitHub

当日の雰囲気は kozy さんがまとめられているのでそちらで。

kozy4324.hatenablog.jp

ここでは、y-yagi さんの OSS 方面からの興味深い情報を2つ書き残しておきます。

1 つ目は、parallel gem の方で使われている concurrent-ruby の Concurrent.available_processor_count 周辺の挙動を直したというもの。この辺りからの一連をリンクを見ると良さそう。

github.com

2 つ目は、Active Record で ActiveRecord::Base.connection が長期的には非推奨になって、今後は ActiveRecord::Base.lease_connection を使うことになりそうという話。現状の ActiveRecord::Base.connection は soft-deprecated という状態だけれど、影響の大きな話なので (それはそう) RuboCop Rails としては、もう少し明確に非推奨になってから対応が良いかな？というところ。情報のはじまりはこのあたりかな。

github.com

次回は9月スキップで、10月開催予定となりました。

Minify Rubyをリリースした

大阪Ruby会議04向けにリリースした Minify Ruby についてとりあげます。

ざっくりいうと JavaScript の UgilifyJS や Terser のような位置付けで、Ruby のソースコードを Minify する Gem です。

github.com

使い方

使い方は README.md に記しているとおりですが、コマンドラインからであれば、minifyrb コマンドを叩くのがシンプルです。

$ gem i minifyrb
$ minifyrb path/to/file.rb

これで minify されたコードが標準出力に出力されます。echo 'puts :hello' | minifyrb といったパイプでの標準入力からの使い方や、-o オプションを使ったファイル出力が可能です。

もう少し実用的 (とは?) な使い方としては、まず Gemfile に minifyrb を追加します。

# Gemfile
gem 'minifyrb'

続いていつもの流れで bundle install を実行。

$ bundle install

次に Rakefile へのタスク追加をします。

# Rakefile
require 'minifyrb/rake_task'

Minifyrb::RakeTask.new

これによって bundle exec rake minifyrb で実行できるようになります。この bundle exec rake minifyrb はディレクトリ配下の *.rb ファイルに対して直接 minify をしますので、git リポジトリで管理されていることを推奨します。

$ bundle exec rake minifyrb

少し大きなもので使いたい場合はこれがおすすめです。余談ですが、私が大阪Ruby会議04の発表デモで使っていたコマンドはこちらになります。

対象の処理系

現状では Ruby 3.3 以上のパースを行う Prism を構文解析のエンジンにしている関係で、Ruby 3.3 以上が minifyrb の処理対象です。もし古い Ruby で使いたいようなユースケースがあれば、ユースケース次第でサポートを考えてみますのでお声掛けください (もちろん必ずしもお応えできるかはわかりません) 。

既知の課題

まだバグがあります。

簡単なプログラムであれば minify によって壊れることはあまりないかもしれませんが、弱点のひとつにヒアドキュメントがあります (そうヒアドキュメントです) 。 また、登壇後にぺんさんに教えてもらったp +a; p (1;2) が p+a;p(1;2) のシンタックスエラーになる問題は 0.1.0 時点で未解決です (それはそう) 。

マジックコメントについても minifyrb によって削除しますが、frozen string literal マジコメは frozen を解くだけなので大きな問題はなさそうですが、String#frozen? のようなメソッドを使った処理分岐があると問題が出ます。またエンコーディングに対するマジックコメントが UTF-8 以外の場合は、スクリプトエンコーディングの関係で問題が出る可能性があります。このあたりはマジックコメントを消すか残すかする互換オプションを設けるか、それともどちらかに割り切るかはまだ決めていない段階です。

開発者ノート

2019年の平成Ruby会議01向けに実装した RuboCop Faker 以来、4年半ぶりくらいの新作 Gem です。その RuboCop Faker はいまはまさかの 10,000,000 ダウンロード超えしていて、マジかという気持ち。

rubygems.org

RuboCop Faker は現世の益を目的に明確な課題を解くために実装したものでしたが、今回の Minify Ruby は現世の益を目的にしていないもので、RuboCop オートコレクトのマッチポンプ以外で、どんな現実世界の問題を解くユースケースが誕生するか楽しみです。

誕生した背景や設計的な部分は以下のスライドをご参照ください。

また関連する記事として、大阪Ruby会議04での話は以下をご参照ください。

koic.hatenablog.com