しきゆらの備忘録

こんにちは、しきゆらです。
今回は、人生初の洋書である「Effective Testing with RSpec 3」を購入したので、洋書ってどうなの？というところをメモしておきます。

購入した本

購入したのは、先述の通り「Effective Testing with RSpec 3: Build Ruby Apps with Confidence」です。

数年前に発売されたRSpecの本です。
RSpecの書籍といえば、長年参照されていたのは「The RSpec Book」ではないでしょうか。

これは、日本語で読める数少ないRSpecの書籍ですが、内容としてはRSpecよりもCucumberなどの別ツールの話が多いことや、バージョンが古いなどの理由で、純粋にRSpecについてきちんと学ぼうと思って買うにはちょっとなぁ、という印象でした。

そんな中で発売された「Effective Testing with RSpec 3: Build Ruby Apps with Confidenc」。
こちらは英語ではありますが、RSpec 3で書かれており、純粋なRSpecについての説明がメインなのでRSpecを学ぶ上ではよさそうな本です。

しかし、洋書ということでハードルが高そう。
私もそう思っていました。
そんな中で、なぜ買ったのかをいかにまとめておきます。

洋書を買ってみて

そもそも、洋書とはいえ今回購入したのはRuby/RSpecの本です。
小説などと違い、スクリプトが読めればたいていの内容は理解できるはずです。
そんな軽いノリで買ってみました。

あとは、以下のブログを読んだから。
【洋書Q＆A】どうやって洋書を読んでるの？どれくらい時間がかかるの？という質問に答えてみた – give IT a try | https://blog.jnito.com/entry/017/09/12/072903

正直に言うと、翻訳されたら買おうと思っていたのですが一向にそのような話が出てこないので早く読みたい、というモチベが勝ってしまった形です。

実際に読んでみると、英語が苦手な私でもある程度雰囲気で理解できている印象です。
要所でサンプルコードを提示してくれているので、単語がわからないから理解できない、ということはあまりありません。
単語的にも比較的簡単なほうなのではないでしょうか。

まだすべてを読み切ったわけではないので、内容的な話は控えますが
洋書を読むというハードルは思っているより低いようです。
洋書を買うという心理的なハードルを越えることができれば、意外とすんなり進んでいけそうな印象でした。

まとめ

今回は、人生で初めて洋書を買ったので、買うまで思っていたことや読んだ印象をさっくりメモしておきました。
洋書に手を出そうかと考えている方の参考になれば幸いです。
(そもそも、情報がほぼないですが・・・)

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

こんにちは、しきゆらです。
今回は、タイトルの通りGitにファイルを置いておきたいが、そのファイルの変更自体は管理しなくてよい場合にどうすればいいかをメモしておきます。

どんな状況か

そもそも、なんでこんなことが必要になったのかを簡単に書いておきます。
状況としては、Jiraにある未完了チケットを取得し、特定のものをチャットに飛ばす、というスクリプトを作っていました。
この時、前回実行時に取得したチケットのIDを保持するようにしていました。
これは、定期実行で動かしていて、最初に実行したときに未完了のものが、次に実行したときも未完了なチケットが通知されないようにするためのものです。
(そもそも、このチケットIDを記録するファイルは、もしかしたらGitに置いておかなくてもよいかもしれません)

さて、このような状態でチケットIDを記録していたファイルは、そこに存在してくれていればOKであり
ファイルの中身が実行されるたびにgitの変更差分として出てきてしまいます。
これは鬱陶しいですよね。
これを回避する方法をメモしておきます。

対応策

調べてみると、Gitさんは管理下にあるファイルの更新を無視するような設定をいくつか用意してくれていました。
ドキュメント：Git – git-update-index Documentation | https://git-scm.com/docs/git-update-index

assume-unchangedとskip-worktreeというものが、この状況に使えそうなものです。
それぞれの違いとしては、正確にはドキュメントを参照してほしいのですが、印象としては以下のように感じました。

• assume-unchanged
  • マージ、リセット等するとき、リポジトリの状態が正
• skip-worktree
  • マージ、リセット等するとき、手元の状態が正

今回の状況的には、リポジトリにおいてある内容に特に重要な意味はなく、手元の環境でIDがガシガシ更新されているので
手元の状態を保持してくれるskip-worktreeを設定しました。
git update-index --skip-worktree ファイル名

これにて、手元にあるファイルの更新をGit側で無視しつつ、マージ等で変更がある場合に上書きされないようにできました。
解決です。

検索時のメモ

今回、このような状況で検索するときになんというキーワードで検索すれば出てくるのかわかりませんでした。
そこで、適当に英単語を並べていく作戦をとってみました。
gitkeepで空フォルダをGitの配下にすることを知っていたので、「gitkeep file」とキーワードを検索欄に入力してみました。
すると、「gitkeep file but ignore changes」とサジェストしてくれました。
まさにほしい情報はこれです。
さすがはグーグル先生、感謝です。

何が言いたいかというと、ほしい状況は分かっているが、それをどう探せばいいかわからないとき
それっぽい単語をGoogle先生の検索欄に並べると、もしかしたらサジェストしてくれるかもしれません。
困ったときは、それっぽい単語をGoogle先生に並べてみましょう。

まとめ

今回は、Git管理下にあるファイルの変更を無視する方法をメモしました。
やはりというかなんというか、Gitさんはきちんとこういう状況の設定も用意してくれていました。

今回は、ここまで。
おしまい

こんにちは、しきゆらです。
今回は、タイトル通り非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を使ってサーバへデプロイする方法をメモしておきます。

こんにちは、しきゆらです。
今回は、久々に買った商品を紹介してみます。

だいぶ古い記事ですが、「【日記】iPod ClassicをBluetoothで無線化する」で無線デビューした私ですが
ここからBluetoothヘッドホンやイヤホンを使うようになりました。
煩わしい線がなく、音楽プレイヤーを携帯していればどこでも使えるためとても便利になりました。
(無線化する前は、部屋の中を移動できるように3mのケーブルでヘッドホンを使っていました・・・懐かしい)

こんにちは、しきゆらです。
気が付けば、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ですよ、と宣言しているので何度も参照することになるとは思いますが、まさか専用のメソッドが用意されているとは知りませんでした。

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

こんにちは、shikiyuraです。
今回は、タイトル通りMacでcronを使わずにコマンドを定期実行する方法をメモしておきます。

コマンドを定期実行するためによく使われるものは、cronだと思います。
私も、今回のことがなければ真っ先に思い浮かぶものはcronです。
Macにもcronはあるようですが、権限やOSのセキュリティの壁などにふさがれて気軽に動かせないようです。

参考

• macOS 10.15 catalina で crontab を使用する | 林檎コンピュータ | https://mac-ra.com/catalina-crontab/
• macOS Catalinaでcronが動いてくれなくなった | N-blog [ver. 3.0] | https://blog.n-function.com/806/

では、どうすればいいのか。
Macに入っているlaunchdというものを使えばいいのです。
launchdとは、デーモンとエージェントを管理してくれるものです。
Macの「ターミナル」でのlaunchdを使ったスクリプトの管理 – Apple サポート | https://support.apple.com/ja-jp/guide/terminal/apdc6c1077b-5d5d-4d35-9c19-60f2397b2369/mac

裏側で自動起動させたり、定期的にコマンド実行させたりすることも可能です。
では、こいつらを使ってcronの代わりに特定コマンドを定期実行できるようにしてみます。

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さんが動かないのかを調べつつ、解決方法が見つかったのでメモしておきます。

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

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

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

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

こんにちは、しきゆらです。
今回は、先日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で構築してもよさそう。
いい時代になりました。

さて、今回はここまで。

おわり

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

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