読者です 読者をやめる 読者になる 読者になる

Forkwell を Rails 5.0.0.1 へアップグレードしました

Ruby on Rails

こんにちは、Forkwell 開発チームの @sinsoku です。

Rails 5.0.0.1, 4.2.7.1, and 3.2.22.3 have been released! で Rails のセキュリティアップグレードが公開されました。
弊社で該当する処理はありませんでしたが、 Rails は上げられるときにアップグレードしておいた方が楽なので、さっさとアップグレードしておきました。

f:id:sinsoku:20160812141826p:plain

今回のアップグレード内容

CVE-2016-6316 を読むと分かるようにXSS脆弱性の対応です。 差分は rails/rails@v5.0.0...v5.0.0.1 を見ると tag_helper の修正だけでした。

# 5.0.0
content_tag('p', "content", title: '"'.html_safe)
#=> <p title=""">content</p>

# 5.0.0.1
content_tag('p', "content", title: '"'.html_safe)
#=> <p title="&quot;">content</p>

html_safe を使う機会は少ないかもしれませんが、使っている方は早めに上げた方が良さそうです。

最速で Forkwell を Rails 5 にアップグレードしてみました

Ruby on Rails

こんにちは、Forkwell 開発チームの @sinsoku です。

本日の Riding Rails: Rails 5.0: Action Cable, API mode, and so much more で Rails 5.0.0 のリリースが告知されました。

f:id:tshotoku:20160701180502p:plain

Rails 5 ではいくつもの新機能・変更点があります。

  • Action Cable
  • Rails API
  • Railsコマンド
  • Turbolinks 5

各機能の詳細については、リリース前から既にいくつも記事が出てますし、そちらを参照ください。

そんな Rails 5 のリリース直後ですが、弊社では早速 Forkwell Jobs をアップグレードして、デプロイしてみました。

いくつかの変更は Rails 4.2.6 でも対応できますので、業務の合間などに少しずつ進めておくのがオススメです。 この記事が皆さんの Rails 5 アップグレードの参考になれば幸いです。

目次

  • Rails 5 へのアップグレード前の環境
  • gem の依存関係を解決する
  • 設定ファイルなどの更新
  • Rails Guide に従って更新
    • Active Record Models Now Inherit from ApplicationRecord by Default
    • Halting Callback Chains via throw(:abort)
    • ActiveJob Now Inherits from ApplicationJob by Default
    • Rails Controller Testing
  • schema.rb の更新
  • ApplicationMailer を継承するように修正
  • Turbolinks v5.0.0 対応
    • Progress bar の表示
    • イベントの変更
    • PhantomJS 1.9.2 対応
  • API の仕様変更への対応
    • [Error] Rails 3 時代の count(:xxx, distinct: true) を削除
    • [Error] Rails 3 時代の mass-assignment の修正
    • [Error] find_by(n) みたいな使い方していたので修正
    • [Error] ActiveRecord::Relation で slice が使えなくなっているので to_a.slice に修正
    • [Error] has_many の collection<<(object...) で select を使用したコードを修正
    • [Error] content_tag_for を使わないように修正
    • [Error] namespace 内の root でメソッドが生成されないので修正
    • [Warning] uniq を distinct に変更
    • [Warning] Controller の envを request.env に修正
    • [Warning] alias_method_chain を Module#prepend に修正
    • [Warning] alias_method_chain を Module#prepend に修正
    • [Warning] db/migrate/*.rb で ActiveRecord::Migration[4.2] を使うように修正
  • RSpec
    • [Warning] HTTP request methods の引数の変更
  • 調べる時間がなかった
    • [Error] routes の helper メソッドの引数の挙動が変
    • [Error] テストでミリ秒まで比較するとテストが落ちる
    • [Error] ActionController::Parameters#slice! がエラー
    • [Error] テストで使用していた params でエラー
    • [Error] ActiveRecord#touch が 2回走る?
    • [Warning] render :text を render :plain に修正
  • あとがき

Rails 5 へのアップグレード前の環境

Ruby: 2.3.1 Rails: 4.2.6

また、他の gem は tachikomatachikoma_ai を使い、毎週アップデートを実施してました。

gem の依存関係を解決する

まず rails 以外の gem を可能な限りアップデートします。

$ bundle update

次に rails をアップグレードします。

$ bundle update rails

エラーが出た gem を1つずつ対応していきます。

  1. beta, pre などのバージョンがないか確認
  2. gem 'rspec', '>= 3.5.0.beta3' などで対応
  3. GitHub の master ブランチが対応していないか確認する
  4. gem 'sinatra', github: 'sinatra/sinatra' のように対応
  5. Issue や Pull Request で対応されていないか確認する
  6. 対応されていれば fork されたリポジトリを使用する
  7. ソースコード読んで自分で直す
  8. プルリクを投げるチャンスですね!

地道に対応すれば、そのうち bundle update できるようになります。

設定ファイルなどの更新

rake app:update を実行し、設定ファイルなどを更新していきます。 ただ、競合したファイルはひとまず skip しておきます。

次に別ディレクトリに rails new app5 のように 5.0.0 で新しいアプリを作成し、 skip したファイルは新しいアプリと比較して、手で直しました。

比較方法の一例として、 vim を使った方法を紹介します。

$ vim -d config/environments/development.rb ~/tmp/app5/config/environments/development.rb

変更内容はアプリによって異なるので、各自で頑張ってください。

ちなみに、弊社では ActionCable はまだ未使用のため、コメントアウトしています。

  • config/application.rb
require "action_controller/railtie"
require "action_mailer/railtie"
require "action_view/railtie"
# require "action_cable/engine"
require "sprockets/railtie"
# require "rails/test_unit/railtie"

Rails Guide に従って更新

upgrading-from-rails-4-2-to-rails-5-0 を見ながら、各項目の対応をしました。

Active Record Models Now Inherit from ApplicationRecord by Default

ActiveRecord::Base を直接継承せず、 ApplicationRecord を継承するように直しました。

$ git grep -l ActiveRecord::Base -- app/models | xargs sed -i '' "s/ActiveRecord::Base/ApplicationRecord/g"

既存ファイルの継承元を sed で修正し、 ApplicationRecord を新規に作成します。

# app/models/application_record.rb
class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true
end

Halting Callback Chains via throw(:abort)

4.2 では before_save などで false を返すと、ROLLBACK されていました。 これが 5.0 では throw(:abort) と明示的に例外を投げる必要があります。

class User
  before_save { false }
  before_save { p 'Hello' } # 4.2 では実行されないが、 5.2 では実行される
end

git grep before_ -- app/models などで該当箇所を調べ、 return falsethrow(:abort) に修正しました。

ActiveJob Now Inherits from ApplicationJob by Default

ActiveJob::Base を直接継承せず、 ApplicationJob を使うようになりました。

$ git grep -l ActiveJob::Base -- app/models | xargs sed -i '' "s/ActiveJob::Base/ApplicationJob/g"

既存ファイルを一斉置換したあとに ApplicationJob を新規作成します。

# app/jobs/application_job.rb
class ApplicationJob < ActiveJob::Base
end

Rails Controller Testing

Rails 5 からコントローラーのテストで assigns などを使う場合は rails-controller-testing の gem が必要になりました。 gem がない状態でテストを実行すると下記のようなエラーが発生します。

Failure/Error: expect(assigns(:user)).to be_a_new(User)
NoMethodError:
  assigns has been extracted to a gem. To continue using it,
          add `gem 'rails-controller-testing'` to your Gemfile.

また、 rails-controller-testing には rails/rails-controller-testing#22 の問題があるため、 require: false にして読み込みを遅延させる必要があります。

# Gemfile
group :test do
  gem 'rails-controller-testing', require: false
end

# spec/rails_helper
RSpec.configure do |config|
  require 'rails-controller-testing'
  [:controller, :view, :request].each do |type|
    config.include ::Rails::Controller::Testing::TestProcess, :type => type
    config.include ::Rails::Controller::Testing::TemplateAssertions, :type => type
    config.include ::Rails::Controller::Testing::Integration, :type => type
  end
end

schema.rb の更新

Rails 5 で schema.rb の形式が変わっているので、更新しました。 一回 rails db:migrate を実行すれば更新されます。

$ rails db:migrate

Rails 5 から rake db:migraterails db:migrate でも実行できるようになっています。

ApplicationMailer を継承するように修正

ApplicationRecord, ApplicationJob と同様に ApplicationMailer になっていたので修正。

$ git grep -l ActionMailer::Base -- app/mailers | xargs sed -i '' "s/ActionMailer::Base/ApplicationMailer/g"

既存ファイルを一斉置換したあとに ApplicationMailer を新規作成します。

# app/mailers/application_mailer.rb
class ApplicationMailer < ActionMailer::Base
  default from: 'from@example.com'
  layout 'mailer'
end

Turbolinks v5.0.0 対応

Progress bar の表示

2.x では Turbolinks.enableProgressBar() を実行していましたが、 5.0.0 ではメソッドが無くなり、デフォルトで ON になっています。

https://github.com/turbolinks/turbolinks/tree/v5.0.0#displaying-progress

色を変える場合は下記のような CSS を用意します。

.turbolinks-progress-bar {
  height: 5px;
  background-color: green;
}

また、プログレスバーを非表示にする場合は visibility: hidden にします。

.turbolinks-progress-bar {
  visibility: hidden;
}

イベントの変更

turbolinks のイベントが変更されているので、対応が必要です。

https://github.com/turbolinks/turbolinks/tree/v5.0.0#full-list-of-events

- $(document).on 'ready page:load', ->
+ $(document).on 'turbolinks:load', ->

よくありがちな ready page:loadturbolinks:load に変更する必要があります。

PhantomJS 1.9.2 対応

PhantomJS 2系だと一部のテストが動かないため、 PhantomJS 1.9.2 を使っていたのですが、 PhantomJS 1.9.2 だと Turbolinks 5.0.0 は動きませんでした。

5.0.0.beta5 までは動いたので、 vender/assets/turbolinks_5_beta5.js を置いて、バージョンを固定して対応しました。

-//= require turbolinks
+//= require turbolinks_5_beta5

ただ、これだと turbolinks をアップデートできなくなるので、早めに PhantomJS をバージョンを上げたい。

API の仕様変更への対応

5.0.0 で API の挙動が色々と変わっていたので、対応しました。 一部、弊社では謎のコード・挙動にも遭遇しましたが、知見の共有として紹介します。

[Error] Rails 3 時代の count(:xxx, distinct: true) を削除

# 4.2.6
User.count(:name, distinct: true)
#   (0.2ms)  SELECT COUNT("users"."name") FROM "users"
#=> 0

# 5.0.0
User.count(:name, distinct: true)
#=> ArgumentError: wrong number of arguments (given 2, expected 0..1)

上記のように、エラーが発生します。 ただ、元のコードでは DISTINCT 効いていません。もしこんなコードを見つけたら、ちゃんと仕様を確認して、修正しましょう。

弊社の場合 使われていないページ でしたので、該当箇所のコードは全て消しました。直す場合は下記の通りです。

# 5.0.0
User.distinct.count(:name)
#   (0.6ms)  SELECT DISTINCT COUNT(DISTINCT "users"."name") FROM "users"
#=> 0

[Error] Rails 3 時代の mass-assignment の修正

# 4.2.6
User.new(params[:user], as: :admin)
#=> <User id: nil, name: "foo", ...

# 5.0.0
User.new(params[:user], as: :admin)
#=> ArgumentError: wrong number of arguments (given 2, expected 0..1)

上記のように、エラーが発生します。 Rails 4 からは Strong Parameters を使うべきなので、修正しましょう。

class UsersController < ApplicationController
  def create
    @user = User.new user_params
  end

  private

  def user_params
    params.require(:user).permit(:name)
  end
end

[Error] find_by(n) みたいな使い方していたので修正

# 4.2.6
User.find_by(1)
#  User Load (0.2ms)  SELECT  "users".* FROM "users" WHERE (1) LIMIT 1
#=> nil

# 5.0.0
User.find_by(1)
# ArgumentError: Unsupported argument type: 1 (Fixnum)

上記のように、エラーが発生します。 弊社の場合、運良く動いていましたがメソッドの使い方が謎なので、仕様を確認して直しましょう。

[Error] ActiveRecord::Relation で slice が使えなくなっているので to_a.slice に修正

# 4.2.6
User.all.slice(0)
#  User Load (1.9ms)  SELECT "users".* FROM "users"
#=> #<User id: 1, ...

# 5.0.0
User.all.slice(0)
#  User Load (1.2ms)  SELECT "users".* FROM "users"
#=> NoMethodError: undefined method `slice' for #<User::ActiveRecord_Relation:0x007fad46c2bcf8>

上記のように、エラーが発生します。 ActiveRecord 周りの仕様が変わったぽい。ひとまず to_a すれば元の挙動を維持できるので、それで対応しました。

# 5.0.0
User.all.to_a.slice(0)
#  User Load (0.1ms)  SELECT "users".* FROM "users"
#=> #<User id: 1, ...

[Error] has_many の collection<<(object...) で select を使用したコードを修正

モデルの構造は下記の通り。

class User < ApplicationRecord
  has_many :posts, through: :bookmarks
  has_many :bookmarks
end
# 4.2.6
u.posts << Post.select(:id)
#  Post Load (0.1ms)  SELECT "posts"."id" FROM "posts"
#   (0.1ms)  begin transaction
#  SQL (0.6ms)  INSERT INTO "bookmarks" ("user_id", "post_id", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["user_id", 1], ["post_id", 1], ["created_at", "2016-06-12 11:49:54.391603"], ["updated_at", "2016-06-12 11:49:54.391603"]]
#  SQL (0.1ms)  INSERT INTO "bookmarks" ("user_id", "post_id", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["user_id", 1], ["post_id", 2], ["created_at", "2016-06-12 11:49:54.401580"], ["updated_at", "2016-06-12 11:49:54.401580"]]
#   (0.9ms)  commit transaction
#  Post Load (0.2ms)  SELECT "posts".* FROM "posts" INNER JOIN "bookmarks" ON "posts"."id" = "bookmarks"."post_id" WHERE "bookmarks"."user_id" = ?  [["user_id", 1]]
#=> #<ActiveRecord::Associations::CollectionProxy [#<Post id: 1>, #<Post id: 2>]>

# 5.0.0
u.posts << Post.select(:id)
#  Post Load (0.1ms)  SELECT "posts"."id" FROM "posts"
#   (0.1ms)  begin transaction
#   (0.1ms)  rollback transaction
#=> ActiveModel::MissingAttributeError: missing attribute: user_id

上記のように、エラーが発生します。 ただ、そもそも元のコードで N+1 が起きていたので、弊社では zdennis/activerecord-import を使って collection<<(object...) を使わない形に修正しました。

[Error] content_tag_for を使わないように修正

<!-- 4.2.6 -->
<table>
  <!-- -->
  <%= content_tag_for(:tr, @user) do %>
    <td><%= @user.name %></td>
  <% end %>
</table>

<!-- 5.0.0 -->
<table>
  <!-- -->
  <%= content_tag_for(:tr, @user) do %>
    <td><%= @user.name %></td>
  <% end %>
</table>
<!--
ActionView::Template::Error (The `content_tag_for` method has been removed from Rails. To continue using it, add the `record_tag_helper` gem to your Gemfile:
  gem 'record_tag_helper', '~> 1.0'
Consult the Rails upgrade guide for details.):
-->

上記のように、エラーが発生します。 メッセージに従ってrecord_tag_helperを入れても良かったのですが、使用箇所も1つでしたので使わないように変更しました。

ちなみに、関連するIssueは↓です。

I remember adding RecordTagHelper as an experiment, but never felt happy with its use in real life. Let's kick it out in a gem and remove it from core. https://github.com/rails/rails/issues/18337

[Error] namespace 内の root でメソッドが生成されないので修正

# 4.2.6
Rails.application.routes.draw do
  root 'top#index'
  namespace :admin do
    root 'top#index'
  end
end
#         root GET    /                             top#index
#   admin_root GET    /admin(.:format)              admin/top#index

# 5.0.0
Rails.application.routes.draw do
  root 'top#index'
  namespace :admin do
    root 'top#index'
  end
end
#         root GET    /                             top#index
#              GET    /admin(.:format)              admin/top#index

上記のように、helper メソッドが生成されなくなります。 as オプションを使用して修正する必要があります。

Rails.application.routes.draw do
  root 'top#index'
  namespace :admin do
    root 'top#index', as: :root
  end
end
#         root GET    /                             top#index
#   admin_root GET    /admin(.:format)              admin/top#index

[Warning] uniq を distinct に変更

# 4.2.6
User.uniq
#  User Load (2.9ms)  SELECT DISTINCT "users".* FROM "users"
#=> #<ActiveRecord::Relation [#<User id: 1, name: nil, created_at: "2016-06-05 13:39:31", updated_at: "2016-06-05 13:39:31">]>

# 5.0.0
User.uniq
#DEPRECATION WARNING: uniq is deprecated and will be removed from Rails 5.1 (use distinct instead). (called from irb_binding at (irb):2)
#  User Load (0.2ms)  SELECT DISTINCT "users".* FROM "users"
#=> #<ActiveRecord::Relation [#<User id: 1, name: nil, created_at: "2016-06-05 13:39:19", updated_at: "2016-06-05 13:39:19">, #<User id: 2, name: nil, created_at: "2016-06-12 11:36:46", updated_at: "2016-06-12 11:36:46">]>

上記のように、警告が発生します。 修正方法は下記の通り。

User.distinct
#  User Load (0.2ms)  SELECT DISTINCT "users".* FROM "users"
#=> #<ActiveRecord::Relation [#<User id: 1, name: nil, created_at: "2016-06-05 13:39:19", updated_at: "2016-06-05 13:39:19">, #<User id: 2, name: nil, created_at: "2016-06-12 11:36:46", updated_at: "2016-06-12 11:36:46">]>

[Warning] Controller の envを request.env に修正

# 4.2.6
env['HTTP_USER_AGENT']
#=> "Mozilla/5.0 (Macintosh; Intel Mac OS X...

# 5.0.0
env['HTTP_USER_AGENT']
DEPRECATION WARNING: env is deprecated and will be removed from Rails 5.1
#=> "Mozilla/5.0 (Macintosh; Intel Mac OS X...

上記のように、警告が発生します。 修正方法は下記の通り。

request.env['HTTP_USER_AGENT']
#=> "Mozilla/5.0 (Macintosh; Intel Mac OS X...

[Warning] alias_method_chain を Module#prepend に修正

サンプルコードは下記の通り。*1

class User < ApplicationRecord
  def say
    puts 'Hello, World'
  end

  def say_with_name
    puts "Hi, #{name}"
    say_without_name
  end
  alias_method_chain :say, :name
end

各バージョンで試した結果は下記の通り。

# 4.2.6
User.new(name: 'sinsoku').say
#=> Hi, sinsoku
#=> Hello, World

# 5.0.0
User.new(name: 'sinsoku').say
#=> DEPRECATION WARNING: alias_method_chain is deprecated. Please, use Module#prepend instead. From module, you can access the original method using super.
#=> Hi, sinsoku
#=> Hello, World

警告メッセージに従い Module#prepend を使う形に修正しました。

class User < ApplicationRecord
  def say
    puts 'Hello, World'
  end
end

module SayWithName
  def say
    puts "Hi, #{name}"
    super
  end
end
User.prepend(SayWithName)

[Warning] db/migrate/*.rb で ActiveRecord::Migration[4.2] を使うように修正

migration のサンプルコード。

class CreateUsers < ActiveRecord::Migration
  def change
    create_table :users do |t|
      t.string :name

      t.timestamps
    end
  end
end

これは 5.0.0 で警告が出る。( rails db:migrate警告は出ませんでしたが、直した方が良さそうなので直しておきました)

追記: id:sue445 さんのコメントの指摘通り log/development.log に WARNING が出ていました。

DEPRECATION WARNING: Directly inheriting from ActiveRecord::Migration is deprecated. Please specify the Rails release the migration was written for:

  class CreateUsers < ActiveRecord::Migration[4.2] (called from require at bin/rails:4)

これは sed で一斉置換して対応しました。

$ git grep -l ActiveRecord::Migration -- db | xargs sed -i '' "s/ActiveRecord::Migration/ActiveRecord::Migration[4.2]/g"

RSpec

[Warning] HTTP request methods の引数の変更

RSpec.describe UsersController, type: :controller do
  describe "GET #show" do
    it "assigns the requested user as @user" do
      user = User.create!
      get :show, id: user.to_param #=> ①
      expect(assigns(:user)).to eq(user)
    end
  end
end

① の行で警告が表示されます。

DEPRECATION WARNING: ActionController::TestCase HTTP request methods will accept only
keyword arguments in future Rails versions.

Examples:

get :show, params: { id: 1 }, session: { user_id: 1 }
process :update, method: :post, params: { id: 1 }

警告メッセージに従って、メソッドの引数を修正しました。

 RSpec.describe UsersController, type: :controller do
   describe "GET #show" do
     it "assigns the requested user as @user" do
       user = User.create!
-      get :show, id: user.to_param
+      get :show, params: { id: user.to_param }
       expect(assigns(:user)).to eq(user)
     end
   end
 end

調べる時間がなかった

4.2.6 と 5.0.0 で比較するのに予想以上に時間かかったので、以下は現象だけ紹介。

(あとで再現できたら、追記します)

[Error] routes の helper メソッドの引数の挙動が変

# /users/:user_name
user_url(user_name, options)

上記のような書き方をしていた箇所がエラーになるケースがありました。

user_url(options.merge(username: user_name))

こんな感じで対応しました。

[Error] テストでミリ秒まで比較するとテストが落ちる

テストで時刻を比較しているテストが落ちていました。

it { expect(job.published_at).to eq now }

byebug で調べてみると、どうもミリ秒の部分が異なるのが理由みたい。 弊社では秒単位の比較で十分だったので、下記のように to_i で対応しました。

it { expect(job.published_at.to_i).to eq now.to_i }

[Error] ActionController::Parameters#slice! がエラー

params[:data].slice! のように書いていた箇所が動かなくなっていたので修正しました。

 def update
-   data = params[:data].slice!
+   data = params[:data].to_h.slice!
    # ...
 end

[Error] テストで使用していた params でエラー

テストで permit せずにアクセスしていたため、エラーになっていました。

it { expect(controller.params[:q].to_unsafe_h.symbolize_keys).to include(freeword: 'keyword') }

テストなので、 to_unsafe_h を使って対応しました。

[Error] ActiveRecord#touch が 2回走る?

Rails の Optimistic Locking を使っているコードで ActiveRecord#touch が2回走るような謎の現象に遭遇しました。

弊社では色々とあって、楽観的ロックを使うコードがなくなり、結果として対応が不要になりました。 ただ、発生原因がよく分からなかったので、アプリで使っている人は気をつけた方が良いかも。

[Warning] render :text を render :plain に修正

DEPRECATION WARNING: `render :text` is deprecated because it does not actually render a `text/plain` response. Switch to `render plain: 'plain text'` to render as `text/plain`, `render html: '<strong>HTML</strong>'` to render as `text/html`, or `render body: 'raw'` to match the deprecated behavior and render with the default Content-Type, which is `text/plain`.

まだ対応できていない。

あとがき

Rails 5 のアップグレード、動作検証、リリース、そして長いブログを書いて、本当に疲れた。ビール飲みたい。

そんな Rails 5 にアップグレードされた Forkwell Jobs で、ぜひ Ruby 求人を検索 してみてください。 あと、テストしているので大丈夫だとは思いますが、変な挙動を見つけたらこっそり教えてください。

*1:実際は Rails やその他 gem にモンキーパッチを当てる場合に使ってました

CSSスタイルガイドを作って良かった話

f:id:ringo_girl:20160516105300p:plain

こんにちは、デザインチームのミヤギ(@_ringogirl)です。

エンジニア目線の求人・転職サイト Forkwell Jobsでは、最近デザインのリニューアルを行いました(最近と言っても3ヶ月前の話ですが…)。 リニューアルに合わせてCSSのリビングスタイルガイドを作ることにしました。

実際に作っているスタイルガイドはここで公開しています

スタイルガイドとは

CSSのドキュメントのようなもので、サイトで使う色やタイポグラフィ、UIパターンなどを記述したものです。 見た目とコードをドキュメントとして読めるので、チームで開発するときの共有に役立ちます。

なぜスタイルガイドを作ったのか

僕が入社したのは約1年前なのですが、その頃からCSSがとっ散らかって肥大化してしまっていたので、CSSを触るのがつらい状況になっていました。 もちろんドキュメントも無かったので、どこにCSSコンポーネントが定義されているのか探さないといけないし、コードを書くまで見た目がわからない、色を定義された変数が多すぎて管理ができない、など様々な問題がありました。 このような状況を解決したかったのと、継続的にCSSをメンテナンスできる環境を作りたくてスタイルガイドを作ることにしました。また、エンジニアがデザインに関することで悩むことが減って、開発速度が上がればいいなという思いもあります。

どうやって作ったのか

f:id:ringo_girl:20160516105412p:plain

HologramというGemを使用して作っています。KSSなど有名なものもありますが、やることが少なくて複雑ではない印象だったのでHologramを選択しています。 技術的なことについては長くなってしまうような気がするので、別の記事で書いていきます。

スタイルガイドの管理方法

プロダクト上で作っていくのではなく、別リポジトリで開発をしています。 npmで管理して、そこからプロダクトに読み込むという方法をとりました。

スタイルガイドを作って良かったこと

コンポーネントのスコープを狭めることができた

プロダクトとスタイルガイドを分離することで、プロダクトのレイアウトなどに左右されないようなコンポーネントを書きやすくなりました。 機能ごとにコンポーネントを定義できるので、スコープが狭くなりメンテナンスしやすくなったと思います。

CSSの管理がしやすくなった

上でも書きましたが、スタイルガイドをnpmで読み込んでいるので管理しやすくなりました。 スタイルガイドの変更がプロダクト側にコミットされないので、コミットログの見通しもよくなった気がします。

エンジニアがある程度は楽できるようになった

まだまだ問題はありますが、以前よりはデザインに関することで悩むことが減ったんじゃないかなと思います。 チーム共通のドキュメントなので、コミュニケーションが取りやすくなった気がします。

新しい技術を学ぶことができた

ES2015やReactなど、スタイルガイドで新しい技術を学ぶことができました。Hologramのプラグインを書いて拡張することも楽しかったです。 肥大化したCSSに継ぎ足していくのはつらかったので、こういったところで楽しみができるのも良かったです。

今後の展望

スタイルガイドの運用は始まりましたが、不便なところや不十分なところがまだまだ多くあり、以下のようなことを考えていたりします。

  • Reactコンポーネントの提供
  • JSのテスト
  • CSSのテスト
  • CSSの再設計
  • 色の選定
  • OSS化

スタイルガイドは、今までの僕らの開発にはなかった仕組みでまだ手探りな部分もありますが、今後も継続して開発していけるように頑張りたいと思います!

Protected branches を使ったデプロイ自動化の始め方

Wercker GitHub

初めまして、エンジニアチームの @app2641 です。
去年の夏に grooves へ入社しました。
今回は旬の新人がブログを書かせて頂きます。

さて、突然ですが皆さんはアプリケーションのデプロイをどのような方法で行っていますか?
Forkwell では master ブランチにプルリクがマージされたら capistrano を使って丹精込めて手作業でデプロイを行うということをやっていました。
ステージング環境で動作確認する際にも似たような方法を取っていて、正直なところこのデプロイ方法はだるいなあと感じていました。
僕のように日々ぽやーと作業している人間にとってはデプロイ先を間違えそうになったり、マージだけしておいてデプロイは明日になってからやろうとか考えて翌日すっかり忘れていたりなど散々なことになります。
そんな事態を避けるためにはどうすればいいか。
そうです、自動化すればいいんです!
機械で出来ることは機械に押し付けよう!

今回は Forkwell でデプロイを自動化した話をしたいと思います。

Wercker からデプロイ出来るようにする

Forkwell では CI に Wercker を使用しています。
Wercker はプライベートリポジトリであっても無料で利用出来て大変便利です。
便利なので今すぐに使いましょう。さあさあ。

wercker.com

wercker.yml の設定

まずは設定ファイルである wercker.yml にデプロイの方法を記述していきます。

deploy:
  steps:
    - script:
      name: mkdir -p $HOME/.ssh
      code: mkdir -p $HOME/.ssh
    - add-ssh-key:
        keyname: FORKWELL_SSH_KEY
    - create-file:
      name: deploy.sh
      filename: $HOME/deploy.sh
      overwrite: true
      content: |-
        set -e
        cd forkwell
        git pull origin master
        bundle install
        bundle exec cap production deploy
    - script:
      name: deploy to production
      code: ssh -o StrictHostKeyChecking=no $FORKWELL_USER@$FORKWELL_IP 'bash -s' < $HOME/deploy.sh

なんとなくやっていることは分かると思います。
Forkwell では踏み台サーバを経由してデプロイを行っているので、一度踏み台サーバへ接続し、そこから capistrano で本番環境へデプロイしています。
サーバを経由せずにデプロイしたいのであれば、

- cap:
  stage: production

と記述するだけで production へデプロイ出来ます。
create-filecap といった項目は steps と呼ばれるファンクションで他にも様々なものがあります。
詳しくは Wercker の ドキュメント を読むと理解が深まるでしょう。

Deploy target と変数の設定

ところで先ほどの wercker.yml の中で FORKWELL_SSH_KEY だとか FORKWELL_USER といった変数があったことに気付いたでしょうか。
Wercker では直接設定ファイルに書きたくない内容を変数として登録しておくことが出来ます。
SSH 鍵だとか AWS のキーなどは Wercker 側に登録しておくのがベターです。

また、テストが通るたび自由にデプロイされてはかなわないのでデプロイするブランチを限定する必要もあります。
そういった細かな設定は Wercker 側で行います。

SSH 鍵の生成

我々のようにどこぞのサーバに SSH してデプロイしたいのであればまずは SSH 鍵を生成しなくてはなりません。
まずは設定画面で SSH keys ページを開きます。
Generate new key pair ボタンから SSH 鍵を生成します。
f:id:app2641:20160301162022p:plain

こんな感じで鍵が生成されます。
生成した鍵は忘れずにデプロイ先のサーバへ登録しておきましょう。
f:id:app2641:20160301162150p:plain

Deploy target の設定

次に Targets ページを開いてデプロイの設定を行います。
Add deploy target というところのドロップダウンメニューから custom deploy を選択します。
f:id:app2641:20160301162221p:plain

適当な名前とデプロイを動かしたいブランチ名を入力して保存すればよいです。
f:id:app2641:20160301162243p:plain

続いて変数の設定です。
変数はテキスト系のものと SSH 鍵と二種類あります。

テキストの場合。
f:id:app2641:20160301162257p:plain

SSH 鍵の場合。
この例でいうと、 SOMETHING_PUBLIC という変数で公開鍵、SOMETHING_PRIVATE で秘密鍵を扱えるようになります。
f:id:app2641:20160301162309p:plain

これで master ブランチのテストが通ったあと自動でデプロイされるようになりました。
なんとも簡単です。

master ブランチへのマージ制約

自動デプロイの運用になると当たり前ですがテストが通ったあとすぐにデプロイが始まってしまいます。
つまりは non fast-forward マージの master ブランチを動作確認せずにデプロイすることがまま有りえるということです。
テストが通っているとはいえマージ後のブランチで動作確認しておかないと夜もおちおち眠れません。
git-flow なんかだと feature ブランチと master ブランチのあいだに develop ブランチを作って運用するのが筋ですが、プルリクを作る回数が増えて手間なので出来ればやりたくありません。
そこで我々のチームは GitHub が提供している protected branches の機能を使うことにしました。
protected branches を使えばテストが通っていないブランチや non fast-forward のブランチはマージ出来なくなります。
non fast-forward を禁止して fast-forward 出来る feature ブランチを動作確認しておけば安心してマージ出来るね、ということです。

設定はチェックボックスをチェックするだけの簡単なクリック業です。
f:id:app2641:20160301162323p:plain

これでテストが通っていても non fast-forward のブランチはマージ出来なくなりました。
しかも GitHub は便利なものでウェブ上で master ブランチを feature ブランチにマージする機能を提供しています。
プルリク画面で Update branch ボタンを押すと勝手にマージ出来る状態にしてくれます。すごいよすごいよー。
f:id:app2641:20160301162335p:plain

余談ではありますが、我々のチームでは GitHub の Deployments API を使ってステージングで動作確認をしたかどうかがプルリク画面で分かるようになっています。
あ、こいつ動作確認してねえなっていうのが分かるので素敵です。

f:id:app2641:20160301162343p:plain

まとめ

そういうわけでようやっと自動でデプロイする仕組みが出来上がりました。
Forkwell では Wercker を使っていますが CircleCI や TravisCI でも同様のことが簡単に出来るはずです。
自動化出来ることはどんどん機械に任せて、人間はコードを書くことに集中したいですね。
がんばっていきましょうー。
それではまた。

リファクタリングコンテスト in Ruby 審査結果発表

Ruby on Rails Refactor Me

f:id:grooves:20160202205843p:plain:w400

大変長らくお待たせしました。Forkwell Jobs にて、2015年11月24日〜12月31日の期間で開催していた【リファクタリングコンテスト in Ruby 】の審査結果がようやく出揃いました。

今回、なんと最もよいコードに贈られる Ruby賞 を1人のユーザーが独占する結果となりました。

気になる審査結果の前に、あらためて審査員をご紹介します。

松田 明 ( @a_matsuda )

f:id:grooves:20160202195645j:plain:w100

Ruby / Rails / Haml / CarrierWave等のコミッター。kaminari / action_args / active_decorator / motorhead 等の作者。
好きな寿司:アナゴ

和田 卓人 ( @t_wada )

f:id:grooves:20160202195656p:plain:w100

タワーズ・クエスト株式会社取締役社長、プログラマ。日本におけるテスト駆動開発(TDD)のスペシャリスト。
好きな寿司:赤貝

藤村 大介 ( @ffu_ )

f:id:grooves:20160202195707j:plain:w100

grooves、Aiming、Quipperなどでリーダー的な活動をしていたプログラマー。RubyとHaskellが得意。フロントエンド開発の実績も豊富。
好きな寿司:コハダ

それでは審査結果の発表です。

Ruby賞

f:id:grooves:20160202195726p:plain:w400

今回 Ruby賞に選ばれたのは、imaz さんの2つの投稿です。
それぞれを見ていきましょう!

和田氏、藤村氏に最も良かったと選ばれたコード

imaz さんの"【Refactor Me】複数の配列の要素を並び替えるコード" をリファクタリングしました

Before

def sort_lists(a, b)
  a.sort!
  b.sort!
  b.size.times do |i|
    a.size.times do |j|
      x, y = a[j], b[i]
      if y < x
        a[j] = y
        b[i] = x
      else
        next
      end
    end
  end
  b.sort!

  [a, b]
end

require 'minitest/autorun'

class TestSortLists < Minitest::Test
  def test_sort_lists
    data = ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h'].shuffle
    assert_equal([['a', 'b', 'c', 'd'], ['e', 'f', 'g', 'h']], sort_lists(data[0..3], data[4..7]))
  end
end

After

def sort_lists(a, b)
  c = [a, b].flatten.sort!

  [c.shift(a.length), c.shift(b.length)]
end

require 'minitest/autorun'

class TestSortLists < Minitest::Test
  def test_sort_lists
    data = ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h'].shuffle
    assert_equal([['a', 'b', 'c', 'd'], ['e', 'f', 'g', 'h']], sort_lists(data[0..3], data[4..7]))
  end 

  def test_sort_lists_for_different_size_lists
    data = ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h'].shuffle
    assert_equal([['a', 'b', 'c'], ['d', 'e', 'f', 'g', 'h']], sort_lists(data[0..2], data[3..7]))
  end 
end

和田氏 コメント

「複数の配列の要素を並び替えるコード」に挑戦された方は何人かいらっしゃいましたが、
この回答は「簡潔に書ける」という Ruby の特色が遺憾なく発揮されており、
リファクタリング前のコードと比べて著しく可読性が改善されている点が印象に残りました。

ひとつ気になるのは、リファクタリング前の実装には存在していた副作用がなくなっている点です。
リファクタリング前のコードでソートされるのは戻り値だけでなく、引数に渡した配列も破壊的にソートされます。

リファクタリングで大事なのは「外部から見た振る舞いを変えずに、内部を改善する」ことなのですが、
この副作用は、はたして外部から見た振る舞いでしょうか?

今回は、引数に及ぼす副作用は、意図していないものであろうと判断しました。
理由は、リファクタリング前のテストに引数の副作用に関するテストが無いためです。
テストに書いていないということは、副作用は意図したものでない、という判断です。
テストが書かれている場合は、意図の有無を調べる材料として既存のテストを使い、
機能互換性に関する判断を行うことができます。
(このあたりの設計判断も回答に書かれているとなお良かったと思います)

などなど、様々な意味で、この投稿は印象に残りました。

藤村氏 コメント

Array#shift で副作用を起こしながら結果の配列を作るという、不変性とは何だったのか的なコードでテンションが上がりました。
トリッキーだと感じる人もいるかもしれませんが、僕は簡潔で読みやすいコードだと思います。ということであまり指摘するところが無いんですが、強いて言えばcという変数名はa、bの次にあるものを連想させてミスリーディングかもしれないので、sortedとかにするといいかなあと。

松田氏に最も良かったと選ばれたコード

imaz さんの"【Refactor Me】Controllerをスッキリさせたい" をリファクタリング

Before

class SessionsController < ApplicationController
  def signin
    @user = User.find_by(email: params[:email])

    if BCrypt::Password.new(@user.password_digest) == params[:password]
      self.current_user = @user
      redirect_to root_path
    else
      flash[:alert] = "Login failed."
      render :new
    end
  end
end

After

# app/controllers/sessions_controller.rb
class SessionsController < ApplicationController
  def signin(email, password)
    @user = User.find_by(email: email)

    if @user.authenticate(password)
      self.current_user = @user
      redirect_to root_path
    else
      flash.now[:alert] = "Login failed."
      render :new
    end
  end
end

# app/models/user.rb
class User < ActiveRecord::Base
  has_secure_password validations: false
end

松田氏 コメント

バグを出さないおそらく唯一の方法は、プログラムを自分で書かないことです。
特にチームでのアプリケーション開発では、フレームワークやライブラリの機能を理解してうまく使いこなして自前で実装するコードを減らすスキルはとても重要です。
この投稿のAfterのコードは誰がどう読んでもなんの面白みもヒネリもない平凡すぎるコードなんですが、チームメンバーから見るとそんなコードが一番尊いのではないでしょうか。
なお、敢えてツッコミどころを探すなら、User.find_by(email: email)find_by! にしておかないとヌルポの可能性がありそうですね。

imaz さんには、回らないお寿司券として使えるギフト券をプレゼントいたします。

審査員特別賞

f:id:grooves:20160202195746p:plain:w500

松田賞

joker1007 さんの パラメーター引数のクラス化とActiveSupport::Concernによるモジュール化

Before

# app/models/pasokara.rb
class Pasokara < ActiveRecord::Base
  validates_presence_of :title, :fullpath, :md5_hash
  validates_uniqueness_of :md5_hash

  include SimpleTaggable

  searchable do
    text :title, stored: true
    string :title_sort do
      title
    end
    string :tags, multiple: true, stored: true do
      tags.map(&:name)
    end
    string :nico_vid, stored: true
    integer :nico_view_count, trie: true
    integer :nico_mylist_count, trie: true
    text :nico_description, stored: true
    time :nico_posted_at, trie: true
    integer :duration, trie: true
  end

  class << self
    def all_with_facet_tags(page: 1, per_page: 100)
      search(include: [:tags]) do
        facet :tags
        paginate page: page, per_page: per_page
      end
    end
  end

  paginates_per 100

  include CreateMethods
  
  # 省略...
end

After

# app/models/pasokara.rb
class Pasokara < ActiveRecord::Base
  validates_presence_of :title, :fullpath, :md5_hash
  validates_uniqueness_of :md5_hash

  include SimpleTaggable
  include Searching

  paginates_per 100

  include CreateMethods

  # 省略...
end

# app/models/pasokara/searching.rb
module Pasokara::Searching
  extend ActiveSupport::Concern

  included do
    searchable do
      text :title, stored: true
      string :title_sort do
        title
      end
      string :tags, multiple: true, stored: true do
        tags.map(&:name)
      end
      string :nico_vid, stored: true
      integer :nico_view_count, trie: true
      integer :nico_mylist_count, trie: true
      text :nico_description, stored: true
      time :nico_posted_at, trie: true
      integer :duration, trie: true
    end
  end

  class SearchParameter
    attr_reader :keyword, :tags, :page, :per_page
    def initialize(keyword: nil, tags: nil, page: 1, per_page: 100)
      @keyword = keyword
      @tags = tags || []
      @page = page || 1
      @per_page = per_page.to_i
      freeze
    end
  end

  module ClassMethods
    def search_with_facet_tags(search_parameter)
      search(include: [:tags]) do
        fulltext search_parameter.keyword if search_parameter.keyword.present?
        search_parameter.tags.each do |tag_name|
          with(:tags, tag_name)
        end
        facet :tags
        paginate page: search_parameter.page, per_page: search_parameter.per_page
      end
    end
  end
end

松田氏 コメント

何か特別すごいテクニックが使われているわけでもないんですが、生々しくて実践的な感じがよいですね。
Searchingというモジュール名は、「検索」という意味だろうとは思いますが、現在進行形だと「探してる」みたいなニュアンスになってしまって違和感があります。
Search(検索)、Searcher(検索するやつ)、Sarchable(検索できるやつ)ぐらいでしょうか。

和田賞、藤村賞

kenchan さんの【Refactor Me】if else のテストを書いてリファクタリング

before

0 <= age or raise

if 0 <= age && age <= 2
  'baby'
elsif 3 <= age && age <= 6
  'little child'
elsif 7 <= age && age <= 12
  'child'
elsif 13 <= age && age <= 18
  'youth'
else
  'adult'
end

after

require 'test/unit'

class TimeOfLife
  attr_reader :label, :min_age, :max_age

  def initialize(label, min_age, max_age)
    @label, @min_age, @max_age = label, min_age, max_age
  end

  def include?(age)
   (@min_age..@max_age) === age
  end
end

TIME_OF_LIFES = [
  TimeOfLife.new('baby', 0, 2),
  TimeOfLife.new('little child', 3, 6),
  TimeOfLife.new('child', 7, 12),
  TimeOfLife.new('youth', 13, 18),
  TimeOfLife.new('adult', 19, Float::INFINITY)
].freeze

def age_to_label(age)
  tol = TIME_OF_LIFES.find {|t| t.include?(age) }

  tol&.label || raise
end

class MyTest < Test::Unit::TestCase
  def test_negative_age
    assert_raise do
      age_to_label(-1)
    end
  end

  def test_baby_min
    assert_equal('baby', age_to_label(0))
  end

  def test_baby_max
    assert_equal('baby', age_to_label(2))
  end

  def test_little_child_min
    assert_equal('little child', age_to_label(3))
  end

  def test_little_child_max
    assert_equal('little child', age_to_label(6))
  end

  def test_child_min
    assert_equal('child', age_to_label(7))
  end

  def test_child_max
    assert_equal('child', age_to_label(12))
  end

  def test_youth_min
    assert_equal('youth', age_to_label(13))
  end

  def test_youth_max
    assert_equal('youth', age_to_label(18))
  end

  def test_adult
    assert_equal('adult', age_to_label(19))
  end

  def test_immortality
    assert_equal('adult', age_to_label(200))
  end

  def test_float
    assert_equal('baby', age_to_label(0.1))
  end
end

和田氏 コメント

この投稿が良かったのは、レガシーコードのリファクタリングの過程を公開している点です。
ここで言う「レガシーコード」とは、テストコードが書かれていないコードのことです。
https://github.com/kenchan/forkwell-jobs-sushi-contest-2015

リファクタリングは、小さく安全なステップで対象のコードを段階的に綺麗にしていくプロセスです。
安全なステップの「安全」を支えるのはテストです。
そして、レガシーコードはテストが書かれてこなかった故に、テストが書きにくい、
あるいはそのままではテストが書けない構造になっていることが多々あります。

つまりリファクタリングにはテストが必要だが、テストを書くためにはリファクタリング(構造変更)が必要、という一種のデッドロックに陥ります。このデッドロックに直面したとき、私たちは

  • テストを書けるようになるまでテスト無しで構造変更するか
  • 構造変更を伴わず強引に大外からテストする

という二つの道のどちらかを選択します。 kenchan さんの選んだ道は前者で、
それは対象コードが十分に小さいから、という判断も働いたのでしょう。
github に公開されている履歴を辿っていくと

  1. テストが書けない構造をテスト可能にするために最小限の変更を行う
  2. 小さなテスト基盤を整えてテストを必要なだけ記述
  3. そのテストを通しながら内部を改善する
  4. 安全圏に達したら、必要に応じて段階的に対象コードの(外部も含め)構造変更を行う

というレガシーコード改善の王道とも言える進め方をしている点が印象に残りました。

藤村氏 コメント

ベタ書きだった処理が、適切な範囲の責務を持つクラスに切り分けられていく。
小さな例ですがオブジェクト指向リファクタリングのあるべき姿を示していると感じました!
それでいて冗長になっていないのが個人的に非常に好みです。

僕だったら{ Range: Label }Hashをlookupして終わりにしちゃうところですが、このくらい簡潔に書けるならクラスにしてもいいなあと。
指摘するとしたら、TimeOfLifeはLifeStageのほうが通りがよさそう。

松田氏 コメント

※同氏はこちらのコードを次点としておりましたが、その選出時のコメントを掲載しています。

1つぐらいはRubyの新機能を活用したものを採りたかったのでこれを選びました。
この内容ならクラスを作るまでもないだろうという意見もありそうですが、そのあたりは敢えてそういう設計を選んだようですし、そういった方向性も含めて、全体的な仕事の丁寧さに好感が持てます。
コミットログをしたためてくれたのは素晴らしいんですが、日本語コミットはちょっと読む気しないのでプラマイゼロ。
lifeの複数形はlivesなような気がするのでそのあたりが減点対象で、そもそもそういう紛れがありそうな名前を避けるのもスキルのうちかもしれません。

特別賞

今回、Ruby賞、審査員賞それぞれで審査員の意見が一致しましたので、特別にもう一つ賞をご用意しました。
特別賞に選ばれたのは、teruki.shinohara さんの ブロックを使って、繰り返し使うコードをメソッドに切り出すです。

※商品は審査員特別賞と同じものを贈呈いたします。

before

# fbのfeedを全て取得する
def get_fb_feeds(fb_api_client)
  option = {iam: 'fb'}
  response = fb_api_client.get_feeds(option)
  fb_feeds = response

  until response.empty?
    option[:max_id] = response.last.id
    response = fb_api_client.get_feeds(option)
    fb_feeds += response
  end

  fb_feeds.flatten
end

# twのtweetを全て取得する
def get_tw_tweets(tw_api_client)
  option = {iam: 'tw'}
  response = tw_api_client.get_tweets(option)
  tw_tweets = response

  until response.empty?
    option[:from_id] = response.last.id
    response = tw_api_client.get_tweets(option)
    tw_tweets += response
  end

  tw_tweets.flatten
end

after

def paginate(&block)
  response = yield(nil)
  sns_posts = response

  until response.empty?
    response = yield(response)
    sns_posts += response
  end

  sns_posts.flatten
end

# fbのfeedを全て取得する
def get_fb_feeds(fb_api_client)
  option = {iam: 'fb'}
  paginate do |response|
    option[:max_id] = response.last.id unless response.nil?
    fb_api_client.get_feeds(option)
  end
end

# twのtweetを全て取得する
def get_tw_tweets(tw_api_client)
  option = {iam: 'tw'}
  paginate do |response|
    option[:from_id] = response.last.id unless response.nil?
    tw_api_client.get_tweets(option)
  end
end

藤村氏 コメント

僕も同じようなコードを半年前に書いたので懐かしい思いで見させて頂きました。繰り返し処理の抽象化により、コードがあるべき方向に進んでいると感じました。
paginate の実態は繰り返し処理をして値を返すメソッドなので、paginate(ページを付ける)だとミスマッチかも。
APIリクエストを発行する Client をデータソースとする Enumerator を定義して、それによるストリーム処理にするとよさそうです。

例えば SnsPostsEnumerator.new(FacebookClient.new).each.all という風に書けると、馴染みがよくなりそうです。
オーバーデザインだ!と言われる気もしますが。

プログラムはチームで開発している事が多いので、このように議論のスタートになるリファクタリングはとても価値が高いと個人的には思っています。コードレビューを通して完成形に近づけばよいので。

joker1007 さん、kenchan さん、teruki.shinohara さんには、ネスカフェコーヒーメーカーをプレゼントします。

参加賞

f:id:grooves:20160202195828p:plain:w500

コードをきれいにするアレを手に入れたのはこちらの3名です

  • hanachin_
  • yancya
  • 5t111111

すべての受賞者には、Forkwellより個別にご連絡させていただきます。

多くのご参加、誠にありがとうございました!


Forkwell Jobs では、IT 開発者が主役となって活躍できる会社を増やし、そんな会社と開発者が出会うきっかけを創造したいと考えています。
そのために、開発環境をしっかりと整備し、公開できる会社の求人だけを厳選して掲載しています。

Ruby が(きちんと)使える環境に転職したいとお考えの方は、ぜひ Forkwell Jobs をご活用ください!

jobs.forkwell.com

Rails で cancancan と action_args の2つの gem を共存して使う方法

Ruby on Rails

こんにちは、Forkwell 事業部の正徳です。

タイトルにもあるように、Forkwell Jobs の開発では cancancanaction_args の2つの gem を使用しています。この2つの gem を一緒に使う際に問題が起きましたので「問題の紹介」と「解決するコード」を紹介したいと思います。

各 gem の簡単な紹介

知らない方もいると思いますので、各 gem の概要を書いておきます。

cancancan

コードの各所に散らばりがちな権限を Ability という1つのファイルで管理できるようになります。

# app/models/ability.rb
class Ability
  include CanCan::Ability

  def initialize(user)
    user ||= User.new # guest user (not logged in)
    if user.admin?
      can :manage, :all
    else
      can :read, :all
    end
  end
end

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  load_and_authorize_resource

  def create
    if @user.save
      # do something
    else
      render :new
    end
  end

  private

  def user_params
    params.require(:user).permit(:name, :age)
  end
end

action_args

コントローラーで使用する値を引数に定義することで、 params を使わずにコードを書けるようになります。

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  # white-lists User model's attributes
  permits :name, :age

  # the given `user` parameter would be automatically permitted by ActionArgs
  def create(user)
    @user = User.new(user)
  end
end

2つの gem を使うときの問題点

前述したコードからも分かるように、それぞれの gem で Strong Parameters に対応する方法が異なります。このため、両方のいいとこ取りをするような下記のコードはエラーになってしまいます。

class UsersController < ApplicationController
  load_and_authorize_resource

  permits :name, :age

  def create
    if @user.save
      # do something
    else
      render :new
    end
  end

  def update(user)
    if @user.update(user)
      # do something
    else
      render :edit
    end
  end
end

こんなコードが書けるようにしたいですよね!というわけで、共存させるようなコードを書きました。

コード

# refs
# https://github.com/CanCanCommunity/cancancan/blob/v1.13.1/lib/cancan/controller_resource.rb#L79
# https://github.com/asakusarb/action_args/blob/v2.0.0/lib/action_args/params_handler.rb#L45
module CanCan
  module ActionArgsEx
    def permits(*attributes)
      super
      UsingActionArgs.include_once(self)
    end
  end

  module UsingActionArgs
    def self.included(klass)
      klass.singleton_class.prepend(ActionArgsEx)
    end

    def self.include_once(klass)
      method_name = "#{klass.controller_name.singularize}_params".to_sym
      return if respond_to?(method_name)

      m = Module.new do
        define_method method_name do
          model_name = klass.instance_variable_get(:@permitting_model_name)
          permitted_attributes = klass.instance_variable_get(:@permitted_attributes)
          key = (model_name || klass.controller_name).singularize.underscore.to_sym
          params[key].permit(*permitted_attributes)
        end
      end
      klass.include(m)
    end
  end
end

Ruby のメタプログラミング力が上がりそうなコードですね!この Module がやっている概要は下記の通りです。

  1. include したクラスの self.permits を上書きする
  2. permits が呼ばれたら、一度だけ 3. 以降の処理を実行する
  3. コントローラーのクラス名から xxx_params というメソッド名を作る
  4. xxx_params のメソッドを持つ Module を動的に生成し、コントローラーで include する

これにより、 load_and_authorize_resourcexxx_params のメソッドを呼び出すことができるため、エラーが起きなくなります。

ちなみに、使い方はコントローラーで include するだけです。

class UsersController < ApplicationController
  include CanCan::UsingActionArgs

  load_and_authorize_resource

  permits :name, :age

  def create
    if @user.save
      # do something
    else
      render :new
    end
  end

  def update(user)
    if @user.update(user)
      # do something
    else
      render :edit
    end
  end
end

cancancan と action_args という2つの gem を組み合わせて使う際の解決方法をご紹介しましたが、いかがだったでしょうか?

このコードが cancancan と action_args を両方とも使っている Rails プロジェクトの役に立てば幸いです。

【RubyKaigi応援企画】リファクタリングコンテスト期間延長のお知らせ & お題 第2弾を用意しました

Refactor Me

明日から待ちに待った RubyKaigi ですね!

f:id:app2641:20151210150536p:plain

Forkwell Jobs では RubyKaigi 2015 応援企画 として回らないお寿司が食べられる リファクタリングコンテスト を開催しています。

https://jobs.forkwell.com/campaigns/rubykaigi-2015

前回の投稿 では、投稿するネタが見つからないという方に向けてリファクタリングのお題をご用意させて頂きました。

このお題をきっかけに、投稿が少しずつ増えてきましたので、
それならばと、さらに五つのお題をご用意しました。

今回も曲者揃いのコード達です。
優秀作品に選ばれる、それはすなわち豪華審査員があなたのリファクタリングスキルにお墨付きを与えたようなもの!
是非挑戦してみてください。

重要なお知らせ

さて、ここでリファクタリングコンテストに関してお知らせがあります。
タイトルにもあるように RubyKaigi 2015 応援企画と銘打って開催してきたリファクタリングコンテストを年末まで期間を延長することが決定致しました。

変更後の募集締め切り: 2015 年 12 月 31 日

皆様からの投稿が社内でも好評で(期間内に投稿いただきありがとうございます!)、このまま終わらせてしまうのはどうにも勿体無い!という想いからです。
Forkwell Jobs は RubyKaigi だけでなく Ruby のコミュニティ全体を応援しているんですから少しくらい良いですよね?

リファクタリングの投稿は 2015 年 12 月 31 日いっぱいまで受け付けています。
ひとり何回でも投稿可能です。どんどんご応募ください。
年末といえば大掃除。一年の間で汚れてしまったあなたのそのコードもリファクタリングして綺麗さっぱりにして新しい年を迎えてみませんか?
そのままリファクタリングコンテストに投稿して美味しいお寿司(あるいはあのお肉やあの蟹やあのディナーなどなど)をゲットしましょうー。

ご応募お待ちしております!