
# 去年度作ったgem

Railsでサービスを開発する中で感じたストレスを解決するためgemを作ってはプロダクトに取り込むってことをいくつかやったのでその紹介。

## [acb](https://github.com/kakubin/acb)

ActiveRecordのインターフェイスからデータのCSVをシームレスに発行してくれるgem。

複雑なデータの組み合わせだと諦めて生SQLを書いてしまった結果、テーブルを何十個もJoinしなきゃいけなくクエリが激重みたいなことを解決したくて作った。
Ruby側でデータの索引方法を定義でき、ActiveRecordのpreloadを使って読み込みのクエリを単純化することでDB側の負荷が減り結構な速度で出力できるようになった。


## [rubocop-grape](https://github.com/kakubin/rubocop-grape)

grapeというAPIを簡単に作成できるgemがある。
こってこてのDSLに対して日本語ドキュメントが充実してないため、フォーマットがぐちゃぐちゃだったのを解決したくて作った。

詳しくは[こちら](https://kakubin.github.io/entry/2022-08-21/)


## [actionslack](https://github.com/kakubin/actionslack)

アプリケーションからSlack通知を飛ばすのに、メッセージをcontrollerだったりmodelだったり至るところで組み立てており
難読化していたのでそれをまとめる目的で作成。

結果、見通しが良くなった。

## おわり

実は今日リリースしたgemがある。
[active_record_polyline](https://github.com/kakubin/active_record_polyline/)というgemでGoogle Mapとかでよくみる移動経路を扱うPolylineという規格をActiveRecordで簡単に扱えるようにしてくれる。
位置情報をその都度単一のレコードとして記録してしまうと、レコード数が瀑速で増加してしまう。
そこで位置情報の配列を文字列にエンコーディングするPolylineという規格を使うことで一定期間の移動経路を保存できるようにした。
ただし、保存される情報にタイムスタンプは含まれないので単純に経路しか分からず、「この時間にここにいた」という情報は
別途控えておく必要がある。


去年度作ったgem



[CBcloud 2022アドベントカレンダー](https://qiita.com/advent-calendar/2022/cb-cloud)の12日目の記事です。

デバッグをするとき以下のように例外処理のブレイクポイントを書いて実行したとします。

```language-ruby
begin
  nil.call
rescue StandardError
  binding.irb
end
```

ここでエラーオブジェクトの変数へのアサインを忘れていることに気づきました。

そんな時は`$!`を参照しましょう。

[Rubyの仕様](https://docs.ruby-lang.org/ja/latest/method/Kernel/v/=21.html)で直近の例外を参照することができます。


Rubyのデバッグでエラーオブジェクトのアサインを忘れた時


# RuboCop::Lint::SafeNavigationWithEmptyとは

[CBcloud 2022アドベントカレンダー](https://qiita.com/advent-calendar/2022/cb-cloud)の5日目の記事です。


[Lint/SafeNavigationWithEmpty](https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Lint/SafeNavigationWithEmpty)とは、
RuboCopのルールで`empty?`をぼっち演算子で呼び出しているのを検知しANDで別々に書くよう修正してくれる。

「ハイ、ソウデスカ」で自動修正しちゃってもいいんですが、なんでそうするべきなのか気になったので調べてみる。


> Checks to make sure safe navigation isn't used with `empty?` in a conditional.

> While the safe navigation operator is generally a good idea,
when checking `foo&.empty?` in a conditional,
`foo` being `nil` will actually do the opposite of what the author intends.

日本語訳すると、
「条件分岐の中でempty?とぼっち演算子が一緒に使っていないかチェックする」
「ぼっち演算子は一般的には良い手法ではあるが、条件分岐内で`foo&.empty?`をチェックするとき、
`foo`が`nil`であることは実際には書き手の意図と全く逆のことである。」

全く意味が分からないので僕の解釈を付け加える。

例えば以下のようなコードであった場合、ガード節は引数argが不正な値でないかチェックしている。

```language-ruby
def do_something(arg)
  return if arg&.empty?

  do_something_with(arg)
end
```

この時、`arg == nil`であった場合はチェックをすり抜け`do_something_with`に`nil`が渡されることになる。
この予測しづらくかつ見落としがちな挙動が書き手の意図した挙動であるか、
それを読んだ他者もしくは後で見返した書き手がすぐには判別できない。
ならば少なくとも、それぞれをチェックするようにすればこの行が何を「しているか」(したいかではなく)は
見落とさなくなるであろう。

以上がこのCopが作られた背景と思われる。

## ついでに

ついでに導入時のPRまで遡ってみる。
https://github.com/rubocop/rubocop/pull/6568

おおよそ同じことが書かれているがこのディスクリプションの中で、
更にそれより前にされた議論を[見れるリンク](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54853)がある。

そこでは「`return if variable&.empty?`が書き手の意図しない挙動をする」や
「レビュー時に見落としがち」といったことが話されているので概ね間違いなさそう

## 更についでに

RuboCopルールの定義ファイルの読み方を解説する。

[これ](https://github.com/rubocop/rubocop//blob/23a3924bdfc992ab89e8b9770f41a555aff39989/lib/rubocop/cop/lint/safe_navigation_with_empty.rb)が
さっきまで話していたCopの実態。

1. RuboCopのルールはRuboCop::Cop::Baseを継承して定義される。(22行目)
2. `on_if`を定義することでコードを探索して if 文が出てきたらこの`on_if`が実行される。なので引数の`node`は親が必ずifノードになる。(32行目)
3. `safe_navigation_empty_in_conditional?`はCop::Baseで提供される`def_node_matcher`を使って[28行目から30行目](https://github.com/rubocop/rubocop/blob/23a3924bdfc992ab89e8b9770f41a555aff39989/lib/rubocop/cop/lint/safe_navigation_with_empty.rb#L28-L30)で定義されたASTパターンであり、nodeがこれに完全一致しない場合は`false`を返す。(33行目)
4. 最後に`add_offence`でルール違反の検知を登録する。その際、`MSG`(25行目)が警告のメッセージとして渡される。(37行目)


RuboCop::Lint::SafeNavigationWithEmptyとは


# データを破壊した話

[CBcloud 2022アドベントカレンダー](https://qiita.com/advent-calendar/2022/cb-cloud)の4日目の記事です。


## 経緯

ある時、以下のような位置情報を持つテーブルでprefecture_idが入力されていないためにエラーが発生していたので、
full_addressからprefecture_idを補完するという作業を実行しました。

```languate-sql
CREATE TABLE `locations` (
  `id` bigint unsigned NOT NULL AUTOINCREMENT,
  `prefecture_id` bigint,
  `full_address` carchar(255),
  PRIMARY KEY (`id`)
)
```

Railsを利用していたので以下のようなスクリプトを作成し、ステージング環境で実行しました。

```languate-ruby
ActiveRecord::Base.logger = Logger.new($stdout)

Location.where(prefecture_id: nil).find_each do |location|
  prefecture = find_prefecture_from(address: location.full_address)
  Location.update(prefecture_id: prefecture.id)
end
```

実行中、ログファイルを tail -f して経過を見ていたんですが、「ガガガッ....ガガガッ....」
という比較的間の開いた間隔でログが更新されるのに違和感を感じつつも実行完了まで待ちました。

完了後、確認のためテーブルを見てみると、
全てのレコードのprefecture_idが同一の値になっておりそこでバグがあるまま実行していたことが発覚しました。

原因は先程のスクリプト最後から二行目、モデルのインスタンスに対してupdateを
呼び出したいところ、モデルクラスに対して呼んでおり所謂where句のないupdateクエリを発行していました。


## 対応

本来このスクリプトはprefecture_idを補完するものだったので、
スクリプトの修正、全レコードでprefecture_idの削除、
最後にもう一度スクリプトを実行することで修復が完了しました。


## 予防

今回はfull_addressから情報が復元できたので良かったですが、
今後同様の事故が起きたとき必ずしも復元できるとは限らないので予防としてリンターの設定を行いました。

```languate-ruby
module RuboCop
  module Cop
    module Rails
      class DirectUpdate < Base
        MSG = "don't call update to ApplicationRecord"

        ENTITIES =
          Dir.entries('app/models').map { _1.gsub(/\.rb$/, '').camelize.to_sym }.freeze

        def_node_matcher :update_to_model?, <<~PATTERN
          (send
            (const _ $_)
            :update ...)
        PATTERN

        def on_send(node)
          const_name = update_to_model?(node)
          return unless const_name

          add_offense(node) if ENTITIES.include?(const_name)
        end
      end
    end
  end
end
```


データを破壊した話


# いい感じにFibonacciが書けた

<script src="https://gist.github.com/kakubin/7b83bde057fe02cb6b51dbaf99a21499.js"></script>


いい感じにFibonacciが書けた


# rubocop-grapeを作った

## モチベーション

弊社のサービスはRailsを使って開発されおり、
特に[Grape](https://github.com/ruby-grape/grape)というREST APIを簡単に作れるgemを使っている。

なぜGrapeを使っているかは、はっきりとした理由は分からず誰かが詳しいからと導入したわけでもないため、かなりオレオレな感じになっている。
また知見の偏りもあるため、APIをフルに活かしきれていないコーディングで、レビュワーは都度同じ指摘を何度もする必要がある。
プロジェクトコードの規模はかなり膨れ上がりレビューも大変になったので解決する必要がある。

そこで[rubocop-grape](https://github.com/kakubin/rubocop-grape)というGrape用のRubocop拡張を作ってみた。


## 使い方

Gemfileからインストールして、.rubocop.ymlに`rubocop-grape`と追記したらそのまま使える。
```language-ruby
gem 'rubocop-grape', require: false
```

```language-yaml
require:
  - rubocop-grape
```


## 効用

まだルールは二つしか作れていないが、これを導入することで多少なり苦労がなくなるのではと思っている。
さらにはGrapeに関するナレッジがこの拡張を介して他のプロダクトにも反映できれば一石二鳥である。
一方でルールネタに尽きている。


rubocop-grapeを作った


# 既存コードにRubocopを導入

今の会社のコードにはRubocopが入っているがほとんど適用されていない状態なので
インデントがめちゃくちゃだったり、シンタックスが適当だったりで可読性が低い。
LSPにもめちゃくちゃに指摘されてファイル開くとエディタの画面が真っ赤っ赤。

今から.rubocop.ymlを本格的に適用しようにもPullRequestが大量に立っているので
何も考えずやってしまうとコンフリクトは避けられない。

そこでPR内の変更ファイルに対してのみ新しいRubocopルールを適用させていけば
コンフリクトもなくコードがきれいになるのではと考えた。

結果、出来上がったのが以下のコード。

```language-ruby
# lib/tasks/rubocop.rake
# frozen_string_literal: true

require 'rubocop/rake_task'

module RubocopStrictTask
  def setup_subtasks(name, *args, &task_block)
    namespace(name) do
      desc 'PRの変更ファイルに対して走る強めのrubocop'

      task(:strict, *args) do |_, _task_args|
        RakeFileUtils.verbose(verbose) do
          options = full_options.dup

          if diff_files.empty?
            puts 'Rubocop: No Diff Files'
            exit
          end

          options.push '-c', './.rubocop_strict.yml'
          options.push(*diff_files)
          run_cli(verbose, options)
        end
      end
    end

    super
  end

  RuboCop::RakeTask.prepend self

  private

  def diff_files
    @diff_files ||= `git diff --name-only --diff-filter=ACMR origin/master..HEAD -- '*.rb'`.split
  end
end

RuboCop::RakeTask.new
```

.rubocop_strict.ymlに設定された新しいRubocopルールが
origin/masterと差分のあるファイルのみに適用されるようになっていて、
bundle exec rake rubocop:strictで実行できる。

結果、通常のPRの運用でApproveをもらったら、origin/masterを作業ブランチへマージした後に
このRakeタスクで修正してもらい再度pushするという流れになった。


既存コードにRubocopを導入


# 卒論の原罪

卒論も受理され卒業も確定したので振り返ってみる。
特に僕と同様の研究をしようと思っている人の参考になれば幸いである。


## 研究背景

ECサイトで商品の購入検討する時、実物を見れないから
実際に買った人のレビューって参考にならない？(僕は参考にしてる)
その時、本当に欲しい情報って肯定的なものだけでなく否定的なもの、
もっと言うとなんでそう評価したのか、ってことが知りたい。
でも楽天なんかで見てみると、目に付きやすいとこにあるレビューは
高評価なレビューばかりでバイアスがあるように感じる。
アマゾンなんかだと「このレビューが参考になった」ってボタンで投票ができて
票数が多いレビューは購入するときの参考になったりするけど、
この機能ってプラットフォーム運営側としては事業としてクリティカルではないし
データを十分集められる保証も無いために機能提供しているとこは実際少ない。
そこで、参考になるレビューをレコメンドするために、
レビュー文を自動で判定する機械があると嬉しいよねって発想に至った。


## 目的

ユーザーの投稿するレビューを解析して、
他のユーザーが商品購入する際の参考資料として適当な
レビューであるか判定するモデルを作る。

注意すべきは、このモデルが判定しているのは
「そのレビューが肯定的な内容を書いているか否か」ではなく
「なぜそのレビュー評価(例えば5段階評価で1を付ける、逆に5を付ける)
に至ったのか具に説明している」である。
(この時点で致命的な事があるのだが後に説明する。)

また卒論発表のときに突っ込まれたけど、ターゲティング広告みたいに
個人個人に合わせてレコメンドするものでもない。
世間一般的に参考になるかどうかの判定が目的。


## やったこと

### huggingfaceのBERTを使ってみる

まずは普通にやった場合どのぐらいの精度が出るのか、
ライブラリの使い方に慣れるという点も含め、
huggingfaceで配布されている事前学習済みBERTモデルで
レビュー文全体の特徴量を抽出し二値分類を行った。(卒論で書いた提案手法1に該当)
この時が確か75%前後？で予測できたと卒論に書いた気がする。
(僕の卒論読める人はそっちを確認して欲しい)
この精度、実は試行の度にバラついてかなり怪しかった。
あるときは65%とか、またあるときは90%弱とか。
手始めにBERT触った感覚としては「BERTすげぇ!!!、けどこのばらつきなんだ??」ってずっと言ってた。

### 提案手法を考える

一般的にBERTは一回の入力に2文までしか考慮されていない。
(学習のやり方にもよるのだが)
それに対し、レビューというのは大抵2文で収まるようなものではなく、
レビュー全体から重要な2文だけ選択してレビュー全体の代表とするというのも
無理やりな気がする。
ここまでのことをまとめると、BERTを使って、レビュー全体から特徴量を取る手法
というのが要件になる。
ここで指導教授から「レビューを一文ずつBERTで特徴抽出し、
得られたものを結合してTransformerに入力してみたら？」という助言を頂いた。
要するに以下の図の感じ。(卒論で書いた提案手法3に該当)

![proposed_method](https://user-images.githubusercontent.com/58410530/151568274-81e7783c-7b94-4a25-b8d4-42b98771553c.png)

1. レビュー全体を構文解析通して一文ずつに分割
2. 一文ずつトークン化、それをBERTに通して文の特徴量を獲得
3. 得られた特徴量のうち、CLSトークンに対応する出力のみ選択
4. 各文の3の結果を合体&特異トークンなどを付与して所定のサイズに整形
5. 4の出力を4層のTransformerに入れてレビュー全体の特徴量を獲得
6. 続けて全結合でゴニョゴニョして、票数が一定以上あるないで二値分類

というのが提案手法の流れ。

ちなみに提案手法2は提案手法3のTranformerをCNNに置き換えた対照実験になっている。


### 実装、計測

ここからはこんな感じの同じ日課を3週間ぐらい過ごした。

1. 午前中に実装する
2. 計測開始、待ち時間に卒論書き進める
3. 計測結果のまとめ
4. 次の計画、修正箇所を考え翌日のタスクに積む

一人暮らしで人との会話もないし、コロナで籠もりっきりなのも相まってまじで辛かった。


## 計測結果

提案手法1 > 提案手法3 > 提案手法2 の順で精度が良いという結果だった。
正直、3 > 2 > 1とかの順になってくれれば万々歳だったけど、
世の中そう上手くは行かないんですね。


## 実際のところ

### 筋書き

卒論では提案手法を3つ出したことになっている。
でも実は提案手法は1つの予定で、ここまで読めば分かるとおり提案手法3がそれになる。

当初の筋書きでは、
提案手法1の内容で、利用する事前学習済みBERTモデルの性能の確認検証、
提案手法2の内容で、提案手法の対照実験、その結果、
3 > 2 > 1の順で精度良く予測できて、「BERTを使って3文以上から特徴抽出できる!」、
「CNNよりTransformer良いね!」って結論に着地したかった。

けど実際の計測結果は芳しくなく何度も試行錯誤したけどうまく行かなかった。
時間が足りず大きな変更はできなかった。
まだまだ試したいことはあったけどここでタイムアウト、
聞こえ良くなるよういい感じに書き換えて提出した。


### 提案手法3の予測要因

なぜ提案手法3がうまく行かなかったか。
というより何を指標に予測しているか。
おそらく、文章長で良いレビューか判断していたと思う。
参考にならないレビューは「よかった」とか「買わないほうがいい」とか短文が多いし、
逆に参考になるレビューは、なぜその評価になったかの説明で文が長くなる。
このことを検証するため、一文ごとにBERTで取れるCLSトークンと対になる出力を全て
任意のトークン(例えば「1, 0, 1, 0, ...」)に置き換えて同様に計測してみた。
つまりここでは文章数だけで予測できるのか検証している。
この結果、置き換える前と全く同じ精度になった。
文ごとの特徴量を使っても結局は文章数しか見てない、という可能性が大きいことがわかった。

ちなみに、卒論にはこのこと書いたけど自分の研究を否定することは
書かないほうがいいということで提出前に消した。


## じゃあどうすればよかったの？

![wakannaippi](https://user-images.githubusercontent.com/58410530/159123475-2a7eeba4-810a-4282-9964-1f9bade4985a.jpg)
(この画像を使いたかっただけのタイトル)

と言いつつちょっと真面目に考えてみる。

卒論最終章にはいろいろ書いたけど結局のところ、下の2つが無難な気がする。

- 学習データは全て長文のもののみ利用する
  - 長文かつ参考にならないレビューって少なそうだけど
- BERTをファインチューニングする

でもまあ正直ファインチューニングってどこまで効果あるか未知数だし
前者を試してダメそうだったら研究テーマ変えた方が良さそう。
そんなとこ。

最後まで読んでくれてありがとう。


### 追記

卒論に使ったコードは下のリンク先に置いておきます。
わからないことあったら気軽に[連絡ください](mailto:wetsand.wfs@gmail.com)。

[ReviewVital](https://github.com/kakubin/review_vital)


卒論の原罪


# 慶應の習わし

大学に入って一番最初に驚いたこと。
それは教職員が「君」付けで呼ばれること。
入学式で、学長が「〇〇君」なんて呼ばれてるの聞いて違和感しかなかった。

[このページ](https://www.keio.ac.jp/ja/about/history/encyclopedia/18.html)に
書いてあることを要約すると、全員が学び、全員が教え合うという精神&先生は
「福󠄁澤諭󠄀吉先生ただ一人」ということで君付けなのだそう。

ここで発生する問題が、教授の呼び方どうすればいい問題。

特殊な文化的事情により、「さん」で呼んでもいい雰囲気ではあるけれど、
かなり年上の教員に「さん」付けは気が引ける。

一つ思いついたのは、役職を付けること。
「〇〇教授」、「〇〇准教授」など。
便利ではないか！

それでもここで、問題が発生した。

うちの学科に一人、60歳ほどの教員がいるのだが、その人はなんと「専任講師」。
別に専任講師が悪いわけではないし、なにか理由があるんだろうけども、
60近い方に「〇〇専任講師」呼びなんてできるはずがない。

どうしたものか。

PS : 今日、卒論が受理された。


慶應の習わし


# 卒論研究テーマが決まらない

8月の中頃には卒論テーマも決まり
9月初めの中間発表でどんなことをするかは発表していた。

ただその研究に使うデータが手に入る見通しがなかなか立たない。

自分の選んだテーマの先行研究者が研究室の先輩だったから、
データをくれないかと連絡しているのに全く返信が来ない。

一応、その方と同期だった方からも連絡してもらって、
向こうには伝わってるぽいんだけど。。。

こうなってくると、連絡を当てに何もしないことがかなりリスキーなので
代替の研究テーマを決めなければならない。

この状態が二週間続いているのにだらだらと過ごし今日まで全く進捗がない。
流石に今日には決めるぞ！の覚悟で籠もり、他の先行研究を漁ることにした。

1時間ほど経った頃、気づいたらNext.jsのチュートリアルを読んでいた。


## Nextへの書き換え
ということでブログをNuxtからNextに書き換えてみた。
ドキュメントもほどほどにとりあえずやってみるの精神で
書いたせいでかなりガタガタの実装になっちゃったけど。


### つまったとこ
SSGをするためには動的パスには何が来るか宣言しなければならないことを知らず
気づくのにだいぶ時間がかかった。

またそうで合った時に`fs`を読み込むのは`getStaticProps()`内でなければ
ならないのも「ひょえ〜」って感じで。

なんとなくでできたけど、また改めてドキュメント読んで型とかちゃんと
定義しなきゃなーとか課題はまだまだたくさんある。


### ToDo
- prismjsを入れる
- モバイル対応
- 他のページも作る[ここ](/about_me)とか[ここ](/biograph)も
- 型注釈を適切に入れる
- (卒論テーマ決める)

CSS辛い...


卒論研究テーマが決まらない


# 散歩中の出来事
散歩中に起こった出来事で一句詠む

```
背後より
聞こえる放屁
子連れ夫妻
```


散歩中の出来事


# Nuxt.tsで自分のWEBページを作った
日々勉強したことをちゃんと記録できる場所が欲しくて作った。
また自分は何ができるのかを発信できれば今後のキャリアにも良い影響あるのかなと思ってたり。

ちなみにNuxt.tsの勉強も兼ねて"はてぶ"やよく出回っているテンプレートは一切使わず0から作成した。

全くフロントの知識がない中で作ったためにtypescriptに全労力を持っていかれ、デザインがすこぶる悪い。
他にもトップページのエントリー順が最新順になるとは保証されていなかったりと色々不具合あるので少しずつ直していくつもり。
