Rails で gem を導入するときに最低限やること

普通にみんなやっていることだと思うけど、自分が gem を入れるときに最低限やることをまとめてみた。

何かしらの方法で探してきた gem を「導入するかどうか」の判断をするときにやることです。

やること一覧

1. 今後もメンテされそうかを調べる
2. README を 全部 読む
3. 依存関係を調べる
4. ソースコードを読む

今後もメンテされそうか？

ほとんどの gem は GitHub で公開されているので、下記の観点を参考に調べる。

• 最終コミット日時
  • 1年前とかだと安定している or 放置されている
• contributes の数
  • 多いとメンテされそう
• star の数
  • 使用者が多く、問題が報告（修正）されそう
• Releases の数
  • 基本機能は安定してそう
• Issues, Pull Requests の数、対応状況
  • 問題が放置されていないか
  • 自分が踏みそうなものが挙がっていないか
• 作者はどんな人か？
  • 有名な gem の作者なら技術力ありそう(= ちゃんと動きそう)

ただ、「機能が少なく、あまり更新されない gem」とか「Issues は多いけど、他に代用もない phantomjs」みたいなのもあるので、上記だけでは判断できないこともある。

README を全部読む

はてなブログや Qiita などの記事は参考になるけど、「gem のアップデートに追従できていない」「インストール手順が中途半端」「一応動くけど、内容が微妙」みたいなのが多いです。 安易に信じると、未来の自分が死にます。

今までの経験上、信頼できるのは「ソースコード、次に README」です。英語が苦手でも、 README は一通り目を通した方が良いです。

依存関係を調べる

GitHub のリポジトリにある xxx.gemspec を読んで、依存関係がどのくらいあるかを調べる。

• 依存関係が多い
  • 他 gem (特に Rails )のアップデートで苦労するかも
• 依存関係が少ない
  • 他 gem へ移行することがあっても楽そう

ソースコードを読む

全部を読むのは時間かかるので、「バグに遭遇したとき、コードを読めそうか？直せるか？」の観点でざっと目を通します。

• ファイル数がどのくらいか
  • 少ない場合は fork してメンテ(もしくは再実装)がしやすい
• メタプロがどのくらい使われているか
  • rails_admin などは導入に覚悟が必要になってくる
• コードが読みやすいか
  • 複雑なコードは直す気になりにくい
  • デバッグ・修正も大変
• テストコードがあり、 CI が動いているか
  • コードを直したときに、既存機能が壊れていないか確認できる

おまけ: 絶対にやったらダメ

はてなブログや Qiita の「おすすめ gem 10選」みたいなので公開されている gem を一気に Gemfile に入れるのは絶対ダメ。

問題が起きたときに「どの gem が原因か？」が分からなくなって大変なので、面倒でも1つずつ調べてから導入すべきです。

まとめ

ざっと gem を導入するときに気にしてることを書いてみました。何か参考になれば幸いです。

rake notes で TODO が増え過ぎたら CI で検知できるように拡張する

Rails アプリから機能を gem 化する方法の実例を1つ公開してみる。

sinsoku.hatenablog.com

rake notes を拡張する

rake notes で Rails アプリ内の "OPTIMIZE|FIXME|TODO" を一覧表示できるが、これを拡張する。

ソースコードの探し方

1. rails/rails のリポジトリをローカルに git clone して、 git grep :notes する
2. annotations.rake が見つかる
3. git grep "class SourceAnnotationExtractor" する
4. source_annotation_extractor.rb が見つかる

パッチを書く

lib/rails_notes_validation/lib/rails_notes_validation.rb

# frozen_string_literal: true
class SourceAnnotationExtractor
  module MaxSizeValidation
    def display(results, options = {})
      super

      annotations = results.values.flatten
      display_annotations(annotations)
      display_failed_if_exceed(annotations)
    end

    private

    def display_annotations(annotations)
      puts 'Result'
      tag_and_size = annotations.group_by(&:tag).map { |tag, arr| [tag, arr.size] }
      tag_and_size.sort_by(&:last).reverse_each do |e|
        tag, size = e
        puts "  * [#{tag}] #{size}"
      end
      puts
      puts "Total"
      puts "  * [#{tag}] #{annotations.size}"
    end

    def display_failed_if_exceed(annotations)
      max_size = ENV['SOURCE_ANNOTATION_MAX_SIZE'].to_i
      exceed_size = annotations.size - max_size
      if exceed_size.positive?
        puts
        puts "Failed: #{exceed_size} notes exceed. [#{annotations.size}/#{max_size}]"
        exit 1
      end
    end
  end
  SourceAnnotationExtractor.prepend(MaxSizeValidation)
end

動かしてみる

$ rake notes
app/models/user.rb
  * [10] [TODO] Fix me

Result
  * [TODO] 1

Total
  * [OPTIMIZE|FIXME|TODO] 1

Failed: 1 notes exceed. [1/0]
$ echo $?
1

これで終了コードが 1 になるので、 CI で実行させれば fail になる。

おわり

gem にするまでもないコードとか、公開前の動作確認とか、そういうので便利ですよ。

Rails アプリから汎用的な機能を gem 化する方法

これから Rails 用の gem を作ってみたい人向けの内容。

gem 化する

実は下記のようなコードを置くだけで RubyGems に登録しなくても、 gem として認識される。

Gemfile

gem 'hello_world', path: 'lib/hello_world'

lib/hello_world/hello_world.gemspec

# coding: utf-8
lib = File.expand_path('../lib', __FILE__)
$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)

Gem::Specification.new do |spec|
  spec.name          = 'hello_world'
  spec.version       = '0.0.1'
  spec.summary       = ''
  spec.authors       = ['']
end

lib/hello_world/lib/hello_world.rb

module HelloWorld
  def self.say
    puts 'Hello, World'
  end
end

これは簡単な例だけど、 rails c で読み込まれていることが確認できる。

HelloWorld.say
#=> "Hello, World"

仕事のコードで「これ gem にできるかも？！」みたいなのを gem 化して、ある程度試して安定してきたら公開すると良い。

一般公開する

概要は下記のような感じ。分からんところはググれば参考になる記事がたくさん見つかると思います。

$ bundle gem hello_world 
MIT License enabled in config
Code of conduct enabled in config
      create  hello_world/Gemfile
      create  hello_world/.gitignore
      create  hello_world/lib/hello_world.rb
      create  hello_world/lib/hello_world/version.rb
      create  hello_world/hello_world.gemspec
      create  hello_world/Rakefile
      create  hello_world/README.md
      create  hello_world/bin/console
      create  hello_world/bin/setup
      create  hello_world/.travis.yml
      create  hello_world/.rspec
      create  hello_world/spec/spec_helper.rb
      create  hello_world/spec/hello_world_spec.rb
      create  hello_world/LICENSE.txt
      create  hello_world/CODE_OF_CONDUCT.md
$ cd hello_world/
$ vim hello_world.gemspec # TODO: を直す
$ vim README.md # 使い方を書く
$ bundle exec rake release # RubyGems に公開される

Rails の timestamps カラム(created_at, updated_at) と別に日時カラムを作る理由が分からん

Rails を使っていて、日時カラムを作るケースがありますが、あれのメリットが知りたいと思って、ブログに書いてみた。

created_at を使わず、あえて自分達で 別のカラムに https://t.co/BzSE87AzJJ を保存する実装にする意味が分からん…。非同期処理で時間がズレるのを避けるとかならともかく、それ以外で作る意味あるのかなぁ…。

— 神速@リリカルエンジニア (@sinsoku_listy) 2016年10月10日

例: ユーザーの登録日時

# db/migrate/20161010010101_create_users.rb
class CreateUsers < ActiveRecord::Migration
  create_table :users do |t|
    t.string :name
    t.datetime :registered_at, null: false

    t.timestamps null: false
  end
end

こんな感じで、ユーザーの登録日時を created_at を使わず、 registered_at のように別カラムを用意して、自分たちで Time.now などを保存するような実装のメリットが知りたい。

timestamps で良いと思っている理由

カラムを使い分けることがほぼない

よく「レコード挿入日時と登録日時は意味が違う」という意見をお聞きするのですが、「ユーザーが登録するとレコードが1件できる」という事を考えると、そこまで意味が違うものなのか疑問。

そもそも「レコード挿入日時」と「登録日時」と使い分ける仕様がほぼ無い。(後述する非同期処理くらい？)

使った方が楽

「ActiveRecord が自動的に生成するものを使うべきじゃない」って話も聞くけど、用意されている機能を使った方が冗長にコード書かなくて済むし、自分たちで再実装するより良いのでは？ belongs :user, touch: true とか使えて便利ですし。

cache に使われる

標準だと View の cache で Modle の updated_at が使われるので、 updated_at を最終更新日としておいて方がシンプルに Rails のレールに乗れて良い。

日時カラムを別に用意する方が良いと思うケース

非同期処理を使う

「非同期処理（または登録処理）に時間がかかり、ユーザーのリクエスト 〜 DB挿入に時間がかかる」場合、値がズレるので別カラムは必要かもしれない。そのズレが問題になる仕様の場合は。

単純な更新日時じゃない場合

「特定のカラムが更新されたときだけ、更新日時を更新したい」みたいな仕様の場合は updated_at とは別にカラムを用意した方が良いと思う。

• あえて非正規形なテーブルにしている
• 既存のDB設計が腐っているが、直せない

みたいなケースだと、 updated_at をそのまま活用するのは難しいと思う。

まとめ

DB設計に問題がなければ、基本的には Rails 標準の timestamps を使って良いのではないかと思っています。

もし、別の考えなどあればコメントなど頂けると嬉しいです。

Rails の link_to_if にブロックを渡したときの挙動が分かりにくいので注意

Rails の link_to_if にブロックを渡したときの挙動が分かりづらいので、使う場合の注意点をまとめてみました。

TL;DR

ブロックの内容を条件によってリンクにしたい場合は capture を使うのがシンプルで良いです。

<% body = capture do %>
  <%= image_tag 'icon.png' %>
  <span><%= user.name %></span>
<% end %>
<%= link_to_if condition, body, root_path %>

link_to_unless や link_to_unless_current の場合も同じ。

link_to_if にブロックを渡す例

ユーザーのアイコンと名前を条件によってリンクにする場合を考えます。*1

<% if condition %>
  <% link_to root_path do %>
    <img href="icon.png"></img>
    <span><%= user.name %></span>
  <% end %>
<% else %>
  <img href="icon.png"></img>
  <span><%= user.name %></span>
<% end %>

これを DRY にするために link_to_if を使おうとしても、うまく動きません。

<% link_to_if condition, root_path do %>
  <img href="icon.png"></img>
  <span><%= user.name %></span>
<% end %>

# If the condition is true
# => <a href="/">/</a>
# else
# => <img href="icon.png"><span>name</span>

条件が true の場合、ブロックが 評価されない からです。

ブロックを必ず評価するメソッド

条件が true の時にaタグで囲むメソッドを作ってみました。

def link_to_block_if(condition, options = {}, html_options = {}, &block)
  if condition
    link_to(options, html_options, &block)
  else
    capture(&block)
  end
end

使い方はこんな感じ。

<% link_to_block_if condition, root_path do %>
  <img href="icon.png"></img>
  <span><%= user.name %></span>
<% end %>

Rails へプルリクを送ることを検討

rails/rails で検索してみると、 link_to_if でブロックを必ず評価するプルリクが出て、1度マージされた後 revert されていました。

• Update url_helper.rb by stevenspiel · Pull Request #19844 · rails/rails
• Fixed behaviour, when block wasn't passed to link_to from link_to_if(condition = true) method by avdept · Pull Request #19936 · rails/rails

また、 Qiita にも同じような記事がありました。

• link_to_ifにブロック渡した時の挙動が欲しいのと違う - Qiita

似たようなことで困っている人がいることは分かったので、 Rails にプルリク送ってみても良いかもしれないと考えた。

メソッド名の検討

link_to_block_if は微妙なので、他のメソッド名を考えてみましたが、どれも微妙・・・。

- link_to_content_if
- link_or_content_tag
- wrap_link_to_if

link_to_if や cache_if のように _if のメソッドは条件が true の時にブロックが評価されない。 また、 find_or_create_by のように _or_ のメソッドは前半が true の時にブロックが評価されない。

Rails の他メソッドと一貫性の無いメソッド名になるのはダメそう。

命名に時間がかかるメソッド

そもそも、命名に時間がかかるメソッドは何かがダメです。 そこで、1つのメソッドにする事を止めて、下記のように2つのメソッドで書いてみました。

<% body = capture do %>
  <%= image_tag 'icon.png' %>
  <span><%= user.name %></span>
<% end %>
<%= link_to_if condition, body, root_path %>

あれ、これで良いのでは・・・。Rails の標準メソッドの組み合せなので、後から読んでも分かりやすいし。

まとめ

• link_to_if にブロックを渡した時の挙動は少し分かりづらい
• ただ、 Rails の _if のメソッドとしては一貫性がある
• 命名に悩むような難しいメソッドは、そもそも設計がダメ

Rails にプルリクを投げる前に気づくことができて良かった。

RubyKaigi 2016 で色んな Rubyist に link_to_if について話を聞いて、助言を頂いたお陰です。感謝。

*1:似たような例だと「公開日時以降はバナーをリンク可能にする」「公開設定のリソースをリンク可能にする」など

tachikoma_ai を v0.3.0 にアップデートしました #mokumoku_onsen

7/16(土)〜18(月)の2泊3日で開発合宿に参加していて、前々からやりたかった tachikoma_ai の gem のアップデートをしました。

開発合宿について、詳しくは id:niwatako さんが記事を書かれているので、興味ある方はそちらを参照して下さい。

niwatako.hatenablog.jp

TachikomaAi について

TachikomaAi は sanemat/tachikoma の拡張で、 bundle update のときプルリクに github の比較URLをつける gem です。

実は tachikoma_ai を仕事でも使っているのですが、使っていて機能不足なところやバグを見つけたので、今回直しました。

変更内容

v0.2.0

• ✨ 0.1.0 のような v のついてないタグに対応

v0.3.0

• ✨ .gemspec の homepage が github.com でない gem の一部に対応
  • lib/tachikoma_ai/strategies/bundler/urls.json
• 🐛 Gemfile で github 指定した gem がアップデートされるとコメントが表示されないバグを修正

.gemspec の対応について

.gemspec の homepage 以外で github.com の URL を探す方法が見つからなかったので、 json ファイルでリンクを管理して対応しました。
もし TachikomaAi を使っている人で、対応 gem を増やしたい人は json にリンクを追加してプルリクください。

github 指定について

vendor/bundle/ruby/2.3.0/bundler/gems/ の下の .gemspec を使えば対応できそうだけど、ちょっと対応に時間かかりそう。
また時間のあるときに対応したい。

これで来週からお仕事での gem のアップデート確認が少し楽になる(∩´∀｀)∩

Swift でトランプを実装しようとして、勉強になってる話

まだ全然実装できていないけど、とても勉強になっているので途中経過をブログに書いてみる。

github.com

なぜやっているのか

トランプくらい簡単に実装できる・・・そう思っていた時期が（ｒｙ

環境

• Swift 3.0-dev on Docker swiftdocker/docker-swift

この環境で勉強を始めたのが間違いだったかもしれない。

やりたいこと

• 汎用的にトランプのゲームを作れるようなライブラリ設計にする
• ポーカー、七並べ、大富豪など、メジャーなゲームを実装する

設計など

• Card が Rank ( 1 〜 13 ) と Suit (スペード、ハート、クラブ、ダイヤ) を持つ
• Card の強弱をゲームによって変える
  • Generics で変更できるようにした
• まだ Jocker は未実装
  • ワイルドカード、最強と効果が変わるので、クラス設計に悩んでいる

Swift で実装方法が分からなかった箇所など

stringLiteralConvertible で特定文字だけ許容したい

let card: Card<DefaultComparing> = "13S"

これで「スペード13」が生成したかった。結局、できなかったので、 init? を使った。

https://github.com/sinsoku/PlayingCard/blob/908faee6fe4fe1d66e028ee481b6ad07c06f4322/Sources/PlayingCard/Card.swift#L14-L33

init?(_ value: String) {
  var characters = value.characters
  let suit = characters.popLast()
  let rank = Int(String(characters))

  guard let rankInt = rank where 1...13 ~= rankInt else {
    return nil
  }

  guard let suitStr = suit where ["S", "H", "C", "D"].contains(suitStr) else {
    return nil
  }

  switch suitStr {
    case "S": self = Card<T>(rank: Rank(rawValue: rankInt)!, suit: .Spade)
    case "H": self = Card<T>(rank: Rank(rawValue: rankInt)!, suit: .Heart)
    case "C": self = Card<T>(rank: Rank(rawValue: rankInt)!, suit: .Club)
    case "D": self = Card<T>(rank: Rank(rawValue: rankInt)!, suit: .Diamond)
    default: return nil
  }
}

無理矢理感がある・・・。
もうちょい綺麗になりそうだけど、よく分からんかったので他の実装を進めている。

戻り値を Set, Array で切り替えたい

https://github.com/sinsoku/PlayingCard/blob/908faee6fe4fe1d66e028ee481b6ad07c06f4322/Sources/PlayingCard/Util.swift

class Util {
    static func factory<C: CardInitializeable>(_ values: String...) -> Set<C> {
      let cards = values.map { C($0)! }
      return Set(cards)
    }
}

戻り値も Generics でうまく返したかったけど、よく分からなかった。

let arrCards: Array<Card<DefaultComparing>> = Util.factory("1S", "2S", "3S", "4S", "5S")
let setCards: Set<Card<DefaultComparing>> = Util.factory("1S", "2S", "3S", "4S", "5S")

本当は ArrayLiteral で定義できると綺麗なんだけど、これ init? だから出来ないんですよね・・・。

let setCards: Set<Card<DefaultComparing>> = ["1S", "2S", "3S", "4S", "5S"]