Speakers
willnet
Railsの機能の一つに、Concernsと呼ばれるものがあります。 app/controllers/concernsやapp/models/concernsに関心事を切り出して配置するものです。 私はフリーランスや技術顧問として多くの会社のRailsプロジェクトに関わってきました。その中で、良かれと思ってConcernsを使ったものの、 そのことによりかえって可読性や保守性を下げてしまうケースをよく見かけています。 これは「Concernsをどのように使うのか」が曖昧な状態でなんとなく使っていることが原因ではないかと思います。 この発表では - Concernsとは何か - Concernsを構成するActiveSupport::Concernとは 何か - Concernsを使うべきでないケースと代替案 - Concernsを使うべきケースについて解説することで 「Concernsを完全に理解した」状態にすることを目的にしています。
KaoruHotate
Railsアプリを作っていて、 「Controllerの見通しをよくする」「Viewにロジックを書かない」といった言葉を聞いたことはないでしょうか。 Fat Controller / Fat Viewは、Modelに処理を移すという手法をとることが多いと思いますが、その結果、Fat Modelという負債を作ってしまいます。 1つのActiveRecordを継承したモデルオブジェクトに大量の便利メソッドと大量の分岐を作ったり、 中身を見ないと何をやっているかが分からないクラスを作ったり。。。 本セッションでは、Fat Modelをリファクタリングして見えてきた、6つのパターンを話します。各パターンのサンプルコードと、 解決できる内容・メリットを、他のプロジェクトにもいかせるように解説します。 サンプルコードは、過去に出会ってきたコードを題材にし、実体験に基づいた修正内容を紹介します。Fat Modelに悩む方の一助になれば幸いです。
Yusuke Endoh
Ruby 3の三大目標の1つである静的解析機能について、現在の計画と進捗を報告します。 Ruby 3では、複数のコンポーネントからなる静的解析ツールチェインが構想されています。 (1)標準的な型シグネチャフォーマット、 (2)アプリケーションコードの型シグネチャを要求せずに緩く検査し、型シグネチャを推定するlevel-1型検査、 (3)アプリケーションコードの型シグネチャを元に検査を行うlevel-2型検査、 により、Rubyの型検査に対するさまざまなレベルのニーズに応えることを企図しています。 この発表では特に、level-1型検査器として発表者が開発している『型プロファイラ』について詳しく説明します。 型プロファイラは、注釈のないRubyコードを対象とする軽量な静的解析ツールです。 静的解析によるプログラミング支援として型エラーの可能性を検出したり、 型注釈を必要とする別の検証ツールを使うために型注釈の推定を行ったりすることができます。 型プロファイラの基本的なアイデア、設計において気にしていること、現在の進捗などを説明する予定です。