tmux 起動中に新規セッションを追加する方法
- プレフィックスキー (
C-b(Ctrl-b)) +:new
カテゴリー
カテゴリー: コンピューター
Linux の悪戦苦闘記、プログラミング、WordPress、ウェブサービス、Windows、Mac などの話題ですの。
まとめ
作ったもの
docker-compose コマンドだけで環境をうまく切り替える方法
docker-compose -fオプションを使うことで、使用する YAML ファイルを取捨選択できるようになった。これを利用して、開発環境用ではボリューム共有を使い、サーバ環境用では別のサービスを追加する、といったことが可能になる。docker-compose -fオプションで毎回 YAML ファイルを指定するのはとても手間がかかるが、解決することができる。Compose の設定に用いられる環境変数のデフォルト値を.envという 環境ファイル で行うことができる。このファイルにCOMPOSE_FILEという CLI 変数 を定義し、その値に使用する YAML ファイルを指定することで-fオプションを省略することができる。- Dockerfile のマルチステージビルド を使うことによって、複数の環境を一つの Dockerfile で表現することができる。
Visual Studio Code で開発環境コンテナも使う方法
- Visual Studio Code の Remote – Containers – Visual Studio Marketplace 拡張機能で実現する。
- コマンドパレットから "Remote-Containers: Add Development Container Configuration File…" を選んで設定ファイルを自動生成するのが楽。
.devcontainer/devcontainer.jsonが独自の設定ファイル。.devcontainer/docker-compose.ymlはただの Docker Compose ファイル。.devcontainer/devcontainer.jsonと.devcontainer/docker-compose.ymlの難しい箇所は本投稿の続きに記載した。
5.8. 行セキュリティポリシー を利用することで単一データベースかつ単一スキーマ方式を採用したマルチテナントアーキテクチャをより安全にすることができそうです。
実際にシステムやアプリに組み込む前に、 PostgreSQL の Row Level Security とはそもそもどのような物なのか、手を動かすことで体験いたしました。
本投稿では、その時の動きをまとめます。また、時間が経ってもう一度 PostgreSQL の Row Level Security をおさらいしたくなったり、新たに挙動を確かめたくなったりした時のために、すぐにお試しの環境を作れるように記録を残します。
Laravel7 で入力値そのものと入力値を分割した配列の両方を一度にバリデーションするためのルールの書き方 – oki2a24 を改善する話です。
ルールオブジェクトまとめ
公式ドキュメントに書いてあること
- ルールオブジェクトの使用 – カスタムバリデーションルールのメソッドを定義
php artisan make:rule <name>コマンドでapp/Rulesディレクトリに新しいルールオブジェクトのファイルを生成できる。passes($attribute, $value)メソッドでバリデーションを行う。$attribute: フォームの属性名$value: フォームに入力された属性値。これをバリデーションすることになる。
- フォームリクエストクラスの
ruleメソッでのルールオブジェクトの使用方法は、ルールを書く場所にインスタンス化すれば良い。そのため、ルールを書く際は文字列を|で区切るのではなく、配列で定義することになる。
公式ドキュメントに書いてないこと (こちらを本ページで扱う)
- クロージャの使用 – カスタムバリデーションルールのメソッドを定義 のみを使う場合、カスタムバリデーションルールが 2 つ以上になるとテスト時にどのクロージャがテストに該当するのかわからなくなる。そのため、クロージャを利用せずにルールオブジェクトのみを使うのも良いと思う。
- どうやらルールオブジェクトは 1 回のバリデーションで使ったオブジェクトをそのままエラーメッセージ出力時でも使うようだ。したがって、ルールオブジェクトクラスのコンストラクタやプロパティ (クラスのメンバ変数) を使って応用を効かせることができる。
passesメソッドで$attributeと$value以外の値を使いたい (例えばバリデーション時の判定に使う最大数とか) 場合は、ルールオブジェクトのコンストラクタで渡す。messageメソッドで例えばpassesメソッド内で出てきた値を使いたい場合は、passesメソッド内からプロパティに渡してやればよい。
ポイント
- フォーム値の事前加工 は使えない。なぜなら加工前の値もバリデーションしたいため。
- クロージャの使用 – カスタムバリデーションルールのメソッドを定義 し、その中でフォーム値を加工してバリデーションを行う。
- ただし、
rulesメソッド内に 2 つ以上のクロージャのルールが存在するとテスト時にどのクロージャがテストに該当するのかわからなくなる。そのため試してはいないが ルールオブジェクトの使用 – カスタムバリデーションルールのメソッドを定義 をした方が良いと思われる。 - 今回はクロージャの使用を押し通したため、テストではエラーメッセージを確認することでどのルールで不正となったかを確かめている。
- ただし、
- カスタムバリデーションルールのメソッド内では
'required','email:rfc,spoof'といったバリデーションルールを宣言できない。とはいえ該当するバリデーションロジックを書くのは車輪の再開発となり、おかしい。探すと、Illuminate\Validation\Concerns\ValidatesAttributesトレイトに各バリデーションルールの実装となっているのでこれをuseして利用する。
例。ユーザー削除時に連携するサービスも削除するイベント
実際に書いたコードから少し内容を変えており、実際に動かない可能性がありますことを最初にお断りします。エッセンスを伝えるためのコードとなります。
例えば、ログインに外部の OpenId Connect サービスを使う場合、今回は Google としましょうか。ユーザーを作成したときは Laravel の googles テーブルに連携時のデータを保存しているものとし、モデルでは user->google でアクセスできるものとします。
ユーザーを削除する時にイベントを実行し、リスナーで Laravel の google レコードを削除するとします。この時のリスナーの handle メソッドを、次のようにテストしました。
- ポイント。リスナーのテストのコツと言っても、リスナークラスをインスタンスかして handle メソッドを実行するだけ。アサートは実行した結果を確かめる。
- おまけポイント。 イベントリスナー DeleteGoogle クラスはコンストラクタで DI を行っている。この DI を自動的に行って欲しいので
appメソッドを使用した。 - おまけポイント。テストメソッド内でも、
appメソッドは普通に使える。 - おまけポイント。ファクトリの
statesメソッドで users レコード作成後に googles レコードも作成している。登録は、UserFactoryクラスでafterCreatingメソッドを使って行っている。
Docker イメージ php:7.4.5-apache で Apache の他に cron も動かす方法 – oki2a24 のcrond の実行ログを docker のログに出力するようにしたと思ったが出力されていない、という問題に対処できました。
ポイント
- 対象のプロセスのログを stdout や stderr へ出力しておくことが必要
- Supervisor の対象プロセスの設定で、ログを stdout や stderr へ出力するように設定
- どちらか一方ではダメで、対象プロセス自身のログと Supervisor の対象プロセスの設定の両方で stdout や stderr へ出力すること
関連したモデルの挿入、更新については公式ドキュメントに記述があります。
しかし、削除については言及されていません。
そこで、自分なりにたどり着いた最適な削除方法を残します。
まとめ
~/.config/starship.toml
[custom.vim]
command = "echo Vim"
when = """ test -n "$VIMRUNTIME" """
フォームリクエストバリデーション – バリデーション 7.x Laravel にあるように、バリデーションロジックを含んだカスタムリクエストクラスを作成して利用することはよくあります。
しかし、フォームリクエストをどうやってユニットテストすれば良いのかについては、 Laravel ドキュメントに記載がありません。
自分自身がさまざま調べ、現在行っているユニットテストの方法を記したいと思います。