
すべての説明はイチRubyユーザーの個人的で期間も限定的な観測範囲に基づきます。

# 「Rubyには型がない」

ある日、同僚とプログラミング言語に関する雑談をしていたときに言われた一言です。

私はその日までRubyの型機能は使っていませんでした。忙しい毎日を送り、キャッチアップを疎かにしていたのです。後日このことは猛烈に反省することになります。

**「Rubyには……型があるッ……！」**

火がついた私はパターンマッチの時と同様にRubyの型についてキャッチアップすることにしました。そして最高の体験が待っていました。

# 導入した後の世界

ぶっちゃけRubyの型を導入するとどうなるのでしょうか？

メチャクチャ簡単に説明すると、エディタでバグがひと目で分かるようになります。

![post.rb](/10-ruby-type/post.png)

vscodeでの画面です。なにやら赤線がついています。

### === bar ===

`bar`の部分にカーソルを合わせてみましょう。

![bar](/10-ruby-type/bar.png)

「Postクラスにはbarという名前のmethodはないよ」というメッセージが表示されています。
この表示は特にtypoチェックに役立ちます。

### === blog.user.stats ===

今度は`blog.user.stats`の赤線部分に合わせてみましょう

![blog.user.stats](/10-ruby-type/stats.png)

「Userクラスにはstatsという名前のmethodはないよ」というメッセージが表示されています。
`blog`や`user`は何のオブジェクトを返すのか解釈した上で、`stats`というmethodがないことも見つけることができています。
これもtypoチェックに役立ちそうです。

### === point * 100 ===

今度は`point * 100`の部分です。一見`point`は`1`か`2`が入っていて大丈夫そうに見えます。
何がいけなかったのでしょうか？

![point * 100](/10-ruby-type/point.png)

「Integerもしくはnilなので`*`は呼べないよ」と出ています。
そう、`case`文はどこにも条件が引っかからなかった場合`nil`を返します。
その可能性まで考慮しているのです。
これにより、`nil`の考慮漏れをふせぐことができます。

しかし、さらにその下の`point * 100`の部分は赤線がありません。これは

```rb
return unless point
```

というコードによって、`point`が`nil`である可能性が排除されるので、問題なく`*`が呼べているのです。

ここで紹介したものはごく一部でしかありません。

## 他にも

- methodの返り値を決め、実装がその通りになっているかチェック
- `has_one`関連など`nil`が返る可能性があるmethodがひと目で分かる
- methodのキーワード引数のオートコンプリート

等々、さまざまな機能を享受することができます。

これはもはや**Ruby界の革命**です。

導入しない手はないでしょう。

# 導入方法

## Rubyのversion

「型はRuby3の機能でしょ」と思われがちですが、
2.6以上であれば導入可能です。

## [Steep](https://github.com/soutaro/steep)導入

### dockerの場合

dockerプロジェクトの場合はlocalに入れたほうが楽です。

1. Steepをインストール

通常の場合

```shell
gem install steep
```

最新版を使いたい場合

```shell
$ gem specific_install -l https://github.com/soutaro/steep.git
```

2. `bin/steep`を作る

```rb
#!/usr/bin/env ruby
load Gem.bin_path('steep', 'steep')
```

```shell
$ chmod +x bin/steep
```

### dockerじゃない場合

```rb
gem 'steep', require: false
```

これでsteepコマンドの準備ができました。

## [vscode-steep](https://marketplace.visualstudio.com/items?itemName=soutaro.steep-vscode)の導入

vscodeの拡張で`steep`と検索すれば見つけることができます。
これをinstallしましょう。

## [gem_rbs_collection](https://github.com/ruby/gem_rbs_collection)の設置

READMEに従って、submoduleとしてリポジトリに追加します。
この辺は将来的に別の方法でも実現できるようになっているかも。
現状はsubmoduleが取り回しやすいです。

```
git submodule add https://github.com/ruby/gem_rbs_collection.git vendor/rbs/gem_rbs_collection
```

## Steepfileの設置

リポジトリのトップに以下の内容で`Steepfile`として保存します。

steepはこのファイルを読み込んで型チェックの対象範囲と型定義範囲を決めます。

型定義には別の型定義への依存関係があるものもあります。

ここにある`library`の記述は、全てRailsのための依存ライブラリです。

将来的に短くなるかもしれませんが、現状型定義に依存する型定義を全て記述しなければならないようです。

```rb
target :app do
  check "app/models"
  signature "sig"
  repo_path "vendor/rbs/gem_rbs_collection/gems"

  library 'pathname'
  library 'logger'
  library 'mutex_m'
  library 'date'
  library 'monitor'
  library 'singleton'
  library 'tsort'
  library 'securerandom'
  library 'base64'
  library 'forwardable'
  library 'time'
  library 'json'

  library 'rack'

  library 'activesupport'
  library 'actionpack'
  library 'activejob'
  library 'activemodel'
  library 'actionview'
  library 'activerecord'
  library 'railties'
end
```

`app/models`ディレクトリをチェック対象として、`sig`ディレクトリに型定義を保存する設定になっています。

これでsteepは最低限動かせますが、動かしてもエディタは真っ赤になっているでしょう。
Railsは動的にメソッドを追加する事が多いので、activerecord等のライブラリ型定義だけでは足りません。この動的定義を補完するにはrbs_railsを使います。

## [rbs_rails](https://github.com/pocke/rbs_rails)の導入

READMEに従い、`Gemfile`に以下を追加。

```rb
gem 'rbs_rails', require: false
```

`lib/tasks/rbs.rake`ファイルを以下の内容で作ります。

```rb
require 'rbs_rails/rake_task'
RbsRails::RakeTask.new
```

次に`$ bin/rake rbs_rails:all`を実行します。

これにより、アプリケーションのモデルファイルを読み取って、型定義(rbsファイル)が生成されます。

Railsは様々なmethodを自動生成します。

ここで生成された型定義はこの自動生成されるmethodを補完するものです。

ここで生成されたファイルは基本的に編集しません。編集しても`$ bin/rake rbs_rails:all`を再実行すると上書きされてしまいます。

ここまで実行できれば、だいぶエラーが減るでしょう。

## sig/app/models/*を補完

rbs_railsはあくまでRailsが自動生成するmethodを補完するものであるため、アプリケーションコードのmodelに定義されたconstやmethodの定義は生成されません。

これらはrbs_railsでは関与せず、アプリケーションで管理する前提なのかなと予想されます。
イチからrbsファイルを作ってもいいのですが、面倒なので、以下のスクリプトでざっくりプロトタイプを作っておいて、あとで編集すると便利です。

```bash
for file in app/models/**/*.rb
do
  mkdir -p sig/$(dirname $file)
  rbs prototype rb $file > sig/${file}s
done
```

このスクリプトで`sig/app/models`以下にmodel毎にファイル分けされたプロトタイプが生成されます。

ちなみにrbsファイルは分けても分けなくてもどちらでもよく、全部読み込んでから全部判定という手順をとっているようです。

`rbs prototype rb`ではファイルの内容を静的に見ているだけなので、引数や返り値はほとんど`untyped`でしょう。

このファイル達はアプリケーションで管理する型定義です。ガンガン編集していきましょう。

お疲れさまでした。あなたのRailsプロジェクトに型が導入されました。

## 動作確認

ここまできたらエディタで`app/models`のコードを見てみましょう。

**あなたは新しい世界に飛び込むことでしょう。**

「あーここはDBのカラムがnullを許可しているのにコードでは考慮できてなかったなー。」

「`has_one`だから関連レコードがない場合は`nil`になっちゃうのか。この場合の考慮が漏れてた。」

「変数名typoしてた。」

のような気付きが、**ひと目で**分かるようになるでしょう。

まだいくつかエラーが出ているかもしれません。
その原因は様々です。ライブラリーの問題かもしれません。まだプロトタイプの型定義の問題かもしれません。アプリケーションの問題かもしれません。

全部治す必要はないですが、「これは無視できる」「これは無視できない」を見分ける必要があります。

もしライブラリーの問題ならissueで報告するかPRを作ると良いと思います。
あなたの行った問題解決が、全世界に還元されます。

もしアプリケーションの型定義の問題なら、型定義を修正しましょう。コツは「こうあるべき」を書くことです。

もしアプリケーションの問題なら……。おめでとうございます。あなたは静的型検査によってアプリケーションのバグを発見することができしました。

# 導入してみた感想

## バグの発見

私はRubyの型検査でアプリケーション内でのバグをいくつか発見することができました。
単純な変数名のtypo、未定義のmethodの発見、オブジェクトがnilになる可能性など。

確かに自動テストを書いていればこれらの問題を発見できていたかもしれません。
しかしながら、「テストを書かなくても、コードを実行しなくても問題を発見できる」というのは利点になると思います。

例えば分岐パターンが多すぎてテストケースを全パターン用意するのが困難なケースでも、実行自体が難しいAPI連携や重い処理でも、
最低限の静的チェックを行うことができます。

まだ導入から日が浅く、その効果を実感できていませんが、リファクタリングのしやすさや、コード理解にも役立つことが見込めます。

## 型定義の方針

ライブラリーで自動生成されるメソッドはできるだけ型定義を自動生成し、アプリケーション固有の定義はアプリケーションで型定義を手書きしていくのが良いと思われます。

ライブラリーの定義がまるごとない場合は、アプリケーション内で試しに以下のコードでライブラリーの型定義のプロトタイプを作ってみて、gem_rbs_collectionなどにPRを送るのが良いのではないでしょうか。

```shell
rbs prototype rb lib/**/*.rb > lib.rbs
```

## 型ファースト

例えば、あなたはモデルに1つmethodを追加したくなりました。
大体の仕様は頭にあるはずです。

あなたは最初に何を書きますか？

実装？

テスト？

私は、もしかしたら型定義を最初に書く手法が今後使われるような気がしました。

型駆動開発**≪TDD(Type Driven Development)≫**の誕生です。

## 埋めきれないエラー

いくつかは既存の型定義や自動生成などによって保管されましたが、
いまだ多くのライブラリーで型定義が足りていない状況かと思われます。

実用的なアプリケーションで、エラーが一つもない状況を保つのはしばらく困難でしょう。
地道にライブラリーの型定義を増やしていく活動が必要かと思われます。

やっていきましょう。

# ツールの説明

以下はオマケとして、私の現時点での各ツールの私の理解です。

型(rbs)を「使う人」と「書く人」によって使うツールが異なることを考慮すると、理解しやすいかもしれません。

## [rbs](https://github.com/ruby/rbs)

型定義専用の言語です。Rubyとは構文が似ているようで異なります。
また、cliツール名でもあります。
「使う人」と「書く人」両方にとって重要なので、構文は覚えたほうがいいでしょう。
`$ rbs prototype rb`コマンドも便利なのでよく使います。

## [steep](https://github.com/soutaro/steep)

rbsに基づいて、実際のRuby構文に対して型チェックをかけるツールです。
rbsは元々steep用の構文だったとか。[出典](https://techlife.cookpad.com/entry/2020/12/09/120454)

「使う人」と「書く人」両方にとって重要なツールですが、直接cliから使うことは少ないかもしれません。ほとんどはエディタを介して使うことになるからです。

## [steep-vscode](https://github.com/soutaro/steep-vscode)

地味に重要なツールです。
Steepはlanguage server protocol(LSP)を扱う事ができます。
steep-vscodeは、vscodeとsteepをLSPを通じて連携させるvscode extensionです。

「使う人」が最も多用するのは、エディタで個々のファイルを閲覧・編集しながら型のサポートを受ける使い方でしょう。
この機能を使って、今エディタで見ているファイルに対して高速な型検査を実現しています。

vscode-steepは`bin/steep`があればこっちを優先して、なければ`bundle exec steep`を実行するようです。
この仕様を利用して、dockerの場合は`bin/steep`を作っています。

## [gem_rbs_collection](https://github.com/ruby/gem_rbs_collection)

TypeScriptで言う[DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped)みたいなやつです。
ライブラリーが型定義を持つこともできますが、過去のversionには当然組み込めないことや、型関係のツールはまだ実験的な部分があるのでいきなり大きなライブラリーに組み込んでも後で変更しにくくなると困るから別付けにしてまとめているんだと思います。
しかしながらversion毎の管理が大変そうなので、将来的には型定義はライブラリーに組み込まれた方がいい気がします。でもメンテナーにとっては管理するものが増えて大変……？最適な運用はみんなで考えていきましょう。

ちなみにライブラリーに型(rbs)を組み込む場合は、現状`sig`というディレクトリーを切ってその下にrbsを書けば、後から読み出せるようになっています。

## [rbs_rails](https://github.com/pocke/rbs_rails)

gem_rbs_collectionでActiveRecordのライブラリー的な型は分かるのですが、Railsアプリケーションでは自動生成されたmethodがあるのが普通です。

個々のRailsアプリケーションを読み取って、それぞれのプロジェクト用のrbsを自動生成するツールがこちら。

自動生成されるので「使う人」向けですね。

型定義と自動生成は、個人的に相性がいい気がしています。

今あるアプリケーションコードを全く修正することなく導入できるので。

## [TypeProf](https://github.com/ruby/typeprof)

コードを静的解析して、実際の使われ方からrbsを自動生成するツール。
「こういう場合はどういう型を書けばいいんだろう？」と迷ったら、小さなサンプルコードを書いてTypeProfを実行してみると良いかもしれません。

型素人の予想で恐縮ですが、おそらく将来的には型ファイルを人間が書かなくても、全部typeprofが推測してくれることを目指しているんじゃないかなと予想しています。
将来的にはLSP対応とかするのかも。

SteepはRubyでmethodを追加しても、定義がないと呼び出している箇所で型エラーになってしまい、型を書かざるをえません。ここでいい感じに推測してくれたらいいのになーと思うので、TypeProfはこっち側(型を書かない方向)を目指していそうです。

しかしながらSteepでもif文やcase文等で、ある程度型を推測してくれているっぽいので、どう差別化するのか、あるいは統合するのか、今後の発展が楽しみです。

現時点では「書く人」用、将来的には「使う人」向けになるのかも。

[https://mametter.hatenablog.com/entry/2020/12/14/214326](https://mametter.hatenablog.com/entry/2020/12/14/214326)

# まとめ

型最高！


そろそろRailsプロジェクトに型を導入したい人向けの資料


# はじめに

Ruby v2.7から利用可能になったPattern-Matchingについて、効果的な使い方はないかと考え続けて、ようやく実務でも使えそうなパターンを見つけたので紹介するとともに、その効果を検証する。

# Testing

Testingとは、プログラミングにおける自動テスト、およびそのためのコードのこととする。
フレームワークによって実行されることが多く、フレームワークには[test-unit](https://test-unit.github.io/)、[RSpec](https://rspec.info/)等がある。

テストコードに求められる要件として、

- 書きやすさ
- 読みやすさ
- 見やすさ

があげられる。(個人の意見)

## 書きやすさ

テストコードを書くことはしばしばソフトウェアプログラマーからめんどくさがられ、悩みのタネであると思われる。
最近では[Autify](https://autify.com/)等の登場によって、ある程度の負荷軽減が今後見込まれるが、それでもソフトウェアプログラマーはテストコードは書き続けなければならないだろう。
APIが少ない、または覚えやすいことも重要だ。「こういう場合どうかけばいいんだっけ？」と調べる時間はしばしば工数計算を狂わせる。(データなし)
「できればチェックしたいことはあるんだけど、APIを調べるのが面倒くさいから大まかにチェックだけして細かい部分はチェックしないでいいや。」なんてこともあるかもしれない。
もしテストコードが簡単に書くことができれば、その分「テストパターンは網羅できているか？」のような本質的な問題に意識を集中することができる。

## 読みやすさ

書きやすさも重要だが、読みやすさも重要だ。テストコードのほとんどは、1回書いたら100回以上読まれるだろう。(データなし)
複雑なAPIが使われていると、読み手に「このテストコードはどういう意味だ？」と思われ、また調べる時間が発生し、また工数計算が狂わされる。
できるだけ汎用的な知識だけでテストコードを読むことができれば、「何をテストしたいのか？」のような本質的な問題に意識を集中することができる。

## 見やすさ

テストコード書くときはどんなときか。新機能を追加するときは、TDDであればまずテストが落ち、Diffを目にするだろう。また、コード修正をした場合もテストコードが既存のコードとの挙動の違いを教えてくれる訳だが、ここでもDiffを目にする。
特にArrayやHash等のコンテナ型の比較では、Diffの読みやすさ次第で、作業効率が大きく変わるだろう。(データなし)

# Pattern-Matching

Pattern-MatchingはRuby2.7から導入された機能で、case-when文をよりリッチにした構文のイメージだ。
また、変数へのアサインも同時にやってくれる。

単純な例

```rb
case 42
in Integer => i
  puts i
end
#=> 42
```

Arrayを使った例

```rb
case [1, 2, 3]
in [a]
  p [a]
in [a, b]
  p [a, b]
in [a, b, c]
  p [a, b, c]
end
#=> [1, 2, 3]
```

Pattern-Matchingについてのより詳しい説明は割愛する。参考文献の書籍を参照するとよい。

## One-line pattern matching

Pattern-Matchingは`case`を使わずに1行で記述することもできる。

```rb
# 2.7では `in`
{a: 1, b: 2, c: 3} in {c:}
# 3.0では `=>`
{a: 1, b: 2, c: 3} => {c:}

p c #=> 3
```

One-lineで使う場合は、分岐のためというよりは、変数捕縛やassertionとしての意味合いが強い。(個人の感想)

# Testing meets Pattern-Matching (with GraphQL)

本校で提案したいのは、TestingとOne-line pattern matchingの組み合わせである。
特に[GraphQL](https://graphql.org/)のようなJSONを返すWebAPIのテストで有用性が発揮できることが見込まれる。

比較としてRSpecでの記述を用いるが、本校ではRSpecへの批判的なメッセージは一切ないと明言する。
RSpecは私の浅い経験上、チーム開発をする上で最も利用頻度の多いTestingフレームワークであると確信する。

例としては以下の通り。
サンプルとなるコードは[GraphQLのサイト](https://graphql.org/learn)から借りている。

## 前提

Ruby3を用いる。

JSONを返すWebAPIのテストでは、複雑にネストしたHashやArrayの構造をチェックする必要がある。

比較は単に文字列比較だけでなく、classチェックも同時に行う。

以下のようなデータのチェックする場合を例にする。

```rb
result = {
  data: {
    hero: {
      name: "R2-D2",
      friends: [
        {
          name: "Luke Skywalker"
        },
        {
          name: "Han Solo"
        },
        {
          name: "Leia Organa"
        }
      ]
    }
  }
}
```

## 書きやすさ

テストにおいて重要だと示した書きやすさについてのみ調査する。
書きやすさを表す客観的な指標として、「空白と改行を除く文字数」とした。
テストコードの`$_.gsub(/[\n\s]/, '').length`を計測する。

### RSpec

これぐらいであれば、一度にチェックしてみてもいいので試みた。

```rb
expect(result).to match({
  data: {
    hero: {
      name: "R2-D2",
      friends: [
        {
          name: kind_of(String)
        },
        {
          name: "Han Solo"
        },
        {
          name: "Leia Organa"
        }
      ]
    }
  }
})
```

classチェックに`kind_of`を使用した。
さらに`eq`ではなく`match`を使用しないと、`kind_of(Array)`の場合に期待通りに動作しなかった。`match`にしてみると期待通り動作したので、おそらく`kind_of`を使用するなら`match`を使用しなければならないのだろう。

一度にチェックするのではなく、段階的なチェックを試みる。
friendsのチェックとそれ以外に分けてみる。
先にfriends以外の構造を調べるように修正してみる。

```rb
expect(result).to match({
  data: {
    hero: {
      name: "R2-D2",
      friends: kind_of(Array)
    }
  }
})
expect(result.dig(:data, :hero, :friends)).to match([
  {
    name: kind_of(String)
  },
  {
    name: "Han Solo"
  },
  {
    name: "Leia Organa"
  },
])
```

`:friends`keyの値については後で詳しく調べるので、一旦`kind_of(Array)`とした。
`:hero`の中身が`:name`と`:friends`の2つのkeyで構成されていることはチェックできているはずだ。
`Hash#dig`を用いて`:friends`keyの値を取り出すことで、チェックを2つに分けることが出来た。
文字数は**187**だった。

### Pattern-Matching

Pattern-Matchingを用いて、RSpecの場合と同じことを試みる。

```rb
result => {
  data: {
    hero: {
      name: "R2-D2",
      friends: [
        {
          name: String
        },
        {
          name: "Han Solo"
        },
        {
          name: "Leia Organa"
        }
      ]
    }
  }
}
```

これでテストが落ちれば`NoMatchingPatternError`が発生する。
RSpecのときのように、段階的なチェックに書き直しを試みる。

```rb
result => {
  data: {
    hero: {
      name: "R2-D2",
      friends: friends,
    }
  }
}
friends => [
  {
    name: String
  },
  {
    name: "Han Solo"
  },
  {
    name: "Leia Organa"
  }
]
```

パータンマッチの構文を利用して、`friends`を一旦変数に入れ、後で詳しく調べている。
特別なAPIを調べること無く、意識した順番通りに記述することが出来た。
文字数は**114**だった。

## 読みやすさ

書きやすさの項で示したコードについて、読みやすさを見ていく。
読みやすさの指標として、「使用しているmethodの数」を調査した。「使用しているmethodの数」が少ないほど、コード理解のために必要な知識が減るので、読みやすいと筆者は考える。

### RSpec

```rb
expect(result).to match({
  data: {
    hero: {
      name: "R2-D2",
      friends: kind_of(Array)
    }
  }
})
expect(result.dig(:data, :hero, :friends)).to match([
  {
    name: kind_of(String)
  },
  {
    name: "Han Solo"
  },
  {
    name: "Leia Organa"
  },
])
```

使用しているmethod数は

- `expect`
- `to`
- `match`
- `kind_of`
- `dig`

の**5つ**だった。

### Pattern-Matching

```rb
result => {
  data: {
    hero: {
      name: "R2-D2",
      friends: friends,
    }
  }
}
friends => [
  {
    name: String
  },
  {
    name: "Han Solo"
  },
  {
    name: "Leia Organa"
  }
]
```

使用しているmethod数は**0**だった。

## 見やすさ

同じくテストが失敗した場合のDiffの見やすさも見ていく。
テスト実行土台はRSpecを想定し、friendsに不一致があった場合を想定している。
見やすさの指標は定数化しづらいので、独断とする。

### RSpec

```bash
  1) Test is expected to match {:data=>{:hero=>{:friends=>[{:name=>"Luke-Skywalker"}, {:name=>"Han-Solo"}, {:name=>"Leia-Organa"}], :name=>"R2-D2"}}}
     Failure/Error:
       expect(result.dig(:data, :hero, :friends)).to match([
         {
           name: kind_of(String)
         },
         {
           name: "Han Solo"
         },
         {
           name: "Leia Organa"
         },

       expected [{:name=>"Luke-Skywalker"}, {:name=>"Han-Solo"}, {:name=>"Leia-Organa"}] to match [{:name=>#<RSpec::Mocks::ArgumentMatchers::KindOf:0x0000aaaac33997c0 @klass=String>}, {:name=>"Han Solo"}, {:name=>"Leia Organa"}]
       Diff:
       @@ -1 +1 @@
       -[{:name=>kind of String}, {:name=>"Han Solo"}, {:name=>"Leia Organa"}]
       +[{:name=>"Luke-Skywalker"}, {:name=>"Han-Solo"}, {:name=>"Leia-Organa"}]
```

RSpecの機能によりテストコードがそのまま上部に表示されている。
さらに、期待値と実測値がDiffとして上下に並んでいる。

### Pattern-Matching

```bash
  1) Test
     Failure/Error:
       friends => [
         {
           name: String
         },
         {
           name: "Han Solo"
         },
         {
           name: "Leia Organa"
         }

     NoMatchingPatternError:
       [{:name=>"Luke-Skywalker"}, {:name=>"Han-Solo"}, {:name=>"Leia-Organa"}]
```

上にパターンとして書いたテストコード、下に入力された実際の値が表示される。

パターン構文はDiffとしては表示されず、入力値のみで差分が並ばない。

# 考察

## 書きやすさ

書きやすさの指標は文字数で、以下のような結果となった。

- RSpec: 187
- Pattern-Matching: 114

今回のケースでは、単純な文字数ではPattern-Matchingの方が少ないため書きやすいのではないかと考えられる。
より複雑なチェックをしたい場合は、APIが豊富なRSpecの方が記述量が逆転する可能性もあるが、殆どのテストケースはシンプルなもので占められていると予想する。(データなし)
もちろん「書きやすさ」という観点は多分に主観的なものだと考えられるが、この短いチェックで3:5程の記述量の差が出てくることは注目すべきだろう。

## 読みやすさ

読みやすさの指標はmethod数で、以下のような結果となった。

- RSpec: 5
- Pattern-Matching: 0

いささかズルい指標かもしれないが、定量化できる指標としては注目すべき数字だろう。
実際はmethod一つ一つの意味を覚えることと、Pattern-Matching構文を覚えることの差分になるだろう。

## 見やすさ

見やすさにおいては定量的な指標はないが、RSpecの方が上下に差分が表示されているため、間違いに気づきやすい。
これはRSpecの実装がこの差分表示に力を入れている点が大きい。

# さらなる観点

今回、TestingにおけるPattern-Matchingの有用性を示す指標として、「書きやすさ」「読みやすさ」「見やすさ」を大きな基準とした。
しかしながら、大きくはなくとも考慮する必要があるトピックも多数ある。

## aggregate failures

Pattern-Matchingを用いたTestingは、例外を発生させているため、複数のチェック項目が並んでいた場合に、以降のチェックが実行されない問題がある。
この問題を解決するために、`rescue NoMatchingPatternError`を使う案が考えられるが、その場合、Pattern-Matchingの有用性である変数捕縛が使えなくなってしまい、結局複数チェックができなくなってしまう。

```rb
def pattern_matching
  yield
rescue NoMatchingPatternError => e
end

pattern_matching {
  result => { users: users }
}

pattern_matching {
  users => [{name: 'foo'}]
}
#=>  undefined local variable or method `users' for main:Object (NameError)
```

## 理解障壁

今回の比較では、One-line pattern matching構文を用いた。

Pattern-Matchingは構文さえ理解していれば意味はわかるが、その構文理解がチーム開発での導入障壁になると考える。

事実、筆者も本を2冊ほど読み、よく調べてから初めてその意味合いが分かった。

ピン演算子なども絡んでくると、Ruby2.6までのRubyしか書いたことがないユーザーには、コードを読み解くのに時間がかかるかもしれない。

## Experimental

Ruby3時点でのPattern-Matchingは、case-in文はExperimentalではなく正式サポートとなったが、One-lineはまだExperimentalであり、普通に使用するとwarningが表示される。

そのためproductionで導入する強い理由になりにくいと思われる。
しかしながら、テストコードであれば、それほど怖がらずに導入する事ができるのではと筆者は考える。

## 構文の制限

Pattern-Matching構文では、Hashは全てSymbol keyでなければならない。

よってJSONを返すようなWebAPIのテストでは、毎回`result.to_h.deep_symbolize_keys => {...}`のように、全てSymbol keyに変換してから比較する必要がある。

String keyを使う場合は`result => { "a" => 42 }`のように`=>`を使うことになるが、`=>`は、Pattern-Matchingにおける変数捕縛を行うAsパターン構文とぶつかるた、構文レベルで利用できない。

また、ピン演算子を使って`result => { id: ^user.id.to_s }`のようにしたくなるが、これは構文エラーとなる。

以下のように、一旦別の変数に入れてあげる必要がある。

```rb
user_id = user.id.to_s
result => { id: ^user_id }
```

## 併用

Pattern-Matchingの真価はRuby構文なので、あらゆるTestingフレームワークで使用することができる点にあると考えている。

よって、複雑なHash構造はPattern-Matchingで分解・チェックしつつ、シンプルなObjectに落とし込めたら各Testingフレームワークが持つAPIを使用することでDiffの見やすさに配慮するというハイブリッドな構成も可能である。

# まとめ

書きやすさと読みやすさの点で、Pattern-Matchingは定量的な優位性を示した。

しかしながら、Pattern-MatchingはそもそもTestingのための機能ではないので、見やすさの点ではRSpecの方が優位と言える。

よって、複雑な構造を段階的にチェックし、シンプルなデータにまで落とし込めたらTestingフレームワークでチェックしていくという併用が、現状手を打ちやすい手法なのではないかと考える。

```rb
# friends以外のチェック
result => {
  data: {
    hero: {
      name: "R2-D2",
      friends: friends,
    }
  }
}

# friendsが3要素か数チェックしつつ変数にアサイン
friends => [f1, f2, f3]

# フレームワークの機能を使って、落ちた場合のDiffを見やすく
expect(f1).to match({
  name: kind_of(String)
})
expect(f2).to eq({
  name: "Han Solo"
})
expect(f3).to eq({
  name: "Leia Organa"
})
```


# 参考文献

- [n月刊ラムダノート Vol.1, No.3(2019)](https://www.lambdanote.com/products/nmonthly-vol-1-no-3-2019)
- [プログラミングElixir](https://www.amazon.co.jp/dp/B01KFCXP04/)

筆者のパターンマッチの知識はこの2冊の書籍によって得たものがほとんどだ。

- [ExUnitの`assert`でパターンマッチを用いて複雑なデータ構造をテストする](https://qiita.com/kentaro/items/477c92a57c8aaf694251)

この記事が、TestingでPattern-Matchingを利用するという発想の元となった。


TestingにおけるPattern-Matchingの有用性を探る研究


# 要約

新gem [spring-commands-ridgepole](https://rubygems.org/gems/spring-commands-ridgepole)を作ったので使ってみてね。

Gemfileに

```rb
gem 'spring-commands-ridgepole', group: :development
```

をコピペするだけでinstallできるよ。

```
$ bin/spring binstub ridgepole
```

でbinstubを作って、

```
$ bin/ridgepole
```

で使えるよ。

# ridgepole

[ridgepole](https://github.com/winebarrel/ridgepole)という神ツールを皆様御存知でしょうか。

Rails migration的なAPIでテーブル定義を宣言しておくと、その通りにデータベースにテーブルを構築してくれるツールです。

RDB界のReactです。

プロジェクト超初期ではテーブル定義は試行錯誤を繰り返すのでめちゃくちゃ変更します。
宣言的にテーブルが書けて考えも整理しやすく、私はridgepoleを愛用しています。

しかし、悩みがありました。私の環境では**起動が遅い**ということです。

実際に実行してみましょう。

```shell
$ time docker-compose exec api bundle exec ridgepole --env development --config config/database.yml --apply
Apply `Schemafile`
No change
docker-compose exec api bundle exec ridgepole --env development --config    0.40s user 0.10s system 1% cpu 37.273 total
```

37s

テーブル構成をあれこれ試しまくりたい。高速に開発しないとやりたいこと忘れちゃう。気がついたらtwitter見ちゃう。
そんな自分としては、これは悩みのタネでした。

# spring

そこでピーン。前回のblog postを思い出しました。

[https://ksss.ink/blog/posts/7-spring](https://ksss.ink/blog/posts/7-spring)

もしridgepole起動の遅い原因がRailsコードの読み込みなのだとしたら、springで高速化するはずです。
特に計測もしていませんがやってみましょう。

# spring-commands-*

springを使ったコマンドを作るのはハッキリ言って結構めんどくさいです。

なんか全コマンドいい感じになればいいのにな。

ともかくspringでコマンドを作るには**gemを作る必要があります**。

[https://github.com/rails/spring/blob/577cf01f232bb6dbd0ade7df2df2ac209697e741/lib/spring/commands.rb#L36-L46](https://github.com/rails/spring/blob/577cf01f232bb6dbd0ade7df2df2ac209697e741/lib/spring/commands.rb#L36-L46)

```rb
  # Auto-require any Spring extensions which are in the Gemfile
  Gem::Specification.map(&:name).grep(/^spring-/).each do |command|
    begin
      require command
    rescue LoadError => error
      if error.message.include?(command)
        require command.gsub("-", "/")
      else
        raise
      end
    end
  end
```

このようにgemspecを読み込んでrequireするようになっているので、Gemfileで`path`指定するか、publicなgemとして作るしかありません。

とはいえ実装は短いです。

皆さんのアプリケーションのGemfileにも[spring-commands-rspec](https://github.com/jonleighton/spring-commands-rspec)等が忍ばれていませんか？

rspec用でも実装は実質[これだけ](https://github.com/jonleighton/spring-commands-rspec/blob/master/lib/spring/commands/rspec.rb)です。

```rb
module Spring
  module Commands
    class RSpec
      def env(*)
        "test"
      end

      def exec_name
        "rspec"
      end

      def gem_name
        "rspec-core"
      end

      def call
        ::RSpec.configuration.start_time = Time.now if defined?(::RSpec.configuration.start_time)
        load Gem.bin_path(gem_name, exec_name)
      end
    end

    Spring.register_command "rspec", RSpec.new
    Spring::Commands::Rake.environment_matchers[/^spec($|:)/] = "test"
  end
end
```

こうしてgemをinstallしておくだけで、springでbinstubを生成したり、springを土台にコマンドを実行できて高速化を図ることができます。

# でもちょっと大変だった

ちょっとハマった点としては、

ridgepoleが、おそらく

```
ridgepole読み込み => Railsコード読み込み
```

という順番を想定しています。

しかしspringでは

```
springでRailsコード読み込まれてる => ridgepole読み込み
```

の順番になってしまうので[without_table_options](https://github.com/winebarrel/ridgepole/blob/1847a679dfbcd10ca6572a56afab22a8724dc897/lib/ridgepole/ext/abstract_adapter/disable_table_options.rb)がなくてNoMethodErrorになってしまいました。

この辺を理解するのがハマりました。理解できたら解消はすぐでした。

# 37s => 1s

ともかくがんばって作った成果はというと

```shell
$ time docker-compose exec api bin/ridgepole --env development --config config/database.yml --apply
Running via Spring preloader in process 1023
Apply `Schemafile`
No change
docker-compose exec api bin/ridgepole --env development --config  --apply  0.39s user 0.09s system 37% cpu 1.273 total
```

37s => 1sと超高速化することができています！！！

私はdevelopmentとtest環境で同時に適用されるように

```rb
task :apply do |t|
  ["development", "test"].each do |env|
    system "bin/ridgepole --env #{env} --config config/database.yml --apply"
  end
end
```

とRake taskを組んでいるので、およそ1分かかっていたものが2秒位で終わります。記述も簡潔です。導入もgemをinstallするだけです。

これは革命。

1回あたり約1分短縮しているので、このgemを作るのにかかった2時間くらいを考えると、120回叩いたらペイします。

やったね。


ridgepoleの起動をめっちゃ早くする


# まあそんなもんかな

rspecなどを叩くたびに、毎回5sほど待っていたのですが、まあそんなもんかなと思っていました。

しかし、「本当にそうなのか？」という疑問が湧き上がりました。

ちゃんと調べてみると、これまでまったく気がついていませんでしたが開発中のRailsプロジェクトで[spring](https://github.com/rails/spring)がうまく動いてませんでした。。。これはショック。

# Spring is not running.

よくよくspringのことを調べてみると、自分の環境ではspringが動いていないことがわかりました。

```
$ docker-compose exec api bin/spring status
Spring is not running.
```

こりゃ本腰入れるかと、とりあえず本家のdocumentを読みます。

[https://github.com/rails/spring](https://github.com/rails/spring)

ふむふむ。特に何も考えなくても使えるツール的な雰囲気がします。

dockerに入っていろいろ試してみましょう。

```
$ docker-compose exec api bash
root@207515053d29:/api# bin/spring stop
Spring stopped.
root@207515053d29:/api# time bin/rake -T > /dev/null
Running via Spring preloader in process 253

real	0m9.134s
user	0m0.105s
sys		0m0.039s
root@207515053d29:/api# time bin/rake -T > /dev/null
Running via Spring preloader in process 264

real	0m1.034s
user	0m0.101s
sys		0m0.029s
root@207515053d29:/api# time bin/rake -T > /dev/null
Running via Spring preloader in process 273

real	0m1.085s
user	0m0.112s
sys		0m0.033s
root@207515053d29:/api# bin/spring status
Spring is running:

  240 spring server | api | started 53 secs ago
  242 ruby -I /api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/lib -e require 'spring/application/boot'
````

なるほど。確かに初回は9s、2回目以降は1sと高速化しています。

やれやれと思ってdockerから抜けると……。

```
$ docker-compose exec api bin/spring status
Spring is not running.

$ time docker-compose exec api bin/rake -T > /dev/null
docker-compose exec api bin/rake -T > /dev/null  0.41s user 0.10s system 5% cpu 9.414 total
```

えええ……。

ちょっと深くまでは追っていませんが、dockerから抜けるとspringは止まってしまうようです。shellの子プロセスとして動いているのかな？

普段は`docker-compose exec`でrails consoleやらrspecやらを動かしたい派なので、これは結構困ります。

ざざーっとspringのコードを読んだ上での想像ですが、おそらく現在のプロセスからforkしてアプリケーションコードを読み込み、spring processを立ち上げ、unix domain socketを作ってそこにコマンドを送り込んで実行する的な感じなのでしょう。たぶん。

なので、求めるソリューションとしては、常時spring serverが立っている必要があります。

# クラフト隊長みたいに

なんとかdocker上でいい感じにspringを使うことができないものかとサッとググってみると、[https://github.com/jonleighton/spring-docker-example](https://github.com/jonleighton/spring-docker-example)を参考にした記事が多いようでした。

基本的にspring containerを立ち上げて、unix domain socket用のvolumeを作り、アプリケーションから参照できるようにして入力コマンドに気をつけて……。

<strong class="text-2xl">やってられるかああああああああ</strong>

springに期待するのは影でコソコソやってほしいのであって、表立ってバリバリ考えることを増やしてもらうことではありません。複数のプロセスからspringを活用したいのであれば、専用containerを立てるのもいいかもしれませんが、そんなシーンは正直想像できません。

もっと簡単なソリューションは無いものでしょうか。

# かごめかごめ

求めているものはdockerに入って`$ bin/rake`としたときに自動的に立ち上がってくれるアレです。

spring serverでもいいのですが、バックグラウンドで動いてくれるアレが欲しいのです。

あの子がほしい。

あの子じゃわからんので一生懸命springのコードを読んだ結果、undocumentedですが以下の方法を見つけました。

```
$ bin/spring server --background &
```

`--background`というundocumentedなオプションを付けると、ログが消えてくれます。
さらに`&`でバックグラウンドプロセスに無理矢理することができます。

これをentrypointスクリプトで実行させれば、影でこっそり動いてくれるはずです。

```
$ time docker-compose exec api bin/rake -T > /dev/null
docker-compose exec api bin/rake -T > /dev/null  0.40s user 0.09s system 30% cpu 1.635 total
```

これで無駄な時間が一日5s × 100回 = 500sくらいは減るでしょう。トータルで2時間くらいかかったので15日経てばペイします。やったね。

# 追記

docker-compose upしてCTRL+Cで終了する運用をしていたのですが、2回に1回必ず以下のエラーが出てspring serverも立ち上がりません。

```
/api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/lib/spring/server.rb:47:in `initialize': Address already in use - connect(2) for /tmp/spring-0/93af75a8297fc11a0f686ab9ea1fa5e3 (Errno::EADDRINUSE)
	from /api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/lib/spring/server.rb:47:in `open'
	from /api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/lib/spring/server.rb:47:in `start_server'
	from /api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/lib/spring/server.rb:43:in `boot'
	from /api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/lib/spring/server.rb:14:in `boot'
	from /api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/lib/spring/client/server.rb:10:in `call'
	from /api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/lib/spring/client/command.rb:7:in `call'
	from /api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/lib/spring/client.rb:30:in `run'
	from /api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/bin/spring:49:in `<top (required)>'
	from /api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/lib/spring/binstub.rb:5:in `load'
	from /api/vendor/bundle/ruby/3.0.0/gems/spring-2.1.1/lib/spring/binstub.rb:5:in `<top (required)>'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from bin/spring:15:in `<main>'
```

おそらくバックグラウンドプロセスグループで起動しているため、docker-compose終了時にシグナルが届かず、unix domain socket fileとpid fileが残ってしまうようです。
うまいことシグナルを届けることができればいいのですが、よく分からなかったので、`bin/spring server --background &`の直前にファイルを削除することにしました。

```
$ rm -f /tmp/spring-0/*
$ bin/spring server --background &
```

これで毎回springの起動に成功します。やったね。


springコンテナ無しでspringを使いたい


# 耳が壊れた

ひょんなことから耳が破壊されました。

このことについては全てが丸く収まったらまとめて記録を放流するつもりなのですが、ともかく極力耳に何も触れたくない生活が続きそうだったので、骨伝導ヘッドセットを買ってみました。聴力は問題ありませんが、端的に言うと耳が荒れました。

# 骨伝導ヘッドセット

ヘッドセットは重要です。普段仕事をしているときは周りに赤ちゃんを含む家族がいることが多いので、会議音に気を使わせたくありません。また、普段リモート会議をしていても、mac本体だけの場合より、何かしらのマイクを付けている場合のほうが音声が聞き取りやすいと感じています。

耳に何も触れずに、音を外に漏らさず、マイクもついて会議向きのやつを探していました。

rebuild.fmの[この回](https://rebuild.fm/294/)を聞いて、「どうやら骨伝導のヘッドセットがあるらしい」という事が分かっていたので、

抜け目なくtwitterでおすすめを募集してみたところ、おすすめを教えていただけました。

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">OpenComm by AfterShocks<br><br>自信を持ってお勧めできる</p>&mdash; sachin21 (@scn21) <a href="https://twitter.com/scn21/status/1365887607754813446?ref_src=twsrc%5Etfw">February 28, 2021</a></blockquote>

調べてみたところ、骨伝導ヘッドセットといえばAfterShocksというメーカーの独壇場で、その中で目的に合わせて商品を選ぶ感じなようです。

自分の目的がスポーツ用ではなく会議用だったので、マイクが付いているOpenCommにしました。

# OpenComm

<iframe style="width:120px;height:240px;" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" src="https://rcm-fe.amazon-adsystem.com/e/cm?ref=qf_sp_asin_til&t=ksss-22&m=amazon&o=9&p=8&l=as1&IS1=1&detail=1&asins=B08ND2M821&linkId=962afc37908557c5591d7c1ee7f2e18d&bc1=ffffff&amp;lt1=_top&fc1=333333&lc1=0066c0&bg1=ffffff&f=ifr">
    </iframe>

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">マイニューギアー…… <a href="https://t.co/syOt0DMdTr">pic.twitter.com/syOt0DMdTr</a></p>&mdash; ksss (@_ksss_) <a href="https://twitter.com/_ksss_/status/1366622295112867842?ref_src=twsrc%5Etfw">March 2, 2021</a></blockquote>

# 第二の聴覚

骨伝導は初めて使ってみたのですが、「第二の聴覚」という感じで不思議な感覚です。

だれかが頭の中でささやくとこんな感じなのかな。

試しにSpotifyで音楽を聞いてみると、さすがに音質がとか言える感じではないですが、カジュアルにBGMを楽しむ分には全く問題なく使えて、むしろ音楽を聞く頻度が増えました。

# 装着感

後ろからフックで耳に引っ掛けて、こめかみの若干下に振動する部分が当たる感じです。耳の穴の手前のちょっとピョコってでっぱってる部分のすぐ側です。思ってたよりは耳に近いですが、自分が気にしている部分には触れていないのでOKです。

気になるところといえば、眼鏡と若干バッティングして耳周りがごちゃごちゃしてしまうのと、音量を上げると鼓膜がくすぐったくなることぐらいかなと思います。

本当にちゃんと聞き取りたいときは、耳の穴を塞ぐとむしろよく聞こえるという技も発見しました。


# マイク

これまではRazerのKrakenという完全にゲーム用途のヘッドセットを愛用していました。

<iframe style="width:120px;height:240px;" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" src="https://rcm-fe.amazon-adsystem.com/e/cm?ref=tf_til&t=ksss-22&m=amazon&o=9&p=8&l=as1&IS1=1&detail=1&asins=B07PP7889B&linkId=07a5086a22edf75fc09a76b162c1b174&bc1=ffffff&amp;lt1=_top&fc1=333333&lc1=0066c0&bg1=ffffff&f=ifr">
    </iframe>

スプラトゥーン2でチーム組んでやっていたころに買ったもので、音声もマイクも見た目も気に入っていたのですが、いかんせん耳が破壊されたのでしばらくは使えそうにありません。

比較するには用途がぜんぜん違うのですが、よく会議する同僚に聞いてみたところ、マイクの音質はさすがにOpenCommよりKrakenの方が良かったようです。しかしながら現在でも問題なく使えているので、会議用途としてはマイク付きにしてよかったです。

# Bluetooth

さらに、OpenCommならBluetoothなので、ケーブルが邪魔になりません。よく赤ちゃんを抱っこしながらミーティングに参加したり、ちょっと会議を聞きながら飲み物を用意したりできて、Bluetoothは完全に正解でした。ちょっとボタンを押せばつながるので、毎回の接続が面倒ということもありません。

# いつでも側にいる相棒

見た目は小さいこともあって、若干ちゃちい感じはします。「耳からうどん垂れてる。オシャレ！」みたいなことにはならないんじゃないかなあ。無駄に気を張らずに、いつでも側にいる相棒という感じです。

# 電池

電池の持ちはいいのか悪いのかよくわかりませんが、数日に一度不安になって充電する程度です。今どれぐらい電池が残っているのか分かりにくいですが、本体が「電池は残り半分です」みたいに話してくれるのでかわいい。

# まとめ

耳が破壊された際には骨伝導がおすすめです。


骨伝導ヘッドセット


# 抜けてねぇんだ…下っ端根性が…!!

「昔憧れていた上司の年齢に自分がなっている」という事実に気がついたとき、私は愕然としました。
自分としては昔からなんにも変わっちゃいなくて、心の中はまだまだ下っ端根性が抜けていないのです。自分でなにかしようとする気がなくて、いつも仕事が降ってくるのを待っている気がします。それでいて自分は何かができる気でいます。

確か26歳くらいのときにプログラマーとしてキャリアを開始したはずですが、あの頃から一体何が変わったというのでしょうか。

確かにプライベートでの変化は激しかったです。
結婚、第一子誕生、第二子誕生、等々。おおよそ26歳の時に想像していなかった状況に今いるでしょう。
本当に恵まれた人生です。

では仕事面ではどうでしょうか。
3回の転職を経ても、"上司"みたいな役所についたことはないし、誰も育成したことも誰も率いたこともありません。
単に転職が多いからか、「あいつには向いてなさそうだから任せられない」と思われているからかわかりませんが、とにかくそういう経験は今までありません。

今でもまだ、26歳のニュービーのときのままなのです。

今日で35歳になりました。

# こんな感じでいわゆる定年ってことになるんでしょう

35歳と言えば定年説です。自分もそんな歳になってしまったのか。本当に信じられない。。。

今さら「35歳定年説なんてない！現役バリバリだぜ！」みたいな事を言う気はありません。ありませんが、いま現状コードは書いています。

しかしながら、まあこんだけやっていれば仕事をどう進めればいいか大体分かるし、技術的に全体像はつかめているので大体必要なことも分かります。

大体どういう問題が起こりそうで、じゃあ先にどういう手を打っておけばいいのか選択肢もだいたい浮かびます。うまくいったりいかなかったりするけど。

そんなことをやっていると、明らかに一人では手が足りないので、人の手を借りるしかありません。

ある程度大雑把に問題を切り取って、残りの仕上げを別の人にお願いします。

仕様の議論でも「技術的に可能か」みたいな視点を求められるので、頻繁にミーティングにも参加します。

そうこうしているうちに、コードを書くところにまでたどり着くことができず、ついにはコードを書く部分も別の人にお願いする。こんな感じでいわゆる定年ってことになるんでしょう。

っていうか、なりかけてる。

# 何に手を貸すか

私は恵まれた境遇にあるので、この先のことは自分で選択することができます。

ひたすらコードを書くことも望めばやれるだろうし、それ以外をやることもできるでしょう。

昔であれば迷わず前者を選んでいたと思いますが、最近は後者でも結構いいかもなと思い始めています。

[Front-End Study #5](https://www.youtube.com/watch?v=x069r_jOZhk)が面白かったので乗っかるのですが、

「問題」「解決策」「設計」があるとして、更にその先もあると思うんです。「何がしたいか」とか。

「何がしたいか」「問題」「解決策」あたりで自分がやれることがあるのならやってみたい。そんな人生もいいかなと思えてきました。

自分ひとりの力なんてちっぽけなので、世界をどうこうできるとは思ってません。でも、世の中の困りごとのうち「何に手を貸すか」を選ぶことができます。こんな当たり前のことに気がついたのは結構最近です。これが私の35歳の現実です。まだまだ下っ端根性が抜けてません。

数年後、自分が同じようなことを言ってるかはわかりませんが、これが35歳の私の現実です。

微力ながら、自分が手を貸せる何かを模索していければと思います。


35歳になりました


日本語に対応したog-image生成サービスを作ってみた。

[https://og-image-qqmw83jkp-ksss.vercel.app/](https://og-image-qqmw83jkp-ksss.vercel.app/)

(ドメインは後でいい感じにしたい。)

レシピは簡単。vercelを使っただけだ。

### 1. [vercel/og-image](https://github.com/vercel/og-image)をforkする

リポジトリにあるvercelボタンでは、forkじゃなくなるなどいい感じにならなかった。

### 2. [README.md](https://github.com/vercel/og-image#deploy-your-own)に書いてあるとおりに作業する

- localのnode versionをvercelで使えるversionに揃える。今回は14.Xだった。
- fork直後のコードが環境変数`AWS_REGION`を見てlocalなのかproductionなのか判断しているので、localで`AWS_REGION`を設定されているとproductionとして動くので `Error: Failed to launch the browser process! spawn /usr/bin/chromium-browser ENOENT` というエラーが出る。aws lambda上でchromiumを動かすコードが動いているようだ。解決策として別の環境変数を設定して、vercel上で環境変数を設定した。

### 3. 日本語フォントを入れる

[https://qiita.com/mkizka/items/f2d4836e4cfd241acccf](https://qiita.com/mkizka/items/f2d4836e4cfd241acccf) が参考になった。

### 4. vercelにdeployする

おわり


日本語og-image


# 新規アプリ作ってます

お仕事で新規アプリを作ってる。

具体的には `rails new` してコードを書いている。

アプリを実装するにあたり、いわゆる認証周りの技術選定をする中で、そもそも認証の仕組みをよくわかってなかった事に気がついた。

普段Webサイトで、最初だけidとpasswordを入力して後は入力しなくてもいいのはなんでだろう？

Web系のプログラマーを10年近くやってきて今まで知らないのはやばいかもしれないと思い調べてみた。

# Session on Rails

[Railsガイド](https://railsguides.jp/action_controller_overview.html#%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AB%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%81%99%E3%82%8B)によると、ふむふむ、難しいことはよくわからんけど、とにかくサインインしたければ`session`オブジェクトに書き込むといいらしい。

```shell
session[:current_user_id] = user.id
```

ここで湧き上がる疑問は、**「なぜこれでいいのか」**

ちょうどHTTP APIを使ったバックエンドアプリケーションを開発していたので、とりあえずcurlしてみた。

```shell
$ curl -i -X POST http://localhost:3000/sign_in -d '...'
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: strict-origin-when-cross-origin
Content-Type: application/json; charset=utf-8
Vary: Accept
Set-Cookie: _app_session=...; path=/; HttpOnly; SameSite=Lax
ETag: W/"3f357b434c6759cced5bd7770bfb1728"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 1e16eab9-0da8-44ec-88c1-f4b67a177fd4
X-Runtime: 0.275964
Transfer-Encoding: chunked

{"status":"ok"}
```

なんかよくわからんが`Set-Cookie`という長い文字列を持ったヘッダーが返ってきた。これが怪しい。

# CookieStore

Cookieといえば、[Railsガイド](https://railsguides.jp/action_controller_overview.html#%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3)によるとセッションストアなるものがあり、これが選べるらしく、CookieStoreがデフォルトらしい。

セキュリティのことは無視できないので、選択肢がある以上調べなければならない。

そもそもCookieってなんだ。

# Set-Cookie/Cookie

調べてみたところ、`Set-Cookie`ではなく`Cookie`ヘッダーもあるようだ。

試しにcurlで`Cookie`ヘッダーをセットしてみる。値はさっき`Set-Cookie`で返ってきていた値だ。

```shell
$ curl -X POST -H 'Cookie: ...' http://localhost:3000/
```

Railsのコード内で`session[:current_user_id]`を見てみると、なるほど、さっきセットした値が取得できた。

```rb
session[:current_user_id] #=> 123
```

つまりサーバーで`Set-Cookie`ヘッダーにセットした値を、クライアント側でそのまま`Cookie`ヘッダーにつけてあげれば、サーバー側でセットした値を再生できる。だからいちいちidとpasswordを入力しなくても、誰からのリクエストなのか分かる。

こういう仕組みっぽい。おそらくcookieはWebブラウザが内部でファイルに保存してくれて自動的にリクエストヘッダーに入れてくれているんだろう。

これがCookieのプリミティブな仕組みなようだ。

# CookieStore再び

ここでCookieStoreの仕組みを考えると意味がわかる。

idとpasswordを入力したことで得られる`user_id`みたいなアカウントを識別する値をcookieに入れたのがCookieStore。CookieStoreなら情報がクライアント側に保存されるのでDBなりが不要。
cookieを他人に取られても、そのcookieだけを無効化することができないのが弱点。ただし、暗号鍵を変えれば全アカウントの既存のcookieを無効化はできる。

他の方法として、無意味な文字列をcookieに入れて、`user_id`などの情報を別のストアに入れるのが`ActiveRecordStore`なり`MemCacheStore`。これなら1 session毎に無効化などのコントロールが可能。ただし、もちろんDBなりが必要で、データアクセスもリクエスト毎に必要。

Railsのメモリにデータを乗せておくのが`CacheStore`。DBなりが不要になる代わりに、deployのたびに全ユーザーで再サインインが必要になるので小規模向けか。

とスルスル理解できた。

# その先へ

## curlのcookie用オプション

更に調べると、curlにはcookie用のオプションがあるらしい。確かにいちいちヘッダーの値をコピペするのは大変だった。

### Set-Cookieをファイルに保存

```shell
$ curl -h | grep -- -c,
 -c, --cookie-jar <filename> Write cookies to <filename> after operation
```

`-c` or `--cookie-jar`オプションをつければ、指定したファイルにSet-Cookieの内容を保存してくれるっぽい。

### Cookieをファイルからセット

```shell
$ curl -h | grep -- -b,
 -b, --cookie <data|filename> Send cookies from string/file
```

 さらに、この保存したファイルは`-b` or `--cookie`オプションで`Cookie`ヘッダーにセットするとように指定できる。これでいちいちコピペしなくて済みそうだ。

# Cookie on Rails

[Railsガイド](https://railsguides.jp/action_controller_overview.html#cookie)によると`cookies`ヘルパーもある。[実装](https://github.com/rails/rails/blob/a8a1afd45572004c903a7aefaa99640fa13547d4/actionpack/lib/action_controller/metal/cookies.rb)を見ると`request.cookie_jar`でもいいっぽい。

比較にためsessionと同時に使ってみる。

code

```rb
cookies[:cookie_id] = 123
session[:session_id] = 123
```

response

```shell
curl -i -X POST http://localhost:3000/sign_in
...
Set-Cookie: cookie_id=123; path=/; SameSite=Lax
Set-Cookie: _app_session=...; path=/; HttpOnly; SameSite=Lax
...
```

あれ、値丸見えなんですけど。

<br>

<strong class="text-4xl">値丸見えなんですけど！！！！</strong>

<br>

いや[Railsガイド](https://railsguides.jp/action_controller_overview.html#cookie)にも書いてあるんだけど、`cookies`だと暗号化されない。

<br>

<strong class="text-4xl">cookiesだと暗号化されない。</strong>

<br>

今日はこれだけ覚えて返ってください。

# cookies.signed / cookies.encrypted

[RailsのAPI](https://api.rubyonrails.org/classes/ActionDispatch/Cookies.html)によると、`cookies.signed`や`cookies.encrypted`というものがあるようだ。

code

```rb
cookies.encrypted[:encrypted_id] = 123
cookies.signed[:signed_id] = 123
```

response

```shell
Set-Cookie: encrypted_id=mwk5nJI7...; path=/; SameSite=Lax
Set-Cookie: signed_id=eyJfcm...; path=/; SameSite=Lax
```

なるほど。値は読めなくはなった。`encrypted`と`signed`の違いはよく分からないけど、どちらもkey名が見えてしまっている。

どっちにしろ、key名も値も見られず改ざんを防ぐには`session`を使ったほうがいいようだ。

# まとめ

- Cookieは便利。
- セキュリティは大事。

<p class="text-sm">og-image日本語対応させるためには <a href="https://github.com/vercel/og-image">vercel/og-image</a>をforkして独自にdeployすればできるっぽいんだけどその作業がめんどくさ……。</p>


Learning cookie with curl


# Rubyのパターンマッチ

2020年は、ほとんどプログラミング的なキャッチアップをしてこなかったので、
Ruby v2.7で追加されたパターンマッチについてキャッチアップした。

[https://zenn.dev/ksss/scraps/a82a629826fdf6](https://zenn.dev/ksss/scraps/a82a629826fdf6)

まだうまく使える場面に出会えてはないが、チャンスを虎視眈々と狙えるぐらいにはなれた気がする。

# GraphQL

以前から使ってみたいと思いつつ、新プロジェクトを始める機会を得たのでなんとなく使ってみた。

印象としては、結構大規模なプロダクトを整理するみたいな使い方のほうがいい気がする。
結局mutationなんか特に実装がRPCになるし、フロントエンド側の習熟も若干必要。

しかしながらRESTっぽくリソースを用意して、これらを組み合わせる感じでAPIを組めばサーバー側はコードが上手くまとまる気がする。

RelayのConnection型を使うなら、気をつけないとlimitが効かなくてサーバー側で全件取得になる危険性がある。resolverではRelationを返して、TypeでActiveReocrdとレスポンス形式の間を取り持ってあげるのが良さそう。

# RailsのDelegated Type

Rails6.1から入ったっぽいActiveRecordのレコード関連付けに関する機能
[https://github.com/rails/rails/pull/39341](https://github.com/rails/rails/pull/39341)

[https://edgeapi.rubyonrails.org/classes/ActiveRecord/DelegatedType.html](https://edgeapi.rubyonrails.org/classes/ActiveRecord/DelegatedType.html)

STIでJSON dataにする方法だとDBの機能が使えないし、テーブルを分けると一覧で取得するのが大変になってしまうのでちょうど困っていたところ、

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">Delegated typesによってSTIは過去のものになってしまったな。</p>&mdash; Akinori MUSHA (@knu) <a href="https://twitter.com/knu/status/1369921851854495745?ref_src=twsrc%5Etfw">March 11, 2021</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

というtweetをみかけてググってみると、見事に問題を解決するソリューションだった。なんで思いつかなかったんだという発想だけど、ちょうどRails6.1だし使ってみてる。

GraphQLと組み合わせて、Union型ではなく単一の型に合わせてみてる。
集約するTypeを用意して、fieldを定義して、このfieldに合うようにmethodを定義していく。
resolverではRelationを返すと、GraphQLがConnectionのインターフェースに沿ってlimit等を設定してくれるのでこれに乗っかる。
Typeは以下のような感じにしている。

```rb
module Types
  class MainType < BaseObject
    field :kind, String, null: false
    field :subject, String, null: false
    field :body, String, null: false

    def kind = object.nable.class.name.split('::').last
    def subject = object.nable.subject
    def body = object.nable.body

    using Module.new {
      refine Sub1 do
        def subject = "サブ1"
        def body = sub1_column1.to_s
      end

      refine Sub2 do
        def subject = "サブ2"
        def body = "#{sub2_colmun1}:#{sub2_column2}"
      end

      refine Sub3 do
        def subject = "サブ3"
        def body = "(#{sub3_colmun1})"
      end
    }
  end
end
```

こうするとModelはまったく触らず、GraphQLのことはGraphQL内に閉じれる。コードも1 fileにまとまる。

でも一定以上複雑になると対応できなさそう。これでどこまでいけるか。

# AWS Amplify

小さいプロジェクトの実装を任されたが、横断型のプロジェクトなのでコンテキストを分かっているシニアエンジニアがコードの雛形を作ってくれた。これがAWS AmplifyとReactでできていて、急いでキャッチアップした。
最初はAWS版のFirebaseかなと思っていたけど、そもそもFirebaseのことはよく分かってない。
調べていくうちに、アレもできるコレもできると書いてあるので、「もしかしてRailsもいらなくなるのでは？」と思ったけど、更に調べるとそんなことはなかった。

自分なりの解釈だと、AWS Amplifyはフロントエンジニア向けのサービスで、SPAやネイティブアプリのデプロイがgit pushだけでできるようになっている部分がメイン。
そこに付け足しで、Cognitoでの認証だとか、LambdaでのFunctionだとか、AppSyncとDynamoDBでデータベースだとか、EC2というサーバーを使わずにサーバーレスでやれる事をサポートしている感じ。
でもやっぱりサーバー置いたほうが柔軟性はあるので、シンプルな用途向けかなと思った。

しかしながら、SPAを簡単にdeployして他の人にレビューしてもらう使い方なんかはとても便利そうなので、簡単な部分はAWS Amplifyで管理して、複雑な部分はサーバーを置いてAPIで通信することで、サーバーレスとサーバーアリ(何て言うの？)を組み合わせると良さそう。

# Next.js

なんとなく以前からTLで名前は見かけていて、フロントを書く機会も得られたので学んでみた。

そもそもSPAを分かってなくて、Reactも分かってなくて、Reduxも分かってなくてと、かなり覚えることはあったけど、このblogをNext.jsで作れるぐらいには習得できた。
routingをファイルの配置だけでやるのが初学者的にすごく楽だし、よく分かってないwebpackだとかの設定もいい感じにやってくれる。らしい。

と、よく分かってなくてもどんどん作っていけるのが、初心者にとっての魅力の一つだと思う。
最終的に先程のAWS AmplifyのプロジェクトもNext.jsで書いてdeployした。

# SPA

そもそもRailsで言うview層をネイティブアプリみたいに動かすという発想がなくて、ここから新鮮だった。
そして、ちょうど仕事でもバックエンドとフロントエンドでの分業に悩んでいて、SPAにすればフロントエンドをまるっと別の人に任せることができて、Rails側もよく分かってないnode環境を完全になくすことができる。この試みは今の所成功していると思う。

規模やメンバーによってやりやすい開発方法は変わるだろうけど、今の自分の状況には合っていた。

# React

これまでVueを使っていたけど、大して理解していなくてなんかJSに値渡すやつぐらいの認識だった。

しかしながらNext.jsを学んでいくにあたって、関数にするだけというシンプルで覚えやすいcomponent化の方法だったりとか、「選択肢を選んだらボタンを有効化する」みたいなインタラクティブな挙動も作りやすく、「これがGUIプログラミングかー」とまるっきり新しいパラダイムを学ぶことができた。

# Redux/Redux Toolkit

「そもそも状態って何？」みたいな初心者だったので概念を把握するのに苦労した。

この記事がかなり分かりやすくて助かった。

[https://www.hypertextcandy.com/learn-react-redux-with-hooks-and-redux-starter-kit](https://www.hypertextcandy.com/learn-react-redux-with-hooks-and-redux-starter-kit)

自分なりの解釈では、「SPA全ページで使えるグローバル変数みたいなやつ。グローバル変数だけどアクセスの仕方を制限してデバッグとかしやすくしてる」みたいな理解。

ReduxとRedux Toolkitの違いはよく分かってない。

# tailwindcss

[https://tailwindcss.com/](https://tailwindcss.com/)

最近のCSSはこんな感じなんかと体感できる。
style直書きみたいなノリでclassに小さいスタイルを書いていく。なのでオリジナルのclassをほとんど作らなくていい。vscodeとの連携もできてるし、最近のversion upで変更がめちゃくちゃ早く反映されるので開発体験がいい。

# Cookie

恥ずかしながらCookieのことすらろくに分かってなかった。でも認証って触る機会はあんまりないし、だいたいフレームワークがなんとかしてくれるので、意外とプリミティブな部分は分からず使ってる人も多いのでは？Cookieについては別エントリにまとめたい。


ここ3ヶ月で学んだことまとめ


# せっかくNext.jsを学んだのでblogを作ってみた。

仕事でフロントを触る機会があり、興味があってNext.jsを軽く学んでみた。

Next.jsを学んでいると必ず出てくるのがvercelというワード。
出てくるのは当たり前で、Next.jsを開発しているのがvercel社、ということらしい。

vercelというのはサービス名でもあって、これを使えば無料でNext.jsで書いたものをホスティングできるっぽい。
できるっぽいというか、既にできたものがこのページだ。
この記事もmarkdownで書いて、JSのライブラリでHTMLに変換しているらしいが、ほとんどのコードはコピペで作っているのであんまりよく分かってない。

React歴0から付け焼き刃で`create-next-app`から使ってみている。どうやら`create-react-app`で作るやり方もあるらしいけど違いはあんまりわからない。ただ、「ファイルパスがそのままURLになる」という機能はNext.jsのものらしい。通常ならルーティングを書かなければいけないらしいが、Next.jsではそれが不要。Railsで言うroutes.rbが不要になっている。初学者としてはルーティングの書き方を覚えなくて済むのでこれだけでも十分便利。他にもやらなくて良くなっていることがいっぱいありそう。Next.jsはサーバーもクライアントもどっちのviewもまかなえるのが特徴らしいけど、クライアントだけを見ても十分便利なので、初学者から見ると`create-react-app`で始める意義がよく分からない。

ReactのJSXもblog用途だとほぼテンプレートエンジンだなあ。パーツパーツで関数っぽくまとめられるのがよい。topが1 tagに限定されているのでHTMLっぽい。タグの内側も任意に書ける。明示的にimportしてるのでコードを追いやすい。

vercelならGitHub.comにpushしたら、そのまま自動的に公開される。しかもAnalyticsまでついてくる。お金を払えばLambdaでちょっとしたサーバー処理もできる。

httpsも無料でLet's Encryptを使ってやってくれる。

すごい。

# コンプレックス

私は、コンプレックスとして「自分のホームページを作ったことがない」というものがあった。
自分のホームページを持っている人への憧れがあった。

「自分のホームページ」とは何か？
「自分のホームページ」と呼べる条件が自分の中でなんなのか整理してみた。
おそらく、条件にはスペクトルがあり、どこかで線を引くべきだろう。

## Hatena blogは「自分のホームページ」か？

これは自分的にNOだった。

手軽に文章を書いて無料で公開して、お世話になっているHatena社に還元できるとあって、長く使っていた。
これからも使うかもしれない。
しかし、コンプレックスは解消されなかったのである。

## 自鯖立てて運用すれば「自分のホームページ」か？

これはYESだろうと思う。サーバーも物理だろうがクラウドだろうがなんでもいい。
しかしながら、気軽に始めるには結構大変そうっていうかめんどくさそうだった。
気軽に文章を公開したいと言う欲は、既にHatena blogで解消されているため、残りは自己満足でしか無い。

## vercelに上げたものは「自分のホームページ」か？

この辺が絶妙なラインで、無料であること、GitHubにpushすればdeployできること、Next.jsが使いやすいことなどがあり、ある程度の気軽さはある。
HTML、CSS、JavaScriptは、ライブラリの手は借りてはいるが、自分で書いている満足感もある。

しかしながらご覧の通り、デザインはからっきしだ。og:imageもvercelに乗っかってる。RSSフィードもない。ここから先はめんどくさいゾーンに入ってしまう。ちょっとずつ作っていく感じかなあ。

# ともかく

「自分のホームページ」感は結構出てる気がする。
いわゆる平成のホームページ感。
手軽なノスタルジーの摂取。

いい時代になったもんですね。
