GitHub Actionsで"Files changed"のファイルを取得する

GitHub ActionsでPRの"Files changed"タブと同じファイルの内容を取得する方法*1

- uses: actions/checkout@v3
  with:
    # マージベースの探索でコミットをさかのぼるために全コミットを取得しておく
    fetch-depth: 0
- run: |
    # ... でPRのFiles changedと同じ差分
    git diff origin/main...HEAD

    # ファイル名のリストだけ
    git diff --name-only origin/main...HEAD

    # 必要に応じて追加、変更したファイルだけなど
    git diff --diff-filter=AM origin/main...HEAD

やっていることは次と同じ。

# fast-forwardでない可能性があるのでマージベースを見つけておく
merge_base_sha=$(git merge-base origin/main HEAD)

git diff $merge_base_sha HEAD

たぶん実用的にはchanged-filesアクションを使えばよいが、とりあえずインラインで書きたい、なんらかの理由で外部アクションに依存したくないという時用。

*1:2022-11-23に ... を使う方法を追記

できるだけコントローラではなくモデルで例外処理する

問題: コントローラで例外処理している

アプリケーションが扱うドメイン特有のエラーを例外として表現する場合に、その例外をコントローラで処理するコードを書くと、ほとんどの場合でコードが読みにくくなったり、コードを変更しづらくなったりする結果となる。そして、開発の効率が落ちたり不具合を作りやすくなったりする。

具体的な問題は次のとおり。

コントローラのアクションの凝集度が下がる

コントローラのアクションに、たとえば複数の決済方法のエラーのような微妙に異なる種類の例外に対する処理を書くと、コントローラが肥大化し、凝集度が下がる。結果として、エラーが関わる変更を入れるときに、本来ビジネスロジックだけの変更であっても、コントローラとモデルの両方を必ず変更しなければならなくなる。また、関係の薄いさまざまな例外が1箇所で処理されることになり、コードが読みにくくなる。

class ChargesController < ApplicationController
  def create
    # ...

  # いろいろな例外処理
  rescue FooPay::Error
    # ...

  rescue BarPay::Error
    # ...

  rescue BazPay::Error
    # ...

  # 以降同じような節が続く
  end
end

さらに、こういうコードは「ここで例外処理しているから今回のも追加しておくか」という心理を誘発しやすい(割れ窓)。持続的なWebアプリケーション開発は割れ窓との戦いである。

テストの負担が増える

コントローラ層を対象としてテストする場合、いちいち結合テスト(近年のRailsだとintegration testまたはrequest spec)を書く必要がある。プレーンなクラスやいわゆるモデルなどと比較するとテストの準備が大変になるし、テストの実行速度も落ちる。また、異常系はとくにだが、しばしばリクエストやコンテキストを含めた複雑な事前状態を作る必要があり、読みにくいテストになる。

テストがしづらいところにがんばってテストを書くことはできるが、それは問題解決になっていない。

原因

そもそもコントローラはHTTPのことをやるところだが、それ以上の責務を負わせているのが上述した問題の主な原因といえる。

コントローラは、外から来るリクエストを受け取って、レスポンスを作って返すというのが本来の責務。HTTPに基づいてパラメータやヘッダのパース、Cookieの管理、レスポンスの生成などを実行する。

つまり、コントローラはレイヤードアーキテクチャのUI層やプレゼンテーション層にあたる。これらの責務やレイヤーには、アプリケーションの中核となるビジネスロジック(アプリケーションが解決する問題領域に固有のロジック)は含まれない。

一方、ビジネスロジックはモデルで扱う。これはレイヤードアーキテクチャで言うとドメイン層やモデル層と呼ばれるところ。ビジネスロジックを実行中に処理を継続できなくなったら発生させたいエラーは本来ビジネスロジックとして処理するべきだが、このエラーがモデルを外から利用しているコントローラにまで侵食してくると、上述したような問題が発生する。

解決策

本当に例外を使うべきか考える

ビジネスロジックにおけるエラーは「例外」ではないはず、とまず考えたい。たとえば、ユーザーが変な値を送信してきたときにそれを不正としてエラーを返すのは、例外的ではなく想定内のはず。別の側面だと、例外は制御構造から大域脱出するので、多用するとコードを読むときの負荷を高めうる。

例外の定義の1つを引いてくると『オブジェクト指向入門 第2版 設計・コンセプト』の12章に「例外とはルーチンコールの失敗を引き起こす可能性のある実行時イベントである」とある。つまり、例外とは、ルーチン(メソッド)の実行時に最後まで期待どおり実行できない可能性がある事態の発生を表す*1

どのようなエラーを例外として表現すべきか。技術的な例外としては外部サービスとの通信の失敗や、NoMethodErrorなどの実行時エラーがある。また、ビジネスロジックの例外としては、データとビジネスルールのあいだの不整合などで一度開始したトランザクションを続けられない状態になったとき発生させる例外が考えられる。これらのケースを除くと、本当に例外が必要ではないケースもそれなりにある。

そこで、エラーをできるだけ例外ではない方法で表現できないかを考える。たとえば、ビジネスロジック実行前のデータの検証失敗時に例外を起こすのではなく、検証の実行結果を取得できるような設計にする。これは、RailsだとActiveModel::Validationをうまく使い、入力値に関するエラーは戻り値、またモデルやフォームオブジェクトの属性として取得する事になる。

モデル層で適切にビジネスロジックを書く

ビジネスロジックに関するエラーをコントローラで処理するようになることが問題の原因だと書いた。ビジネスロジックに関するエラー処理をモデル層でやるためには、RailsのActive Recordのモデル(つまり、アクティブレコードパターンに基づいたDBのテーブルに対応しているクラス)だけではなく、必要に応じてふつうのクラスを作るようにする。そして、そのなかでエラー処理をやる。Railsならプレーンなクラスでもいいし、コントローラやビューで使えるようにするならActive Model (ActiveModel::Model)を使ってもよい。

このようなクラスをうまく作るためには、リソースだけではなくアプリケーションにおけるイベントもモデルとして抽出したり、ユースケースを見出してクラスにする必要がある。この話題については、非常にわかりやすくまとまっている次の文献を参照されたい。

トランザクションを張る場合は、例外を発生させることでトランザクションをロールバックする形になる。このケースにも対応するための案としては、次のようにビジネスロジックの一部としてロールバックと例外処理を実行し、このモデルを使う側からは実行結果だけが取得できるよう方法がある。これができると、コントローラは薄くなり、scaffoldしたときの構造に近くなる。

class Foo < ApplicationRecord
  # ...

  def execute_some_business_logic
    transaction do
      foobar!
      save!
    end

    true

  rescue ActiveRecord::RecordInvalid
    false

  rescue Foo::SomeError
    # 特有のビジネス例外としてなにか処理する

    false
  end
end

class FoosController < ApplicationController
  def update
    @foo = Foo.find(params[:id])

    if @foo.execute_some_business_logic
      # ...
    else
      # ...
    end
  end
end

DBと通信できないなどの技術的な例外はそもそもプログラムの実行を続けられないはずなので、ここで処理せず呼び出し元まで例外を突き抜けさせるのがよい。

FAQ: 404、500などのエラーにしたいときはコントローラより上の層で例外処理する必要があるのでは?

利用しているフレームワークにもよるが、404や500などの一般的、技術的エラーはアプリケーション共通の処理を定義していることが多いので、そういうケースで例外を発生させるのは問題なさそうに思う。たとえば、PUT /foos/:foo_id/bars/:bar_idのようにパスパラメータとしてIDが入るリソース設計にすると、

  • foobarは最初にコントローラでDBから探す
  • それらのレコードが見つかったら、そこからビジネスロジックに処理を依頼する

という流れになる。このときは、foobarがなければ、コントローラで例外処理をすることになる。

class BarsController < ApplicationController
  rescue_from ActiveRecord::RecordNotFound do
    # ...
  end

  def update
    foo = Foo.find(params[:foo_id])
    @bar = foo.bars.find(params[:bar_id])

    if @bar.update(bar_params)
      # ...
    end
  end
end

*1:契約によるプログラミングの言葉を使うと、呼び出されたルーチンが事後条件を満足できないときに発生するといえる cf. https://www.slideshare.net/t_wada/exception-design-by-contract

Macのセットアップでやること2022

新しくMacBookをセットアップする機会があった。開発環境はdotfilesである程度作れるようにしているが、macOSについてはいつもの設定を覚えておくしかない状態だったのでメモを残しておく。書いているのはデフォルトから変更している箇所だけ。

後述するがOSの言語を英語に設定しているので設定名も英語で書く。

UI

  • Appearance
    • Auto
      • 時間帯に応じてライトモード・ダークモードを切り替える
  • Dock
    • 書くのが難しいのでスクショ
      • 自動で隠す
  • Night Shift
    • Sunset to Sunrise
      • 夜は画面の色温度を下げる
  • Preferred languages
    • English、日本語の順番。英語の練習

入力

Trackpad

  • Tracking speed
    • Fast
  • Click
    • Light
  • Swipe between pages
    • three fingers
  • Swipe between full-screen app
    • four fingers

Keyboard

  • Key repeat
    • Fast
  • Delay until repeat
    • Short
  • Modifier Keys
    • Caps LockとControlの入れ替え

IME

  • Candidate window
    • Font: Hiragino Sans W5(ヒラギノ角ゴW5)
    • Font Size: 16
  • "¥" key generates
    • \ (Backslash)
  • "Full-width numeral characters"を無効化
  • "Use the Caps Lock key to switch to and from ABC"を有効化
    • 日本語と英語の切り替えをCaps Lockに割り当てる
    • "Modifier Keys"でCaps LockとControlを入れ替えているので、Magic Keyboard上のControlキーで日本語と英語を切り替えることになる

ウインドウ管理

画面1枚で仕事するので、次の記事の手法を参考にしている。

macOSでディスプレイ1枚で作業する技術 - Qiita

  • KeyboardのShotcutsタブ
    • Mission Controlの"Switch to desktop 1/2/3"に^1^2^3を割り当て
    • Keyboardの"Move focus to next window"に⌥⇥(Option+タブ)を割り当て
      • 同じアプリの複数ウインドウを⌘⇥と似た操作感で切り替えられる
  • Mission Control
    • "automatically rearrange"を無効化

ウインドウの割り当てかたは次のとおり

  • ブラウザ、ターミナル、エディタをそれぞれdesktop 1、2、3に割り当て
  • Slack、Books.appなどは"All Desktops"に割り当て
    • どの画面に切り替えても出現する

認証

  • Touch ID
    • いまのところ右手人差し指だけ
    • 1PasswordでもTouch IDを使うように設定
  • ブラウザ組み込みのパスワード機能を無効化
    • 1Passwordに一本化

OSその他

  • Battery
    • Power Adapterで"prevent your Mac from sleeping while the display is off"を有効化
  • Date and time
    • "set time zone automatically"を有効化
  • Activity monitor
    • DockアイコンをCPU usageに変更

開発

dotfilesのセットアップスクリプト実行で自動化できていないものがある。

  • SSHの設定
  • GPGの設定
  • VS Codeのワークスペースの移行
  • シェルのヒストリーの移行
    • .local/share/fish/fish_historyにある
  • Terminal.appの設定
    • デフォルトシェルをfishに設定
  • フォントのインストール

所感

従来、入力ソースの切り替えのためだけにKarabiner Elementsを使っていた(左Commandキーで英語、右Commandキーで日本語に切り替え)。しかし、ここまで来たらKarabiner Elements依存をなくせるのではないかと思い、OSの機能だけを使ってControlキーで入力ソースをトグルする運用に切り替えてみた。

両方のCommandキーをそれぞれ英語と日本語に割り当てると、入力ソースの状態を意識する必要がなくなるという利点がある。一方でCommandキーはキーバインドで多用されるので、文字を入力しながら入力ソースを切り替えるつもりが、誤ってキーバインドを発動させてしまうという問題がよく起きていた。

まだControlキーの運用は全然しっくりきてないがしばらく使ってみる。

pt-online-schema-changeで外部キーを削除する

サービスを停止せずにデータベースリファクタリングする - Pepabo Tech Portal の作業をやっていたときに知ったことについて書いておく。

結論

pt-online-schema-change (pt-osc)で外部キーを削除するときは

  • そのキー名の先頭に_を付与して--alterに渡す
  • すでに_が2つ付与されていれば、そのキー名先頭の_を2つ削って--alterに渡す
# 外部キー名がfoos_ibfk_1のとき
$ pt-online-schema-change --alter "DROP FOREIGN KEY _foos_ibfk_1" ...

# 外部キー名が_foos_ibfk_1のとき
$ pt-online-schema-change --alter "DROP FOREIGN KEY __foos_ibfk_1" ...

# 外部キー名が__foos_ibfk_1のとき
$ pt-online-schema-change --alter "DROP FOREIGN KEY foos_ibfk_1" ...

なぜか

外部キーを持つテーブルのスキーマを変更するためにpt-oscを使うと、自動で外部キーの名前が変更されるから。

pt-oscはスキーマに変更を加えるテーブル(旧テーブルと呼ぶ)に対して、スキーマを変更済みの新テーブルを新しく作り、トリガーを使って旧テーブルから新テーブルへレコードをコピーする。旧テーブルが外部キーを持つなら、新テーブルも同じ外部キーを持つことになる。一方、MySQLでは、外部キーなどの制約の名前はデータベース内で一意でなければならない1。pt-oscで新テーブルを作るときにそのまま外部キーをコピーしてしまうと、この決まりを守れない。そこで、外部キーを持つテーブルのスキーマをpt-oscで変更しようとすると、外部キーの変更有無に関わらず、外部キー名を変更するようになっている。

pt-oscは外部キー名の先頭にアンダースコアを付与したものを新テーブルの外部キー名とする。この方式で外部キーを持つテーブルのスキーマを繰り返し変更するとアンダースコアが増えていってしまう2。そこで、アンダースコアは2個を上限として、さらにスキーマを変更するとアンダースコアなしに戻るようになっている3

よって、pt-oscで外部キーを削除するときは、新テーブルを作成したあと--alterに渡されたオプションをもとに外部キーをDROPするので、新テーブルでの外部キー名を指定する必要がある。

参考


  1. https://dev.mysql.com/doc/refman/5.6/ja/create-table-foreign-keys.html の「CONSTRAINT symbol 句が指定されている場合、symbol 値 (使用されている場合) はデータベース内で一意である必要があります」

  2. 過去はそのような実装だったようだ

  3. https://github.com/percona/percona-toolkit/blob/v3.3.1/bin/pt-online-schema-change#L10759-L10777

AOPに基づいてconcernモジュールを作る

発端: concernモジュールの命名をどうするか

ここではActiveSupport::Concernをextendしたモジュールのことをconcernモジュールやconcernと呼ぶ。

「Concernに何を実装すべきかは…非常に曖昧」1である。さらに、Railsアプリのメインであるルーティングからモデルまでは命名規約がかっちり決まっているが、concernに明示的な規約はない。concernも基本的にはRubyのモジュールなので、EnumerableComparableのような組み込みモジュールと似たような命名にするべきだろうか。実際、concernの名前に動詞+ableを使うのはよくやると思う。

Rubyのプレーンなモジュールとの違いとして、ActiveSupport::Concernにはincludedclass_methodsが存在する。これらの機能があることで、concernはコールバックの定義やクラスマクロの定義に使われるようなフォースが働いているように見える。そこで、そのような特徴を踏まえたうえでconcernならではの命名があるか考えてみる。

横断的関心事

concernとはいったいなんだったのかというのをふりかえってみると、アスペクト指向プログラミング(AOP)における横断的関心事(cross-cutting concern)が起源の1つといえそう2

AOPにおける横断的関心事についてはこちらが詳しい。

横断的関心事 - アスペクト指向なWiki

横断的関心事の分類の1つとして静的か動的かというものがある。静的な横断的関心事はインタータイプ宣言の機能を担う。AspectJなどではクラスに新たなメソッドやプロパティを追加する仕組みのことをインタータイプ宣言と呼んでいるようだ。一方、動的な横断的関心事はポイントカット+アドバイスの機能を担う。こちらは、コードを実行すると発生する特定のイベント(メソッド呼び出しなど)にあわせてアドバイスと呼ばれるコードを実行する。

それぞれ、concernだと次のようなものにあたるといえそう。

  • 静的な横断的関心事は、スコープやクラスマクロを追加するconcern
  • 動的な横断的関心事は、コールバックを追加するconcern

concernの事例

Basecampの事例

concernといえば、DHHがかつて示していたBasecampのコード例が有名。

これ自体の賛否は置いておくとして、includeしているモジュールがすべてcocnernモジュールだと仮定すると、その名前には次のようなバリエーションがある。

  • 名詞
    • 単数形、複数形
  • 動詞
    • 接尾辞がable
      • スコープやメソッドを追加するために使われているように見える
    • 現在形(原型と三単現両方ある?)
    • 過去分詞

想定しうるバリエーションがあらかた存在する状況で、これだけだと明確なルールが見出しにくい。

api.rubyonrails.orgの事例

ActiveSupport::ConcernFooモジュールのような単純な例だけだったので、concerningのほうを見ると、EventTrackingという名詞のconcernが紹介されている。このconcernはメソッドを追加しつつコールバックも定義している。

AOPの観点でconcernを作る

実事例を見つつ、さきほど書いたAOPの静的・動的横断的関心事によるconcernの分類に基づくと、ある程度納得感のある名前を持つconcernが作れそうに見える。

モジュールやクラスが静的な横断的関心事にあたるconcernをincludeすると、その時点でconcernが定義しているクラスマクロ、スコープ、またインスタンスメソッドが使えるようになる。つまり、それらを利用するか否かにかかわらず使えるようにはなる。とすると、Rubyのプレーンなモジュールと同じく動詞+ableにするのがよさそうに見える。

たとえば、パーフェクトRuby on Railsに載っているようなTaggableなら付与したタグのためにtagged_withスコープやtagsなどの関連が追加されるだろうし、UserSessionIssueableならログインセッションをセットアップするメソッドlogin_as_userが追加されるだろう。

module Taggable
  extend ActiveSupport::Concern

  included do
    has_many :tags #, ...
  end

  class_methods do
    def tagged_with
      # ...
    end
  end
end

module UserSessionIssueable
  extend ActiveSupport::Concern

  def login_as_user
    # ...
  end
end

一方、モジュールやクラスが動的な横断的関心事にあたるconcernをincludeすると、その時点でconcernが持つコールバックを必要に応じて自動で実行するようになる。「できるようになる」よりは「する」なので、concernのモジュール名は動詞の現在形にしておくのがよさそう。また、アトリビュートも追加されて、なんらかの状態を持たされるなら過去分詞にするといいかもしれない。

たとえば、NotifyImportantOperationなら重要な操作をどこかに自動で通知するコールバックを定義するだろうし、Obfuscatedなら特定のアトリビュートを自動で難読化したものを新たにアトリビュートとして持つようにできるだろう。

module NotifyImportantOperation
  extend ActiveSupport::Concern

  included do
    before_action :notify, only: [:create, :destroy]
  end

  def notify
    # ...
  end
end

module Obfuscated
  extend ActiveSupport::Concern

  included do
    attr_reader :obfuscated
    after_validation :set_obfuscated
  end

  def set_obfuscated
    # @obfuscated = ...
  end
end

うまく命名できるconcernになっているかどうか考えることは、大きすぎたりモジュールとしての意味のまとまりが希薄なconcernを作らないようにするのにも役立ちそうだ。

今回のAOPの考えかただと、concernに名詞で命名するとしっくりくる状況があまり思いつかなかった。一方で、EventTrackingの例のように関連とコールバック両方を定義するようなときは、利用可能なメソッドの定義と自動で実行されるコールバックの両方が手に入るので、上記の命名方法よりは適切に名詞で命名したほうがわかりやすいというのはあるかもしれない。


  1. 『パーフェクトRuby on Rails【増補改訂版】』13-1-3

  2. https://texta.pixta.jp/entry/2022/01/12/150000 など参照