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

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

 

今回は、ここまで。

おわり

Linux,Windows,環境構築

こんにちは、しきゆらです。
Railsと戯れ始めたわけですが、MySQLを動かすために結構時間がかかってしまいました。
serviceで自動起動する方法がわからず、毎回service mysql startとして起動しています。

さて、今回はserviceコマンドを使ってMySQLを立ち上げようとしたときにおこった問題と解決方法をメモしておきます。

 

Ruby,Windows

こんにちは、しきゆらです。
今回は、Railsさんと仲良くなるための施策として、公式のチュートリアルを進めながら理解を深めていこうと思います。

Railsと戯れることが多いのですが、まだまだ仲がいいとは言えません。
デプロイで苦戦した記憶があるのと、Rails流のお作法をきちんと把握しきれていないことが要因です。
そこで、手軽にできて楽しそうなRailsチュートリアルを一通りふれながらRails流のお作法を学んで行きます。

今回は、Rails Guidesにある「Railsをはじめよう」というものをやっていきます。
基本はガイドにある通りですが、一部違うことをすることがあるかもしれません。
この時はきちんと記載します。

 

0. なぜ本ではなく無料のガイドを使うの？

Railsに強い先輩に、良さげな本はないかを聞いたところ、本よりも公式情報のほうがよい、ということを伺いました。
実際、少し見てみるとブログや技術系サイトの情報よりもわかりやすかった気がします。

あとは、大きい要因としては公式情報なので信用できるはずだからです。
発売されている本は、間違っていないか等をきちんと調査しているとは思いますが、動かなかった場合

  • 自分の環境・記述が悪い
  • 本の内容が間違えている
  • Rails、関連するライブラリのバグ

等々様々な要因が考えられるわけです。

たいていの場合、自分の環境や記述が間違えていることが多いですが、本の内容自体が間違えていることも意外と多くあります。
また、本の場合は情報の更新がされないので、本革のミスの場合は正誤表を確認しながら作業を進めないといけません。
これは面倒ですよね。

その点、Rails Guidesは(ほぼ)公式情報である上に、きちんと最新情報も書かれているようです。
安心感が違いますよね。
一応、公式サイトや定義を確認しようということもいわれたので、公式のものを使っていきます。

では、実際にガイドをもとに作業を進めていきます。

Ruby,Windows,環境構築

2020/08/19 追記

こちらの記事が割と検索に引っかかってみてくれているようなので追記しておきます。
最近関連した記事を追加したので、よろしければこちらもどうぞ。
【Ruby/Win】Windows上のAtomからWSL2上のrubocopを利用する 2020年版

本文

こんにちは、しきゆらです。
今回は、Windows上でRubyの開発環境を整える方法をメモしておきます。

以前までは、DockerやWSLを使って開発ができそうな状態までをメモしてきました。
しかし、少し前に画期的なものがMicrosoftから発表されました。
そう、WSL2です。

以前までのWSL(以下、WSL1)から大きく改善され、個人的には普段使いできるのでは？という状態までなっています。
今回は、WSL2を導入してWindows上でRuby環境を構築、rubocopで変なコードを怒ってもらうところまでをまとめます。

Linux,Ruby,Windows

皆さん、Sinatra使っていますか？
簡単なWebアプリであれば一瞬でできてしまうような、Webアプリケーションフレームワークです。

しかし、簡単なので機能をたくさん増やしていたり、処理が多くなってくるとどうしても起こるのが「全体像が見えにくくなる」ということ。
機能やエンドポイントごとに分割したい、と思うこともあるでしょう。
私は思いました。
その方法を調べてみたので、まとめておきます。

例として、以下のような形でアプリケーションを作成しているとします。

[ruby]
# app.rb
require 'sinatra’
class MyApp < Sinatra::Application
get '/’ do
'hello’
end
end
[/ruby]

今回は、エンドポイントごとにファイルを分割していきます。

 

Ruby,Windows

こんにちは、しきゆらです。

タイトルが長くてよくわからないかもしれません。
問題と解決方法を、メモしておきます。

問題

WSL上にrbenvを用いてRuby2.6.3をインストールして簡単なWebアプリを作成しようとしていました。
適当なディレクトリにbundlerを使ってSinatraとUnicornをインストールし、起動テストを行いました。
最初は問題なくUnicornが起動したので、一度停止させておきました。
再びUnicornを立ち上げると、うまく立ち上がりません。

Unicornはデフォルトではターミナルにエラー等を表示しないので、エラーログをファイルに吐き出すようにしてありました。
エラーログの中には、このようなエラーが記録されていました。
code:error
F, [2019-05-22T22:52:13.998205 #22482] FATAL — : error adding listener addr=/path/to/sinatra_app/tmp/sockets/unicorn.sock
ArgumentError: socket=/path/to/sinatra_app/tmp/sockets/unicorn.sock specified but it is not a socket!

どうやら、ソケットファイルが問題のようです。

解決方法

根本的な解決方法ではありませんが、tmp/sockets/unicorn.sockファイルを削除すると問題なく起動するようになりました。

しかし、再度Unicornを停止した後Unicornを再起動すると再び上記のエラーが表示されます。
Unicorn停止とsockファイルの削除は同時に行うと、無駄な時間がかからないかともいます。

解決方法があればコメントやTwitter等から教えてほしいです。
というか、そもそもsockファイルと普通のファイルの違いなどもきちんと理解できているわけではないので、この辺も含めて調べる必要がありそうです。

今回は、場当たり的な対処法までをまとめておきました。

 

おわり

Windows,環境構築

こんにちは、しきゆらです。
今回は、Windowsで開発環境を整えていきます。
Windows環境での開発環境としてWSLを使って環境を整えていこうと思います。