vscodeのphp用formatter

vscodeのphp用formatterはphp-cs-fixer がよさそう。

インストール手順はこちらで紹介されている。

コード 整形 PHP CS Fixer インストール - しすろぐ

が、若干ダウンロードの仕方が異なり、.vscodeの下では

wget https://cs.symfony.com/download/php-cs-fixer-v2.phar -O php-cs-fixer

とした。さらにphp-cs-fixerはphp-cs-fixer.pharとリネームした。

設定の編集内容も若干違い、CTRL+P → >json と打ったあとは下記のように入力した。

"php-cs-fixer.onsave": true, // 保存時に整形を実行
"php-cs-fixer.executablePath": "${extensionPath}/php-cs-fixer.phar", // php-cs-fixer-v2.pharの配置パス
"[php]": {
    "editor.defaultFormatter": "junstyle.php-cs-fixer" // defaultFormatterの指定
}

設定ファイルやデータファイルの拡張子を.cgiにして見られなくするテクニック

事実上レンタルサーバーでの利用を前提とした場合限定なのだが、データファイルの拡張子を実行ファイルの拡張子にしてユーザーから見られなくするテクニックがあった。

公開ディレクトリに見られてはいけないファイルを置くのがそもそも危険なのだが、レンタルサーバーによっては公開ディレクトリしかないサービスもあるのかもしれない。そういう時の苦肉の策として、こういうテクニックがあるのだろう。

感心してしまったが、専用サーバー（仮想も含め）を使えるなら、そもそも公開ディレクトリ外にデータファイルを置くだけだから問題ない。 また、今のレンタルサーバーはDBを使えることが多く、そちらを利用した方がずっといいとも言える。 今となってはノスタルジックなテクニックであるかもしれない。

Laravel8のScaffoldはLaravel Jetstreamらしい

Laravel Jetstreamがそうらしい。

  • LivewireかInertiaの選択肢があるが、Inertiaでよさそう。
    • InertiaはVueだそうなので。
    • LivewireはLaravel独自でこちらのほうが楽そうなのだが、Laravel8にロックインされるリスクを考えると手を出しづらい。
    • チーム機能なるものは今回不要ということでオプションもつけず。

install コマンドは下記。

cd /var/www/html/membership
composer require laravel/jetstream 
php artisan jetstream:install inertia
npm install
npm run dev
php artisan migrate

というわけでInertiaを軽く試してみたが、今回のやりたかったことに合わない。没。

  • もともと小さなサンプルプログラムなのでFrontendとBackendは一緒にする気だった。
  • Scaffold程度のために仕様が変わってしまうのはいくらなんでも困る。
  • 超リッチな追加フレームワークという印象。単にスキーマからCRUDのためのコードのたたき台を自動で生成するツールが欲しかっただけなので（C#のScaffoldみたいな）、これはちょっと。
  • そして”既存のプロジェクトに適用してはいけません”の注意書き通り、プロジェクト内のコードが大量に書き換えあるいは新規追加され大変なことに。いやgitで管理してるから戻せたけども。
    • これは本番で採用するならよっぽど注意しないとまずい印象。そして使わないと決めたら最後まで使わなくなることを理解しないといけない。

というわけで前言撤回、Livewireを使うことにした。こちらはこちらでやはり大量のファイルが追加される。

composer create-project laravel/laravel membership
cd membership
composer require laravel/jetstream
php artisan jetstream:install livewire
npm install
npm run dev

あとロックインがやはり怖い。フレームワークをアップグレードすることはそう頻繁ではないとはいえ。

Laravel: トランザクション境界

Laravel: 設計方針

※ まだ模索中

  • やはりUseCasesの中に置き、ここでDB::beginTransaction();→DB::commit();するしかなさそう。
    • リクエスト単位でのコネクションの維持が保たれているはず。できていなかったらコネクタを引き回す必要がある。
  • UseCasesに置くとDBクラスがUseCasesの中に紛れ込み、さりとてRepositoryの中に置くとロジックがRepositoryの中に入り込む。DBがロジックと保存の両方の仕組みを持つから仕方ないのだが、トランザクションは本当にレイヤアーキテクチャ泣かせ。

Laravel: DI

Laravel

使い方

  • LaravelのDIコンテナはサービスコンテナという名前。使い方は下記の通り。

    1. サービスプロバイダを作る（例: php artisan make:provider CommentServiceProvider ）。作ったファイルはApp/Providers以下に保存される。
    2. サービスプロバイダ内のregister()に$this->app->bind('インターフェイス名', 呼ぶオブジェクト);のように書いて登録。
    3. config/app.php内のプロパティ:providersに作成したサービスプロバイダを追記する。
    4. これでコンストラクタインジェクションが動作する。

  • ユニットテストのときにMockに切り替えたいときは、テストコードの中で指定するらしい。

    • つまり、設定ファイルを複数作って、テストのときはテスト用の設定ファイルを読んで、みたいなつくりではないみたい。

詳細はマニュアル参照