備忘録。
外部APIを呼ぶメソッド、処理に時間のかかるメソッドなど、普段のテストでは不要であるメソッドは factory 側で潰すと楽。
FactoryGirl.define do factory :user do transient do stubs [:call_external_api] end after :build do |user, evaluator| evaluator.stubs.each do |m| r = RSpec::Mocks::Matchers::Receive.new(m, -> {}) RSpec::Mocks::AllowanceTarget.new(user).to r end end
もし User#call_external_api のテストをしたい場合は stubs を空にすれば良い。
user = build :user, stubs: [] user.call_external_api #=> call_external_api が呼べる。
8月末に発売された「BALDR HEART バルドハート (PC 18禁ゲーム)」と「テイルズオブベルセリア(PS3)」を最近やっとクリアできたので、たまにはゲームの感想でもブログに書いてみる。
Qiita と違ってこういう記事書いても非公開にならないので、はてなブログは良い。
戯画のバルドシリーズの最新作。今までのシリーズが好きなら、買って後悔しない出来だと思う。
プレイ時間は全ヒロイン、サバイバル Stage 260 クリアまでで50時間くらい。
電脳化が一般化し、仮想世界（ネット）はもう一つの現実となった。 仮想世界に没入（ダイブ）して活動する電子体が怪我を負えば現実の肉体にフィードバックされ、リミッターがかかってない場所での死は脳死（フラットライン）に至ってしまうほどリアルな手触りを得ていた。
とある事情で戦闘能力と職を失った瀧沢蒼は、養父を頼り故郷である『海神』という島に帰ってきたが、傭兵時代の相棒である三納岸ユーリがなぜか島にまでついて来た上に、ついて早々、記憶喪失の少女月詠を助けたことで自宅に居候させることになってしまう。
過疎化が進みろくな仕事も無い島だったが、謎の人物から仕事の依頼が舞い込む。 その内容は、海神唯一の学園である『甲華学園』に編入し、学園生が島で発生しているテロに関わっていないか調査することだった。
学園に潜入しようとした蒼の前にシュミクラムで立ちはだかる生徒会長の天ケ瀬茉緒。
その時、蒼の前に自らを妖精と名乗る少女が現れ、戦闘能力を失った蒼のシュミクラムに同化しはじめた
前作のバルドスカイから未来の話なので、
など、過去作をやっている人にとっては懐かしい単語が出てくる。
今までのバルドシリーズと同様、ヒロインの攻略順は完全固定で 月詠 → 茉緒 → ユーリ → 凪 の順になる。
シナリオを進めると伏線が少しずつ分かるようになっていて、過去の事件と現在の事件がつながり始める。凪シナリオ後半の世界がカオスな感じになるのはバルドっぽくて良かった。
主題歌が流れてラスボス戦に突入する演出が熱い！！
イニシャライザ使って、9コンボx2 ぐらい叩き込んでいるのに、HPゲージが全然減らない・・・。武装のLvが低いのかな。
— 神速@リリカルエンジニア (@sinsoku_listy) 2016年9月12日
昨日、バルドハートのラスボス戦を2時間くらいやったけど、勝てなかった…。遠距離だと自キャラ背後から攻撃くるし、近距離だと炎のせいでヒートゲージ上がるし、攻略法がよく分からん。
— 神速@リリカルエンジニア (@sinsoku_listy) 2016年9月13日
武装のレベルが低いと、だいぶ厳しい。
バルドハート、やっとクリアした！ラスボスは master の武装でコンボを決めたら、わりとあっさり倒せた（難易度はノーマルだけど）
— 神速@リリカルエンジニア (@sinsoku_listy) 2016年9月14日
master 武装でコンボすれば、結構簡単に倒せた。
今作では武装が擬人化され、武装を使うごとに兵装少女との信頼関係が高まって新しい武装が使えるようになる。 また、装備する武装の組み合わせで兵装少女同士が戦友になって、更に武装が強くなる。
やっぱり武装が強くなってコンボ組み立てるのは楽しい。「バルトハンマー → I・A・I → 彗星脚 → DDミサイル」みたいに、最後は重火器で〆るのが威力高くてよく使ってた。
巨弾のイリヤのグラルパトン「こいつをふっ飛ばして、更地にしてやろうぞ〜」の台詞が好き。
「BALDR HEART」アペンドディスク制作決定！続報をお楽しみに！#バルドハート #戯画https://t.co/qPstW7kBun pic.twitter.com/Zw7BHWOJuX
— 戯画オフィシャル ヒットミー1.27発売 (@web_giga) 2016年10月1日
アペンドディスク出るらしいので、全兵装の武装を master にして、全兵装少女を戦友にしておかないといけない。
テイルズシリーズの最新作。前作ゼスティリアと同じ世界観で、過去の話。
プレイ時間は隠しダンジョン、真ラスボスを倒すの含めて70時間くらい。
ウェイストランドと呼ばれる世界。ミッドガンド聖導王国の辺境の村にベルベット・クラウという少女が住んでいた。彼女は明るく飾り気のない性格で家族と平和に暮らしていた。 しかし、赤い月が上ったある夜、この村に異変が起きた。この事件がきっかけでベルベットは肉親を失い、左腕が魔の手になってしまう。 それから3年、ベルベットは復讐のため、旅に出る。
復讐から始まる旅だけど、話が進むにつれて謎が少しずつ分かっていき、そして世界の危機を救うことに・・・というテイルズらしい話。
前作のような変な矛盾も無いし、良いシナリオだったと思う。ただ、ベルセリアの未来がゼスティリアだと思うと複雑な気持ちになるが・・・。
戦闘システムはSG(ソウルゲージ)で特技を結構自由に出せるし、慣れるとスイッチブラストでキャラ交換しながらコンボを繋げられるようになって楽しい。
前作のようにカメラワークが酷かったり、戦闘キャラが2人固定みたいな事もないのでストレスなく遊べると思う。
ライフィセット の存在が癒やし。一番可愛い。
バルドハートの感想に時間かけすぎて、テイルズは短くなってしまった。
普通にみんなやっていることだと思うけど、自分が gem を入れるときに最低限やることをまとめてみた。
何かしらの方法で探してきた gem を「導入するかどうか」の判断をするときにやることです。
ほとんどの gem は GitHub で公開されているので、下記の観点を参考に調べる。
ただ、「機能が少なく、あまり更新されない gem」とか「Issues は多いけど、他に代用もない phantomjs」みたいなのもあるので、上記だけでは判断できないこともある。
はてなブログや Qiita などの記事は参考になるけど、「gem のアップデートに追従できていない」「インストール手順が中途半端」「一応動くけど、内容が微妙」みたいなのが多いです。 安易に信じると、未来の自分が死にます。
今までの経験上、信頼できるのは「ソースコード、次に README」です。英語が苦手でも、 README は一通り目を通した方が良いです。
GitHub のリポジトリにある xxx.gemspec を読んで、依存関係がどのくらいあるかを調べる。
全部を読むのは時間かかるので、「バグに遭遇したとき、コードを読めそうか？直せるか？」の観点でざっと目を通します。
はてなブログや Qiita の「おすすめ gem 10選」みたいなので公開されている gem を一気に Gemfile に入れるのは絶対ダメ。
問題が起きたときに「どの gem が原因か？」が分からなくなって大変なので、面倒でも1つずつ調べてから導入すべきです。
ざっと gem を導入するときに気にしてることを書いてみました。何か参考になれば幸いです。
Rails アプリから機能を gem 化する方法の実例を1つ公開してみる。
rake notes で Rails アプリ内の "OPTIMIZE|FIXME|TODO" を一覧表示できるが、これを拡張する。
git clone して、 git grep :notes するgit grep "class SourceAnnotationExtractor" する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 を作ってみたい人向けの内容。
実は下記のようなコードを置くだけで 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 を使っていて、日時カラムを作るケースがありますが、あれのメリットが知りたいと思って、ブログに書いてみた。
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 などを保存するような実装のメリットが知りたい。
よく「レコード挿入日時と登録日時は意味が違う」という意見をお聞きするのですが、「ユーザーが登録するとレコードが1件できる」という事を考えると、そこまで意味が違うものなのか疑問。
そもそも「レコード挿入日時」と「登録日時」と使い分ける仕様がほぼ無い。(後述する非同期処理くらい？)
「ActiveRecord が自動的に生成するものを使うべきじゃない」って話も聞くけど、用意されている機能を使った方が冗長にコード書かなくて済むし、自分たちで再実装するより良いのでは？ belongs :user, touch: true とか使えて便利ですし。
標準だと View の cache で Modle の updated_at が使われるので、 updated_at を最終更新日としておいて方がシンプルに Rails のレールに乗れて良い。
「非同期処理（または登録処理）に時間がかかり、ユーザーのリクエスト 〜 DB挿入に時間がかかる」場合、値がズレるので別カラムは必要かもしれない。そのズレが問題になる仕様の場合は。
「特定のカラムが更新されたときだけ、更新日時を更新したい」みたいな仕様の場合は updated_at とは別にカラムを用意した方が良いと思う。
みたいなケースだと、 updated_at をそのまま活用するのは難しいと思う。
DB設計に問題がなければ、基本的には Rails 標準の timestamps を使って良いのではないかと思っています。
もし、別の考えなどあればコメントなど頂けると嬉しいです。
Rails の link_to_if にブロックを渡したときの挙動が分かりづらいので、使う場合の注意点をまとめてみました。
ブロックの内容を条件によってリンクにしたい場合は 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 の場合も同じ。
ユーザーのアイコンと名前を条件によってリンクにする場合を考えます。*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 で検索してみると、 link_to_if でブロックを必ず評価するプルリクが出て、1度マージされた後 revert されていました。
また、 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 にブロックを渡した時の挙動は少し分かりづらい_if のメソッドとしては一貫性があるRails にプルリクを投げる前に気づくことができて良かった。
RubyKaigi 2016 で色んな Rubyist に link_to_if について話を聞いて、助言を頂いたお陰です。感謝。
