Ginza.rb 第86回

『Ginza.rb 第86回 - Rails 8.0について学ぶぞ』に参加した。会場はメドピアさん。今月もありがとうございます。

Ginza.rb 第86回 - Rails8.0について学ぶぞ - connpass

当日は y-yagi さんのファシリテーションによる Rails 8.0 でのアップデートが特集された。

https://y-yagi.github.io/presen_rails_8_0/1

Rails 8.0 は DHH の思想が色濃く出た The One Person Framework への仕上がりになっていて、Rails 6 からしばらくの Shopify や GitHub による複数データベースなんかのエンタープライズ指向ではない、原点回帰のカットになっているというのが全体的な感想。

いちばんホットだったのは、SQLite3 をプロダクションの永続ストレージに使うかどうかという点で、お仕事で関わるようなサービス向けには使わない。ただし、The One Person Framework のはじまりとしての初学者だったり、Once で立ち上げるようなサイズの社内システムだったりであれば、ひとつの選択肢になるかもねという温度感。y-yagi さんの「他の言語処理系でもサービスのバックエンドの RDBMS に SQLite3 を選ぶというのは聞かない」というのは、最も客観的な解釈になりそうと思った視点でした。

個人的には ActionController::Parameters#expect への置換を自動で行いたいという willnet さんの声は、RWC で igaiga さんからも尋ねられていたり、RuboCop Rails のイシューにもあるので改めてリアルワールドの要望として認識をしました。とはいえ、しっくりくるデザインと Cop 名が浮かんだら行おうかなという温度感ではありますが。

github.com

あとは 1 回だけ実行するスクリプト置き場の話で、Rails のディレクトリレイアウトの規約で場所を決めるのではなく、そもそも PR でレビューをしてもマージしない。つまりリポジトリを経由せずに実行できるエンジニアリングフローを作って実行すれば良いというのは「それだ！」と思う話で、特に興味深く聞けました。

次回の Ginza.rb は2025年1月24日(金) に Ruby 3.4 を取り上げるようです。

it ブロックパラメータ構文や Prism デフォルトパーサーまわりなんかの話があるのだろうかというのと、chilled string どうな (ってい) るんだろうあたり話に出てくるのかなと思っています。余談ですが、RuboCop の Ruby 3.4 構文対応について、ちょうどこの日に Parser gem のリードメンテナーがお気持ちなくなってきたことを大きく表明して、今後の進め方について改めて進めないとなあといったところ。it ブロックパラメータ構文くらいまでは Parser gem 自体に入れると良いと思っているけれど、Prism::Translation::Parser とあわせた全体性について冬休みの宿題のひとつかな。

github.com

RubyWorld Conference 2024 で登壇した

去年の RubyWorld Conference 2023 会期後の松江の飲み屋で、ko1 さんからプロポーザル提出のお声掛けを頂いたのが始まり。結果として採択して頂いた話が今回。プロポーザルがとおったあとに快諾頂いたフィヨルドさんにも改めて感謝します。

当日のスライドは以下。動画もどこかのタイミングで公式から配信されると思います。

発表について

日中の仕事からのカットということで、採用と育成をテーマにしてみました。フィヨルドブートキャンプさんというスクール視点のお話はパブリックスピーキングとしても聞いていたものの、受け入れる側の受け入れをテーマにした話というのは大きめのカンファレンスで耳にしてこなかったので、今回まとめてみた形です。

また本編でも取り上げたコミュニティのフラクタルさは、どこかの懇親会で町田さんたちと話した際に話したこと、「町田占い」はフィヨルド卒業生の同僚に聞いたことと、どこかで話そうと温めていたネタを使いました。

話全体を構成するにあたり 2005 年の勤務先での matz 招待イベントから現代までの知見を cherry-pick 編集しており、Ruby プログラミングスクールからの採用と育成というテーマとして、現在の自分が話せることは結構話せたのではと思っています。

なお、本編でも軽く触れましたが、今年のスクラムフェス金沢 2024で話した以下の話とセットで見ていただけると、組織の活性化として考えている全体性をより知っていただけるかもしれません。

www.youtube.com

プレゼンにフィンガープレゼンターを導入してみた

余談ながら、今回プレゼンにフィンガープレゼンターを導入してみました。

Kaigi on Rails 2025 で ydah さんが、フィンガープレゼンターを使っていて良さそうに見えたのがキッカケ。使ってみたのはコクヨの黒曜石というデバイス。最初は黒曜石という名前がカッコよいと思ったけれど、コクヨのダジャレ製品ですね。Amazon の商品見出しにはパワーポイントとありますが、Keynote や PDF ビューアでも使えました。

コクヨ パワポ操作用 フィンガープレゼンター 黒曜石 ELA-FP1

コクヨ パワポ操作用 フィンガープレゼンター 黒曜石 ELA-FP1

Amazon

ただし MacBook でこの黒曜石を使おうと思うと、USB からType-C が別途必要。たまたま以前、RubyKaigi あたりで Sider さんに頂いた変換アダプターがあったのでそれを使っていました。

今回 DHH のような極端な動きは付けられませんでしたが、PC を置いた場所に縛られずに話せるのはなかなか快適で、井上社長に撮ってもらった写真のポーズも今回使ったデバイス効果。

クロージングで井上社長が自分の登壇への言及に「というお話でしたよね？」とコールされたときに、その場にいたのにレスポンスできなかったのが心残り。かくたにさんを見習ってきちんとクロージング待機業の意識を高めたい所存。

ひとまず、現職20周年ツアー 2024 はこれがファイナルでこれにてフィニッシュ。また次回作でお会いしましょう。

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アプリ」

竜堂さんの発表は JRuby と Oracle ということもある以上に、事前にパッチを見ていたことも含めながら聞いていました。自分の場合はまだ 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 といった x が nil でないであろうことが自明なケースでも x&.foo && x&.bar と常に safe navigation を使うよう一貫させるのを強制するものでした。しかも Lint という部署で冗長な safe navigation を強制的に書かせられるのは厳しい。

今回のリリースで x&.foo && x&.bar のようなケースは、最初の条件の x が nil でない前提とできるなら、後ろの条件は 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 第84回 - 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 を取り上げるようです。 自分は予定が被っているため参加できず残念。また年末か年明けに。