Ruby

こんにちは、しきゆらです。
今回は、タイトル通り非Railsアプリのデプロイ作業をCapistranoで自動化するための手順をメモしておきます。

Capistranoといえば、Ruby製のデプロイツールです。
A remote server automation and deployment tool written in Ruby. | https://capistranorb.com/

Capistranoさん自体はRubyやRails専用ではなく、様々なものをデプロイすることができるように設計されています。
とはいえ、調べて出てくる情報の大半はRailsのデプロイについてばかり。
Sinatraのデプロイすら情報が少ないような状態です。
そんな中で、非Railsどころかただ単にCronなどで定期実行するだけの簡単なスクリプトを自動でデプロイするのを自動化する情報なんて見つけるのが難しい。

ということで、今回はフレームワークを使っていないただのRubyスクリプトをCapistranoを使ってサーバへデプロイする方法をメモしておきます。

Ruby

こんにちは、しきゆらです。
気が付けば、7月が終わっていました。

今回は、ちょいちょい書くRSpecさんの記述で見たことないものが出てきたのでメモしておきます。
タイトル通り「described_class」というものです。

こいつは何かというと、ドキュメントによると以下の通り。

If the first argument to an example group is a class, the class is exposed to
each example in that example group via thedescribed_class()method.

described class – Metadata – RSpec Core – RSpec – Relish | https://relishapp.com/rspec/rspec-core/v/3-9/docs/metadata/described-class

簡単に言えば、RSpecの最初に「RSpec.describe ClassNamedo」のように書くと思いますが、
このClassNameを参照するためのメソッドのようです。

確かに、このクラスのSpecですよ、と宣言しているので何度も参照することになるとは思いますが、まさか専用のメソッドが用意されているとは知りませんでした。

 

今回は、これだけ。
おわり

Ruby

こんにちは、しきゆらです。
なんかあれこれしているうちに今年もほぼ半分ほど過ぎていました。
早いものです。

今回は、SeleniumでAlertが表示されるまでの間待機したいことがあったので、調べて解決したのでメモしておきます。

Ruby

こんにちは、しきゆらです。
気が付くと、年が明けて2月です。

今回は、先輩に教えてもらった謎のコードを解読していきます。
謎のコードとは下記のもの。

[ruby]
ObjectSpace.each_object(ActiveRecord::Relation).each(&:reset)
GC.start
[/ruby]

いきさつ

AWS上にあるインスタンスでRailsを動かしていました。
その中で、DBのデータにミスがあったので、1.5万件ほどのデータに紐づく諸々の差し替え作業を行っていました。
このときにおこった問題としては「メモリ使い過ぎで怒られる」という状況でした。
コードを書き換えたりループを工夫したりしても解決せず困っていたとこで先輩が下記のようなコードを教えてくれました。

[ruby]
ModelClass.find_in_batches do |objects|
# 差し替える処理

ObjectSpace.each_object(ActiveRecord::Relation).each(&:reset) # ???
GC.start # ???
end
[/ruby]

このコードが入ると、途中で処理を止められることなく走らせることができるようになりました。

その当時は、先輩すげぇ~と思いながら後で調べておこうと思ってメモしておきました。
そのまま放置されていたものを思い出したので、時間のあるうちに調べてみよう、ということで調べてみました。

ObjectSpaceとは

そもそも、見慣れないクラス名です。
調べてみると、Rubyさんの組み込みモジュールでした。
リファレンスでは

全てのオブジェクトを操作するためのモジュール
module ObjectSpace (Ruby 2.7.0 リファレンスマニュアル)

とのこと。

わかるようなわからないような・・・という感じですが、定義されているメソッド類を見てみると
Rubyで定義したオブジェクトたちに対してあれこれしたり、プロファイルを取るときなどに使われるもののようでした。

ObjectSpace#each_object

その中に、ありました「each_object」メソッド。
「ObjectSpace」が何かわかれば、メソッド名で何をするものなのか大方予想が付きますね。

調べてみると、

指定されたクラスとObject#kind_of?の関係にあるすべてのオブジェクトに対して繰り返す
ObjectSpace.#each_object (Ruby 2.7.0 リファレンスマニュアル)

とのこと。
上記のコードでは「ActiveRecord::Relation」クラスのオブジェクトすべてに対する処理を行うということですね。

こいつは、ブロックを渡すとそのブロックを実行し、繰り返し回数を返すようです。
そして、ブロックが渡らない場合はEnumeratorオブジェクトを返すとのこと。
上記のコードでは、eachメソッドをつなげているので後者ですね。

なお、引数を与えなければすべてのオブジェクトに対して繰り返すようです。
また、Fixnumなどは対象外のようです。

つまり、上記コードの1行目はActiveRecord::Relationクラスのすべてのオブジェクト一つ一つに対して「reset」メソッドを呼び出していることになりますね。

ActiveRecord::Retation#reset

では、「ActiveRecord::Retation#reset」は何者でしょうか。

定義を確認してみると、内部で保持しているデータをすべて破棄しているようです。

つまり、上記コードの1行目が実行されたら、「ActiveRecord::Retationのオブジェクト」はすべて空のデータとなるようです。
1行目の内容は把握できました。
2行目を追っていきます。

GC

見たままGCでしょうね。
一応調べてみると、RubyのGCを制御するためのモジュールでした。
正確な情報は持っていませんが、イメージとしては使用していないデータを解放する仕組みという認識です。
メモリ上にあるいらないものを削除してきれいにしてくれる裏方さん。

GC#start

もう、見たままでしょう。
GC.start (Ruby 2.7.0 リファレンスマニュアル)
GCの処理を始めるためのメソッドです。

別メソッドでGCを禁止するようなこともできるようですが、このメソッドで実行した場合はGCを始めるようです。

すべてを見たうえで

[ruby]
ObjectSpace.each_object(ActiveRecord::Relation).each(&:reset)
GC.start
[/ruby]

たった2行のコードですが、知らないことが満載でした。
処理を簡単にまとめると、この処理の前までに作成されたすべてのActiveRecord::Relationオブジェクトを空にしてGCに削除してもらう感じでしょうか。

1.5万件のデータを処理していると、たくさんの不要なオブジェクトがたまっていき途中で利用できるメモリサイズをオーバーしてしまうということで、それを防ぐために一定の処理を終えると不要になったオブジェクトを削除して次に進む、ということを行っているようですね。

find_eachやfind_in_batchesなどである程度の粒度で処理することなどはわかっていましたが、それですら怒られるのでどうすればいいのかわからないところで、まさか自分でGCを動かして削除させることができるとは・・・。

まだまだ知らないことがいっぱいあるということですね。
まぁよく使うことではないとは思いますが、知っていると困ったときに役に立ちそうです。

まとめ

今回は、先輩が教えてくれた謎のコードを調べながら内容を理解してみました。
ActiveRecordなど、Githubで公開されているコードについては中身を読むことができるので、きちんと中身を知っておくことは大事だなと思いました。

 

今回は、ここまで。
おわり。

Ruby

こんにちは、しきゆらです。
今回は、文字列の先頭・末尾にある特定のものを正規表現で頑張らずとも判定する方法を知ったのでメモしておきます。

文字列の中に、特定のものが入っているかを判定するためには正規表現というものを使う場合があります。
そして、含まれているかどうかを判定するためのメソッドとして「String#match?」があります。
instance method String#match? (Ruby 2.6.0 リファレンスマニュアル)

しかし、文字列の先頭・末尾が特定のものかどうかを判定するためにmatch?を使うのはもったいないことでした。
というのも、この時にはより状況にマッチしたメソッドがあるからです。
それが「String#start_with?」「String#end_with?」です。
instance method String#start_with? (Ruby 2.6.0 リファレンスマニュアル)
instance method String#end_with? (Ruby 2.6.0 リファレンスマニュアル)

これらのメソッドは、機能はシンプルだが高速に処理できるようです。
Ruby: 文字列マッチは正規表現より先に専用メソッドを使おう
Ruby の文字列マッチ判定のパフォーマンス · Yuichi Takada

ということで、知らないメソッドシリーズでした。
ちなみに、これらはrubocop-performanceで怒ってもらえるようです。
Class: RuboCop::Cop::Performance::StartWith — Documentation for bbatsov/RuboCop (master)

今回、はここまで。
おわり

JavaScript,Ruby,Windows,環境構築

こんにちは、しきゆらです。
今回は、SimpackerというGemを使ってサーバ・フロント両方が良しなに動いてくれる環境を整えていきます。

今回はWSL2環境にUbuntuを入れ、そこで動かすことを想定しています。

Ruby,Windows

こんにちは、しきゆらです。
今回は、RSpecで同じ処理を書くことを避ける方法を知ったのでメモしておきます。

 

Railsにてテストを書いているときに、同じようなことを書いてるなぁと思うことがあります。
例えば「このAPIはユーザがいることが前提だ」となると、以下のようなことをいろんなテストで書くことになります。

[ruby]
before do
user = FactoryBot.create(:user)
end
[/ruby]

同じことを書くのは無駄ですよね。
何より繰り返し!修正面倒!!

ということで、このように特定の時に共通する処理を実行してほしい時にどうすればいいかわからなかったので、調べてみた結果をまとめます。

 

Ruby,Windows

こんにちは、しきゆらです。
今回は、RailsとRSpec、DatabaseCleanerを使った環境で起こったちょっとした問題と、(その場しのぎな)回避方法をメモしておきます。

Rails6環境で、DatabaseCleanerというGemを使ってテスト環境を毎回きれいにするようにしています。
そんな中、テストを複数実行すると2回目以降で以下のように怒られる現象に悩まされていました。

[bash]
ActiveRecord::NoEnvironmentInSchemaError:
Environment data not found in the schema. To resolve this issue, r
rails db:environment:set RAILS_ENV=test
[/bash]

 

調べてみると、これは「DBに保存されている環境情報がないから、それを設定してね」というメッセージとこのと。
https://blog.freedom-man.com/no-environment-in-schema-error

実際、上記のコマンドを実行した後にDBを確認するとしっかり情報が入っていましたが、テストを実行した後にはきれいさっぱりになっていました。

[sql]
# rails db:environment:set RAILS_ENV=test を実行した後
mysql> select * from db_name.ar_internal_metadata;
+————-+——-+—————————-+————–
| key | value | created_at | updated_at
+————-+——-+—————————-+————–
| environment | test | 2019-09-23 13:21:49.081104 | 2019-09-23 13
+————-+——-+—————————-+————–
1 row in set (0.00 sec)

# specを実行した後
mysql> select * from rts_test.ar_internal_metadata;
Empty set (0.00 sec)
[/sql]

これでは、確かに毎回設定しないといけません。

しかし、これはおかしな話です。
テストを回すたびに同じ環境情報を入れるなんて面倒でしかありません。

DBの情報がまっさらになっているので、DatabaseCleanerさんが悪さをしている可能性があります。
さらに調べてみると、(だいぶ古いですが)どうやらすでにissueとして報告されているようでした。
https://github.com/DatabaseCleaner/database_cleaner/issues/445

そして、最近これに関連したPRが動いているようです。
https://github.com/DatabaseCleaner/database_cleaner/pull/588
コードを見てみると、上記のar_internal_metadataを削除しないようにしてくれているようです。

しかし、執筆時点ではまだマージされていないので次のバージョンアップまで待ちましょう。
どうしても待てない!という場合は、diffを参考にコードを編集すればとりあえず回避することはできます。

今回はここまで。

おわり

Ruby,Windows

こんにちは、しきゆらです。
今回は、Railsと戯れている中で起こったちょっとした問題を何とかしていきます。

なお、環境としてはWSL2上のUbuntuにrbenvでRubyをインストールしているところで起きました。

状態としては、気が付くとタイトルの通り「rails c」とコマンドを打つと以下のような警告が出るようになっていました。

[bash]
/home/user_name/.rbenv/versions/2.6.4/lib/ruby/2.6.0/fileutils/version.rb:4: warning: already initialized constant FileUtils::VERSION
/home/user_name/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/fileutils-1.2.0/lib/fileutils/version.rb:4: warning: previous definition of VERSION was here
/home/user_name/.rbenv/versions/2.6.4/lib/ruby/2.6.0/fileutils.rb:1267: warning: already initialized constant FileUtils::Entry_::S_IF_DOOR
/home/user_name/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/fileutils-1.2.0/lib/fileutils.rb:1267: warning: previous definition of S_IF_DOOR was here
/home/user_name/.rbenv/versions/2.6.4/lib/ruby/2.6.0/fileutils.rb:1540: warning: already initialized constant FileUtils::Entry_::DIRECTORY_TERM
/home/user_name/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/fileutils-1.2.0/lib/fileutils.rb:1547: warning: previous definition of DIRECTORY_TERM was here
/home/user_name/.rbenv/versions/2.6.4/lib/ruby/2.6.0/fileutils.rb:1542: warning: already initialized constant FileUtils::Entry_::SYSCASE/home/user_name/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/fileutils-1.2.0/lib/fileutils.rb:1549: warning: previous definition of SYSCASE was here
/home/user_name/.rbenv/versions/2.6.4/lib/ruby/2.6.0/fileutils.rb:1595: warning: already initialized constant FileUtils::OPT_TABLE /home/user_name/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/fileutils-1.2.0/lib/fileutils.rb:1602: warning: previous definition of OPT_TABLE was here
/home/user_name/.rbenv/versions/2.6.4/lib/ruby/2.6.0/fileutils.rb:1649: warning: already initialized constant FileUtils::LOW_METHODS /home/user_name/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/fileutils-1.2.0/lib/fileutils.rb:1656: warning: previous definition of LOW_METHODS was here
/home/user_name/.rbenv/versions/2.6.4/lib/ruby/2.6.0/fileutils.rb:1656: warning: already initialized constant FileUtils::METHODS /home/user_name/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/fileutils-1.2.0/lib/fileutils.rb:1663: warning: previous definition of METHODS was here
[/bash]

 

特に大きな問題はないのですが、気持ち悪いので何とかならないかと調べてみました。
すると、同様の問題に直面している人がいました。

FileUtilsのGithubにissueとして挙がっていました。
その中に、暫定的としながらも解決法がありました。

temp solution
gem uninstall fileutils
gem update fileutils --default

fileutils conflict in Ruby 2.5.1 #22 | Github

ひとまず、エラーはなくなりました。
同じような問題で気持ち悪い思いをしている方は、お試しを。

 

今回は、ここまで。

おわり

SQL

こんにちは、しきゆらです。
今回は、DBにてselect文でデータを取得するときの取得順についてメモしておきます。

基本的に、取得順についてはorder句で指定した順番で取得されます。
しかし、order句を指定しない場合もデータは取得することができますね。
この時の取得順について触れる機会があったので、調べた結果をまとめておきます。

 

経緯

今回直面したことの簡単な経緯をメモしておきます。

データベースへランダムにデータを追加し、その結果をCSVとして吐き出す、ということをしていました。
シード値を固定した後、ランダムな値をDBへ追加してその結果問題なく何度も同じ値を取得できているかを確認したかったわけです。

実際、シード値を固定しているためランダム値は何度も同じ値を返すことは確認できました。
しかし、データベースからデータを取得しCSVへ吐き出した結果の差分をとると、何か所か結果が異なる部分がありました。

よく確認すると、データがおかしいわけではなく、単純に値の並び順が異なるだけであり、全く異なる値が入っているわけではないことがわかりました。

この時のSQL文は以下のような形でした。

[SQL]
select * from hoge;
[/SQL]

単純なselect文のみで、orderは指定していませんでした。

 

orderなし時の取得順について

これに関しては、SQL的にはどうにも指定されていません。
仕様等は見つけられませんでしたが、調べてみるとDBの実装依存となるようです。

Oracle Databaseの表データは、データベースへの挿入時の順序にかかわらず、特定の順序では保管されません。ある列の昇順または降順で行を取得するには、そうするようにデータベースに指示する必要があります。

Part 5:ソート順序 | ORACLE

結果の行の表示には特定の順序がないことに気付いたでしょう。

http://MySQL :: MySQL 5.6 リファレンスマニュアル :: 3.3.4.4 行のソート

きちんと書かれているわけではありませんが、順序を指定しない場合は特別何らかのソートがなされるわけではないようです。

MySQLでORDER BYがついていないときに返す結果セットの並び順は定められていない。

MySQLでORDER BYをつけないときの並び順 – かみぽわーる

ブログ等を見てみると、どこも同じようなことが書かれています。
データの取得順は、追加順やどこかのカラム順となるわけではないようです。

 

まとめ

データを取得した順番を考慮しないような場合は問題ありませんが、何らかの順序をもとに処理を行う場合は、しっかりorder句で順番を指定しなければいけないことがわかりました。

 

今回はここまで。

おわり