Web開発
主にRailsを使用しサービスを構築していきます。UXを考えたデザインも得意なのでフロントエンドも任せて下さい。
ホームページ作成
売り上げに貢献するサイトを作ります。古いデザインの改修、新機能の導入、WordPressを使用し作成することも可能です。
プログラミング
プロジェクトへの短期参加、業務委託OKです。0からの開発が得意ですが、大規模なプロジェクトへの参加も可能です。
Blog
開発ブログ
準備中
subtitle lorem ipsum dolor sit amet consectetur.
Use this area to describe your project. Markdown supported.
optional info list (delete if not using):
実装以前は、編集フォームに遷移して順番(position
)カラムの整数値をセレクトフィールドで選択して更新していました。
また、自動連番処理はモデル側でしてました。
知識を整理するため簡単なアプリ上に作ってみようと思います。
acts_as_list
を使用した経緯
SortableJS
を使用した経緯
handle
で制御出来るposition
)カラムの追加今回はMenu
モデルにposition
カラムを追加する形で作っていきます
class AddPositionToMenu < ActiveRecord::Migration[6.1]
def change
add_column :menus, :position, :integer, null: false, default: 0
add_index :menus, :position # ここちょっと怖い
end
end
※ ここでindexにunique
を設定するとacts_as_list
の仕様で順番を更新できなくなります。
gem "acts_as_list"
bundle install
する
acts_as_list
を記述するclass Menu < ApplicationRecord
acts_as_list
validates :title, presence: true, length: { maximum: 50 } validates :title, presence: true, length: { maximum: 50 }
ajax処理が書きやすい(慣れている)ため導入します
yarn add jquery
jqueryの初期化
config/webpack/environment.js
const { environment } = require('@rails/webpacker')
// jqueryの設定
const webpack = require('webpack')
environment.plugins.prepend('Provide',
new webpack.ProvidePlugin({
$: 'jquery/src/jquery',
jQuery: 'jquery/src/jquery'
})
)
module.exports = environment
導入
yarn add sortablejs
view設定
id: js-sortable-menus
内をソートの範囲
class: i.handle
をドラッグ&ドロップのトリガーにする
app/views/menus/index.html.haml
%tbody#js-sortable-menus
- @menus.each do |menu|
%tr
%td
%i.handle
.fa.fa-list-ul
%td= menu.title
app/javascript/packs/views/menus/index.js
import Sortable from 'sortablejs';
$(function() {
const el = document.getElementById('js-sortable-menus');
new Sortable(el, {
handle: "i.handle",
axis: 'y',
animation: 300,
onUpdate: function (evt) {
return $.ajax({
url: `/api/menu/positions/${evt.oldIndex}`,
type: 'patch',
data: {
from: evt.oldIndex,
to: evt.newIndex
}
});
}
});
});
handle:
でトリガーになる要素を設定
oldIndex
は移動前の画面上の順番(0から始まる)
newIndex
は移動後の画面上の順番(0から始まる)
Rails.application.routes.draw do
root to: "static_pages#index"
resources :menus
namespace :api do
namespace :menu do
resources :positions, only: [:update]
end
end
end
app/controllers/api/menu/positions_controller.rb
class Api::Menu::PositionsController < ApplicationController
skip_before_action :verify_authenticity_token
def update
menu = Menu.find_by!(position: params[:from].to_i + 1) # 0から始まるので+1する
menu.update!(position: params[:to].to_i + 1) # 0から始まるので+1する
head :ok
end
end
` skip_before_action :verify_authenticity_tokenで
CSRF トークン`の検証をスキップする
app/models/menu.rb
scope :sorted, -> { order(position: :asc) }
app/controllers/menus_controller.rb
# GET /menus or /menus.json
def index
@menus = Menu.sorted
end
app/views/menus/index.html.haml
順番を並び替えるviewにjs
ファイルを読み込ませる
= javascript_pack_tag "views/menus/index", "data-turbolinks-track": "reload"
%h1 Listing menus
%table
%thead
%tr
%th
%th Title
%th Price
%th
%th
%th
%tbody#js-sortable-menus
- @menus.each do |menu|
%tr
%td
%i.handle
.fa.fa-list-ul
%td= menu.title
%td= menu.price
%td= link_to "Show", menu
%td= link_to "Edit", edit_menu_path(menu)
%td= link_to "Destroy", menu, method: :delete, data: { confirm: "Are you sure?" }
%br
= link_to "New Menu", new_menu_path
subtitle lorem ipsum dolor sit amet consectetur.
Use this area to describe your project. Markdown supported.
optional info list (delete if not using):
RSpecが導入済みかつ
spec/rails_helper.rb
にsupport
ディレクトリ配下のファイルを読み込ませるコードが書いてある
Dir[Rails.root.join("spec/support/**/*.rb")].sort.each {|f| require f }
詳細はRSPECの導入
gem "factory_bot_rails"
を追加するbundle
rails g
実行時にFactoryBotを自動生成するコードを記述するg.fixture_replacement :factory_bot, dir: "spec/factories"
4. spec/support/factory_bot.rbを作成
RSpec.configure do |config|
config.include FactoryBot::Syntax::Methods
config.before :all do
FactoryBot.reload
end
end
RSpecが導入済みかつ
spec/rails_helper.rb
にsupport
ディレクトリ配下のファイルを読み込ませるコードが書いてある
Dir[Rails.root.join("spec/support/**/*.rb")].sort.each {|f| require f }
詳細はRSPECの導入
gem "database_rewinder"
を追加するbundle
RSpec.configure do |config|
config.before :suite do
DatabaseRewinder.clean_all
end
config.after do
DatabaseRewinder.clean
end
end
git co -b develop
git push -u origin develop
git co -b release
git push -u origin release
# Ignore encrypted secrets key file.
config/secrets.yml.key
develop
に変更git push -f
を禁止するgit push -f
を禁止するgit push -f
を禁止するgit push -f
を禁止するpre-pushファイルを作成する
$ cd .git/hooks
$ vim pre-push
#!/bin/bash
unpush_branches=("master" "develop" "release")
while read local_ref local_sha1 remote_ref remote_sha1
do
for unpush_branch in ${unpush_branches[@]}
do
if [[ "${remote_ref##refs/heads/}" = $unpush_branch ]]; then
echo "Do not push to ${unpush_branch} branch!!!"
exit 1
fi
done
done
chmod 755 pre-push
プロジェクトのrootファルダに.github
フォルダを作成
PULL_REQUEST_TEMPLATE.md
ファイルを作成
<!-- あくまでテンプレートなので必ずしもすべての項目を埋めなくてよい -->
# 概要
# Issue
- FIX #
# 実装課題
- [ ]
# 技術的な実装詳細
-
# 新規ライブラリ導入の理由(メリット)・背景・ドキュメント等
-
# リリース時の注意点
-
# UI変更
## 変更前のキャプチャ
## 変更後のキャプチャ
## 動きがある場合(GIF動画など)
# その他・備考
-
ISSUE_TEMPLATE
フォルダを作成markdownファイルの先頭行に
name
,about
を書かないとGithubでIssueを作るとき認識しないので注意!
bug.md
ファイルを作成---
name: バグ報告
about: 不具合、バグの報告
---
<!-- 不具合のテンプレート -->
# 概要
# 再現手順
# 修正しないとどう困るか
# 原因
# 修正案
task.md
ファイルを作成---
name: タスク
about: タスクの整理と内容を記す
---
<!-- あくまでテンプレートなので必ずしもすべての項目を埋めなくてよい -->
<!-- 要望のテンプレート -->
# 概要
# 目的
# 提案内容
# タスク
- 細かいタスクに分解できているなら書き出す
リリース時に develop
から master
へマージするとき、
git-pr-release
を用いると、自動でわかりやすいPullRequest
を作ってくれます。
今回はdevelop
ブランチにマージされたPRリストを出力するものを作ります
gemfile
のdevelopment
にgit-pr-release
を追加 group :development do
## ↓追加
gem "git-pr-release", require: false
end
.git-pr-release
を追加[pr-release "branch"]
production = master
staging = develop
[pr-release]
template = .pr-release.template.erb
labels = pr_release
.pr-release.template.erb
を追加## Pull Requests
<% pull_requests.each do |pr| -%>
- <%= "#{pr.pr[:title]} ([##{pr.pr[:number]}](#{pr.html_link}))" %>
<% end -%>
$ bundle exec git-pr-release
※ 初めて実行するとGithub名とパスと2段階コードの入力がありますRubyのコードがコーディング規約に沿っているかを確認できる「静的コード解析ツール(コーディングチェックツール)」
よく使用する設定をまとめてみました。
gem "rubocop-rails"
を追加する
設定ファイルはconfig/rubocop/**.yml
のように作っていく
# 自動生成されるものはチェック対象から除外する
AllCops:
Exclude:
- "node_modules/**/*" # rubocop config/default.yml
- "vendor/**/*" # rubocop config/default.yml
- "db/schema.rb"
#################### Layout ################################
# メソッドをグループ分けして書き順を揃えておくと読みやすくなる。
# 多少のツラミはあるかもしれない。
# TODO: Categories を調整することで
# https://github.com/pocke/rubocop-rails-order_model_declarative_methods
# を再現できそう。
Layout/ClassStructure:
Enabled: true
# メソッドチェーンの改行は末尾に . を入れる
# * REPL に貼り付けた際の暴発を防ぐため
# * 途中にコメントをはさむことができて実用上圧倒的に便利
Layout/DotPosition:
EnforcedStyle: trailing
# 桁揃えが綺麗にならないことが多いので migration は除外
Layout/ExtraSpacing:
Exclude:
- "db/migrate/*.rb"
# special_inside_parentheses (default) と比べて
# * 横に長くなりづらい
# * メソッド名の長さが変わったときに diff が少ない
Layout/FirstArrayElementIndentation:
EnforcedStyle: consistent
# ({ と hash を開始した場合に ( の位置にインデントさせる
# そもそも {} が必要ない可能性が高いが Style/BracesAroundHashParameters はチェックしないことにしたので
Layout/FirstHashElementIndentation:
EnforcedStyle: consistent
# private/protected は一段深くインデントする
Layout/IndentationConsistency:
EnforcedStyle: indented_internal_methods
# メソッドチェーン感がより感じられるインデントにする
Layout/MultilineMethodCallIndentation:
EnforcedStyle: indented_relative_to_receiver
# {} は 1 行で書くときに主に使われるので、スペースよりも
# 横に長くならない方が嬉しさが多い。
# そもそも {| のスタイルの方が一般的だったと認識している。
Layout/SpaceInsideBlockBraces:
SpaceBeforeBlockParameters: false
#################### Lint ##################################
# spec 内では
# expect { subject }.to change { foo }
# という書き方をよく行うので () を省略したい。
# { foo } は明らかに change に紐付く。
Lint/AmbiguousBlockAssociation:
Exclude:
- "spec/**/*_spec.rb"
# Style/EmptyCaseCondition と同じく網羅の表現力が empty when を認めた方が高いし、
# 頻出する対象を最初の when で撥ねるのはパフォーマンス向上で頻出する。
# また、
# case foo
# when 42
# # nop
# when 1..100
# ...
# end
# と、下の when がキャッチしてしまう場合等に対応していない。
# See. http://tech.sideci.com/entry/2016/11/01/105900
Lint/EmptyWhen:
Enabled: false
# RuntimeError は「特定の Error を定義できない場合」なので、
# 定義できるエラーは RuntimeError ではなく StandardError を継承する。
Lint/InheritException:
EnforcedStyle: standard_error
# * 同名のメソッドがある場合にローカル変数に `_` を付ける
# * 一時変数として `_` を付ける
# というテクニックは頻出する
Lint/UnderscorePrefixedVariableName:
Enabled: false
# 子クラスで実装させるつもりで中身が
# raise NotImplementedError
# のみのメソッドが引っかかるので。
# (raise せずに中身が空だと IgnoreEmptyMethods でセーフ)
Lint/UnusedMethodArgument:
Enabled: false
# select 以外では引っかからないと思うので
# mutating_methods のチェックを有効に。
# TODO: select は引数が無い (ブロックのみ) の場合にだけチェックする
# ようにすると誤検知がほぼ無くなる?
Lint/Void:
CheckForMethodsWithNoSideEffects: true
#################### Metrics ###############################
# 30 まではギリギリ許せる範囲だったけど
# リリースごとに 3 ずつぐらい下げていきます。20 まで下げたい。
Metrics/AbcSize:
Max: 24
# Gemfile, Guardfile は DSL 的で基本的に複雑にはならないので除外
# rake, rspec, environments, routes は巨大な block 不可避なので除外
# TODO: ExcludedMethods の精査
Metrics/BlockLength:
Exclude:
- "Rakefile"
- "**/*.rake"
- "spec/**/*.rb"
- "Gemfile"
- "Guardfile"
- "config/environments/*.rb"
- "config/routes.rb"
- "config/routes/**/*.rb"
- "*.gemspec"
# 6 は強すぎるので緩める
Metrics/CyclomaticComplexity:
Max: 10
# * 警告 120文字
# * 禁止 160文字
# のイメージ
Layout/LineLength:
Max: 160
Exclude:
- "db/migrate/*.rb"
- "bin/bundle"
- "config/routes.rb"
# 20 行超えるのは migration ファイル以外滅多に無い
Metrics/MethodLength:
Max: 20
Exclude:
- "db/migrate/*.rb"
# 分岐の数。ガード句を多用しているとデフォルト 7 だと厳しい
Metrics/PerceivedComplexity:
Max: 8
#################### Naming ################################
# has_ から始まるメソッドは許可する
Naming/PredicateName:
ForbiddenPrefixes:
- "is_"
- "have_"
NamePrefix:
- "is_"
- "have_"
# 3 文字未満だと指摘されるが、未使用を示す _ や e(rror), b(lock),
# n(umber) といった 1 文字変数は頻出するし、前置詞(by, to, ...)や
# よく知られた省略語 (op: operator とか pk: primary key とか) も妥当。
# 変数 s にどんな文字列かを形容したい場合と、不要な場合とがある=無効
Naming/MethodParameterName:
Enabled: false
#################### Security ##############################
# 毎回 YAML.safe_load(yaml_str, [Date, Time]) するのは面倒で。。
Security/YAMLLoad:
Enabled: false
#################### Style #################################
# レキシカルスコープの扱いが alias_method の方が自然。
# https://ernie.io/2014/10/23/in-defense-of-alias/ のように
# 問題になる場合は自分で緩める。
Style/Alias:
EnforcedStyle: prefer_alias_method
# redirect_to xxx and return のイディオムを維持したい
Style/AndOr:
EnforcedStyle: conditionals
# 日本語のコメントを許可する
Style/AsciiComments:
Enabled: false
# do .. end から更にメソッドチェーンすると見づらいので
# auto-correct せず、自分で修正する
# spec 内は見た目が綺麗になるので許可
Style/BlockDelimiters:
AutoCorrect: false
Exclude:
- "spec/**/*_spec.rb"
## option 等、明示的にハッシュにした方が分かりやすい場合もある
#Style/BracesAroundHashParameters:
# Enabled: false
# scope が違うとか親 module の存在確認が必要とかデメリットはあるが、
# namespace 付きのクラスはかなり頻繁に作るので簡単に書きたい。
Style/ClassAndModuleChildren:
Enabled: false
# Style/CollectionMethods 自体は無効になっているのだが、
# https://github.com/bbatsov/rubocop/issues/1084
# https://github.com/bbatsov/rubocop/issues/1334
# Performance/Detect がこの設定値を見るので PreferredMethods だけ変更しておく。
#
# デフォルト値から変えたのは
# find -> detect
# ActiveRecord の find と間違えやすいため
# reduce -> inject
# detect, reject, select と並べたときに韻を踏んでいるため。
# collect -> map を維持しているのは文字数が圧倒的に少ないため。
Style/CollectionMethods:
PreferredMethods:
detect: "detect"
find: "detect"
inject: "inject"
reduce: "inject"
# ドキュメントの無い public class を許可する
Style/Documentation:
Enabled: false
# !! のイディオムは積極的に使う
Style/DoubleNegation:
Enabled: false
# case
# when ios?
# when android?
# end
# のようなものは case の方が網羅の表現力が高い
Style/EmptyCaseCondition:
Enabled: false
# 明示的に else で nil を返すのは分かりやすいので許可する
Style/EmptyElse:
EnforcedStyle: empty
# 空メソッドの場合だけ1行で書かなければいけない理由が無い
# 「セミコロンは使わない」に寄せた方がルールがシンプル
Style/EmptyMethod:
EnforcedStyle: expanded
# いずれかに揃えるのならば `sprintf` や `format` より String#% が好きです
Style/FormatString:
EnforcedStyle: percent
# まだ対応するには早い
Style/FrozenStringLiteralComment:
Enabled: false
# if 文の中に 3 行程度のブロックを書くぐらいは許容した方が現実的
# NOTE: https://github.com/bbatsov/rubocop/commit/29945958034db13af9e8ff385ec58cb9eb464596
# の影響で、if 文の中身が 1 行の場合に警告されるようになっている。
# Style/IfUnlessModifier の設定見てくれないかなぁ? (v0.36.0)
Style/GuardClause:
MinBodyLength: 5
# rake タスクの順序の hash は rocket を許可する
Style/HashSyntax:
Exclude:
- "**/*.rake"
- "Rakefile"
# 平たくしてしまうと条件のグルーピングが脳内モデルとズレやすい
Style/IfInsideElse:
Enabled: false
# 条件式の方を意識させたい場合には後置の if/unless を使わない方が分かりやすい
Style/IfUnlessModifier:
Enabled: false
# scope 等は複数行でも lambda ではなく ->{} で揃えた方が見た目が綺麗
Style/Lambda:
EnforcedStyle: literal
# end.some_method とチェインするのはダサい
# Style/BlockDelimiters と相性が悪いけど、頑張ってコードを修正してください
Style/MethodCalledOnDoEndBlock:
Enabled: true
# この 2 つは単発で動かすのが分かっているので Object を汚染しても問題ない。
# spec/dummy は Rails Engine を開発するときに絶対に引っかかるので入れておく。
Style/MixinUsage:
Exclude:
- "bin/setup"
- "bin/update"
- "spec/dummy/bin/setup"
- "spec/dummy/bin/update"
# 1_000_000 と区切り文字が 2 個以上必要になる場合のみ _ 区切りを必須にする
# 10_000_00 は許可しない。(これは例えば 10000 ドルをセント単位にする時に便利だが
# 頻出しないので foolproof に振る
Style/NumericLiterals:
MinDigits: 7
Strict: true
# foo.positive? は foo > 0 に比べて意味が曖昧になる
# foo.zero? は許可したいけどメソッドごとに指定できないので一括で disable に
Style/NumericPredicate:
Enabled: false
# falsy な場合という条件式の方を意識させたい場合がある。
# Style/IfUnlessModifier と同じ雰囲気。
Style/OrAssignment:
Enabled: false
# 正規表現にマッチさせた時の特殊変数の置き換えは Regex.last_match ではなく
# 名前付きキャプチャを使って参照したいので auto-correct しない
Style/PerlBackrefs:
AutoCorrect: true
# Hash#has_key? の方が key? よりも意味が通る
Style/PreferredHashMethods:
EnforcedStyle: verbose
# 受け取り側で multiple assignment しろというのを明示
Style/RedundantReturn:
AllowMultipleReturnValues: true
# 特に model 内において、ローカル変数とメソッド呼び出しの区別をつけた方が分かりやすい場合が多い
Style/RedundantSelf:
Enabled: false
# 無指定だと StandardError を rescue するのは常識の範疇なので。
Style/RescueStandardError:
EnforcedStyle: implicit
# user&.admin? が、[nil, true, false] の 3 値を返すことに一瞬で気づけず
# boolean を返すっぽく見えてしまうので無効に。
# user && user.admin? なら短絡評価で nil が返ってくるのが一目で分かるので。
# (boolean を返すメソッド以外なら積極的に使いたいんだけどねぇ
#
# 他に auto-correct してはいけないパターンとして
# if hoge && hoge.count > 1
# がある。
Style/SafeNavigation:
Enabled: false
# spec 内は見た目が綺麗になるので許可
Style/Semicolon:
Exclude:
- "spec/**/*_spec.rb"
# * 式展開したい場合に書き換えるのが面倒
# * 文章ではダブルクォートよりもシングルクォートの方が頻出する
# ことから EnforcedStyle: double_quotes 推奨
Style/StringLiterals:
EnforcedStyle: double_quotes
# 式展開中でもダブルクォートを使う
# 普段の文字列リテラルがダブルクォートなので使い分けるのが面倒
Style/StringLiteralsInInterpolation:
EnforcedStyle: double_quotes
# String#intern は ruby の内部表現すぎるので String#to_sym を使う
Style/StringMethods:
Enabled: true
# %w() と %i() が見分けづらいので Style/WordArray と合わせて無効に。
# 書き手に委ねるという意味で、Enabled: false にしています。使っても良い。
Style/SymbolArray:
Enabled: false
# 三項演算子は分かりやすく使いたい。
# () を外さない方が条件式が何なのか読み取りやすいと感じる。
Style/TernaryParentheses:
EnforcedStyle: require_parentheses_when_complex
# 複数行の場合はケツカンマを入れる(引数)
# Ruby は関数の引数もカンマを許容しているので
# * 単行は常にケツカンマ無し
# * 複数行は常にケツカンマ有り
# に統一したい。
# 見た目がアレだが、ES2017 でも関数引数のケツカンマが許容されるので
# 世界はそちらに向かっている。
Style/TrailingCommaInArguments:
EnforcedStyleForMultiline: comma
# 複数行の場合はケツカンマを入れる(Arrayリテラル)
# JSON がケツカンマを許していないという反対意見もあるが、
# 古い JScript の仕様に縛られる必要は無い。
# IE9 以降はリテラルでケツカンマ OK なので正しい差分行の検出に寄せる。
# 2 insertions(+), 1 deletion(-) ではなく、1 insertions
Style/TrailingCommaInArrayLiteral:
EnforcedStyleForMultiline: comma
# 複数行の場合はケツカンマを入れる(Hashリテラル)
Style/TrailingCommaInHashLiteral:
EnforcedStyleForMultiline: comma
# %w() と %i() が見分けづらいので Style/SymbolArray と合わせて無効に。
# 書き手に委ねるという意味で、Enabled: false にしています。使っても良い。
Style/WordArray:
Enabled: false
# 0 <= foo && foo < 5 のように数直線上に並べるのは
# コードを読みやすくするテクニックなので equality_operators_only に。
# Style/YodaCondition:
# # TODO: rubocop 0.63.0以降はforbid_for_equality_operators_onlyなので依存を引き上げれば有効にできる
# EnforcedStyle: forbid_for_equality_operators_only
# 条件式で arr.size > 0 が使われた時に
# if !arr.empty?
# else
# end
# に修正されるのが嫌。
# 中身を入れ替えて否定外しても良いんだけど、どちらが例外的な処理なのかが分かりづらくなる。
Style/ZeroLengthPredicate:
Enabled: false
2 config/rubocop/rails.ymlを作成する
Rails:
Enabled: true
# ActiveRecord で association を安易に delegate すると
# N+1 を起こしまくるので、なるべく delegate 的なメソッドを使わずに
# コストが掛かっていることを自覚できるようにしておきたい。
# メソッドでも危ういが、DSL だと更に意識から抜けるので無効に。
Rails/Delegate:
Enabled: false
# 意図せずに exit を書くこと無いでしょ?
# 毎回 Exclude / rubocop:disable する方が手間。
Rails/Exit:
Enabled: false
# -File.join(Rails.root, "app", "models")
# +Rails.root.join("app", "models")
# はともかく
# -Rails.root.join("app/models")
# +Rails.root.join("app", "models")
# は Pathname#plus が行っているので意味無いのでは?
Rails/FilePath:
Enabled: false
# 桁が揃わなくて気持ち悪い
# create(:user, logged_in_at: 1.day.ago)
# create(:user, logged_in_at: 2.days.ago)
Rails/PluralizationGrammar:
Enabled: false
# unless 文を使ってでも「空」を条件にした方が
# 「存在する」よりも「空」の方が状態として特別なので
# 脳内モデルと合致しやすい。
Rails/Present:
Enabled: false
# method_missing を隠したい場合は respond_to? を使うべき
Rails/SafeNavigation:
ConvertTry: true
# valid? チェックし忘れを防ぎたい
Rails/SaveBang:
Enabled: true
# staging 環境を使っているので追加
Rails/UnknownEnv:
Environments:
- development # rubocop default.yml
- test # rubocop default.yml
- production # rubocop default.yml
3 rootフォルダに.rubocop.yml
を作成する
require:
- rubocop-rails
inherit_from:
- config/rubocop/rubocop.yml
- config/rubocop/rails.yml
AllCops:
TargetRubyVersion: 2.6
# Rubocopのversion1になるための警告
# Rubocopがversion1になると以下のオプションが強制的にtrueになる
# For rubocop < 1.0.0
Lint/RaiseException:
Enabled: true
# For rubocop < 1.0.0
Lint/StructNewOverride:
Enabled: true
# For rubocop < 1.0.0
Style/HashEachMethods:
Enabled: true
# For rubocop < 1.0.0
Style/HashTransformKeys:
Enabled: true
# For rubocop < 1.0.0
Style/HashTransformValues:
Enabled: true
bundle exec rubocop -a
を実行するgroup :development, :test
の中にrspec-rails
を追加するgroup :development, :test do
gem "rspec-rails"
end
2. bundle
rails g rspec:install
--color
を記述する--color
--require spec_helper
3. spec/supportディレクトリを作成する
4. 作成されたspec/rails_helper.rb
にsupport
ディレクトリ配下のファイルを読み込ませる
abort("The Rails environment is running in production mode!") if Rails.env.production?
require 'rspec/rails'
# ↓追記してspec/support/以下を読み込ませる
Dir[Rails.root.join("spec/support/**/*.rb")].sort.each {|f| require f }
begin
ActiveRecord::Migration.maintain_test_schema!
5. 作成されたspec/spec_helper.rb
にspecのステータスファイルを作成する記述を追加する
RSpec.configure do |config|
config.fixture_path = "#{::Rails.root}/spec/fixtures"
config.use_transactional_fixtures = true
config.infer_spec_type_from_file_location!
config.filter_rails_from_backtrace!
# ステータスファイルの作成先
config.example_status_persistence_file_path = "./spec/status.txt"
end
6. .gitignoreにspec/status.txt
を追加する
7. config/application.rbにrails g
実行時に自動生成されるspecファイルを記述する
config.generators do |g|
g.test_framework :rspec,
fixtures: true,
view_specs: false,
helper_specs: false,
routing_specs: false,
controller_specs: false
config.generators.system_tests = nil
end
gem "rubocop-rspec"
を追加するbundle
require: "rubocop-rspec"
# 日本語だと「〜の場合」になるので suffix でないと対応できない
RSpec/ContextWording:
Enabled: false
# subject はコピペ可搬性よりもそのまま USAGE であって欲しい
RSpec/DescribedClass:
EnforcedStyle: explicit
# it が一つしか無いような context では空行を開ける方が読みづらい
# context "when foo is bar" do
# let(:foo) { bar }
# it { is_expected.to do_something }
# end
RSpec/EmptyLineAfterFinalLet:
Enabled: false
# each で回したり aggregate_failures 使ってたりすると厳しい。
# feature spec は exclude でも良いかもしれない。
# ヒアドキュメント使うと一瞬で超えるので disable も検討。
RSpec/ExampleLength:
Max: 8
# block の方がテスト対象が
# * `{}` の前後のスペースと相まって目立つ
# * 普段書く形と同じなので自然に脳内に入ってくる
RSpec/ExpectChange:
EnforcedStyle: block
# one-liner の should は書きやすいし意味が通りやすいし副作用も無いので撥ねる必要がない。
# ただ expect 派に対して強制するほどでもないので統一はしない。
RSpec/ImplicitExpect:
Enabled: false
# let を使うのは context 間で条件が違うものが存在する時だけにしたい。
# before の方が事前条件を整えていることが分かりやすい。
RSpec/InstanceVariable:
Enabled: false
# spec_helper で meta[:aggregate_failures] を設定することで
# aggregate_failures が全ての spec で有効になる。
#
# ほぼ MultipleExpectations についてはチェックされなくなる設定なので注意。
# パフォーマンスの問題さえ無ければ 1 example 1 assertion にしておく方が
# 読みやすいテストになりやすいので、そこはレビューで担保していく必要がある。
RSpec/MultipleExpectations:
Enabled: true
# 変に名前つけて呼ぶ方が分かりづらい。
# テスト対象メソッドを呼ぶだけの subject 以外を書かないようにする方が効く。
RSpec/NamedSubject:
Enabled: false
# Model
# `- #method
# |- 頻出ケースのテスト 1
# |- 頻出ケースのテスト 2
# `- レアケース
# |- レアケースのテスト 1
# `- レアケースのテスト 2
# のように括り出すと、レアケースのテストを読み飛ばせるようになり
# テストを読む人にやさしくなる。
# デフォルトの 3 より少し緩めてもヨサソウ。
RSpec/NestedGroups:
Max: 4
# ブロックは初見だと返り値を書いていると気づけないので and_return にしたいが、
# ブロックの方が見た目がスッキリして見やすいので、どちらでもお好きにどうぞ。
RSpec/ReturnFromStub:
Enabled: false
.rubocop.yml
にrequire: rubocop-rspec
を追加する.rubocop.yml
に- config/rubocop/rspec.yml
を記述するrequire:
- rubocop-rails
- rubocop-rspec <- ここ
inherit_from:
- config/rubocop/rubocop.yml
- config/rubocop/rails.yml
- config/rubocop/rspec.yml <- ここ
AllCops:
TargetRubyVersion: 3.0
NewCops: enable
Heroku有料化に伴いサイトを移行中。。。。
しばしお待ちください。。。
subtitle lorem ipsum dolor sit amet consectetur.
Use this area to describe your project. Markdown supported.
optional info list (delete if not using):
subtitle lorem ipsum dolor sit amet consectetur.
Use this area to describe your project. Markdown supported. This entry (project1.md) uses links for the image sources. All other projects in the portfolio use local images. Both work just fine! Lorem ipsum dolor sit amet, consectetur adipisicing elit.
Lorem ipsum dolor sit amet consectetur.
Use this area to describe your project. Lorem ipsum dolor sit amet, consectetur adipisicing elit. Est blanditiis dolorem culpa incidunt minus dignissimos deserunt repellat aperiam quasi sunt officia expedita beatae cupiditate, maiores repudiandae, nostrum, reiciendis facere nemo!
茨城県北部を拠点に企業様のビジネスの発展を支えるWebサービスを開発しています。最近は都市部の開発を行っておりますが、地方が都市部と同等のサービスを利用できるように地方のIT化も目指し活動しております。
商号: | Web屋 和賀井 |
---|---|
所在地: | 茨城県北茨城市中郷町汐見ヶ丘5丁目197-112 |
代表者: | 和賀井 裕貴 |
開業: | 令和2年9月 |
事業内容: | Webサービスの開発・運営 |
Timeline
私たちに関わりを持たせて頂いたプロジェクトは責任を持って遂行いたします。アジャイルソフトウェア開発宣言に則り顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
お問い合わせ