Windows,環境構築

2021/07/19追記

またまた手順が変わっていたので、改めて記事をまとめなおしました。
こちらの記事をご覧下さい。
【WSL2】Ubuntu 20.04でPID1をsystemdにする 2021年7月版

2020/08/19追記

Win環境を構築しなおして、こちらの手順をやったところうまくいきませんでした。
まとめ直した記事を公開していますので、よろしければこちらもよろしくお願いします。
【WSL2】Ubuntu20.04でPID1をSystemdにする

本文

こんにちは、しきゆらです。
今回は、前回なんとか動くようになったsystemctlについて調べなおしつつ、きちんと動くようになったので改めてメモしておきます。

前回、【WSL】WSL2でMySQL8.0が動かないのを解決するにて、mysqlを動かすために systemctlをごにょごにょして動くようにしました。
ひとまず動くようにはなったんですが、自動起動させてもきちんと動いてくれず困っていました。
今回は、そもそもなぜsystemctlさんが動かないのかを調べつつ、解決方法が見つかったのでメモしておきます。

Windows,環境構築

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

気が付いたらWSL2が正式対応になっていました。
いい時代になりましたね。
Linux環境のためにWindowsに仮想環境を立ち上げたり、高いMacに移行しなくても、お手軽に開発環境を整えることができるようになりました。

開発環境もWindows、面倒が少なくてよい。

さて、先日PCを組みなおしたためOSがまっさらになっていたので、改めてWSL2の環境構築を行いました。
そんな中で、MySQL8.0を使おうとしたときに詰まったので、その様子と解決までの流れをメモしておきます。
(組みなおしたPCについては、興味がないと思うので書きません)

Windows,環境構築

こんにちは、しきゆらです。
今回は、先日1.0 になったWindows TerminalさんをUbuntuのターミナルっぽくしてみたのでメモしておきます。

以前、MacのターミナルをUbuntuのターミナルっぽくする記事を書きましたが、そのWindows版ですね。

Windows TerminalさんをUbuntuのターミナルっぽくしたくて調べてみたところ、海外のサイトで配色の情報をまとめてくれているところがありました。
https://superuser.com/questions/497240/ubuntu-purple-terminal-colors-in-conemu | windows – Ubuntu purple terminal colors in ConEmu – Super User
そこを参考に、Windows Terminalさんの設定をしています。

では、いかにUbuntuっぽいカラースキーマをドーン。
久々に設定ファイルを覗いたのですが、割とわかりやすくなっていますね。
少し前に見たときは、色を配列にぶち込んであるだけで、どれがどこに対応しているのかわかりにくかったのですが、
きちんと色の名前をキーとして設定できるようになっていました。

"schemes": 
[
  {
    "name" : "Ubuntu Like",
    "cursorColor": "#FFFFFF",
    "selectionBackground": "#FFFFFF",
    "background" : "#300A24",
    "foreground" : "#CCCCCC",
    "black" : "#2e3436",
    "blue" : "#3465a4",
    "cyan" : "#06989a",
    "green" : "#4e9a06",
    "purple" : "#75507b",
    "red" : "#cc0000",
    "white" : "#d3d7cf",
    "yellow" : "#c4a000",
    "brightBlack" : "#555753",
    "brightBlue" : "#729fcf",
    "brightCyan" : "#34e2e2",
    "brightGreen" : "#8ae234",
    "brightPurple" : "#ad7fa8",
    "brightRed" : "#ef2929",
    "brightWhite" : "#eeeeec",
    "brightYellow" : "#fce94f"
  }
],

あとは、上記のスキーマを良しなに適応してあげればOK。

{
  "guid": "{xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}",
  "hidden": false,
  "name": "Ubuntu",
  "colorScheme": "Ubuntu Like", // ここに指定してあげればOK
  "source": "Windows.Terminal.Wsl"
}

これにて、Windows TerminalさんをUbuntuのターミナルっぽくすることができました。
あとは、プロンプトを良しなに設定したりすればよいですね。

ようやくWindowsでもまともなターミナルが使えるようになりました。
ターミナルがまともになったので、Macに移行していた開発環境をWSL上に作ってもよさそうですね。
WSL自体も改良されているのと、Windowsとの親和性も向上するようなので、本格的に開発環境をWindowsで構築してもよさそう。
いい時代になりました。

 

さて、今回はここまで。

おわり

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で変なコードを怒ってもらうところまでをまとめます。