開発ツール on ララジャパン

deployerで複数サイトを管理（２）タスクを定義

Wed, 15 Apr 2026 11:07:41 +0900

deployerの話の続きです。今回はユーザー定義のタスク（レシピとも言う）の話です。タスクはdeployerを使って対象のホストに入って実行できるコマンドです。ちなみに前回のdep run dateのrunはdeployerが定義したタスクです。

Laravelアプリをダウンさせるタスクを定義

このブログの読者はもちろんLaravelユーザーなので、そのアプリのダウンのコマンドをdeployerのタスクの例として定義します。

deploy.php

namespace Deployer;

import('hosts.yml');

desc('メンテナンスモードにする');
task('app:down', function () {
    cd('{{deploy_path}}');
    $secret = run('echo $RANDOM | md5sum | head -c 10'); // ランダムなキーを生成
    $result = run("php artisan down --secret=$secret");
    writeln($result);
});

上において、cd(’{{deploy_path}}’)は、hosts.ymlで定義したホストにおいてLaravelのアプリが存在するパス名です。つまり、まずそこへcdしてからphp artisan downを実行ということです。

前回定義した、hosts.ymlは以下です。

hosts.yml

hosts:
  production:
    hostname: www.larajapan.com
    remote_user: deployer
    deploy_path: ~/example

  staging:
    hostname: staging.larajapan.com
    remote_user: deployer
    deploy_path: ~/example

さきのタスクを実行すると、

$ dep app:down

Select hosts: (comma separated)
  [0] staging
  [1] production
 > 0
task app:down
[staging]
   INFO  Application is now in maintenance mode.

   INFO  You may bypass maintenance mode via [http://staging.larajapan.com/040538d125].

ここで大事なのは、上のphp artisan down –secret=の実行は、そこで与えられたシークレットキーを知るユーザーのみダウンしていない状態でLaravelのアプリへのアクセスを許します。今回のようにランダムな覚えにくいシークレットキーを生成すると、それをいちいちタイプするのは面倒ですよね。しかし、Laravelのdownコマンドは実行後にそのリンクを親切に出力してくれます。そのために、先のタスクの定義において、writeln($result)として画面に出力するのが重要となります。

タスクを強化

app:downのタスクは先に見せたように、ローカルから対象のマシンにsshを手動で実行することなく簡単にリモートで操作できてしまいます。その便利さは時には過ち実行も起きやすいということです。実行する前に確認のプロンプトも追加しましょう。 deployerでは、確認のプロンプトはaskConfirmation()の関数が使えます。

...
desc('メンテナンスモードにする');
task('app:down', function () {

   // 以下が追加した部分です。
    $host = currentHost()->getAlias();
    if (! askConfirmation("<comment>$host</comment>のホストをメンテナンスモードにしますか？", false)) {
        writeln('<error>実行はキャンセルされました.</error>');
        exit(1);
    }

    cd('{{deploy_path}}');
    $secret = run('echo $RANDOM | md5sum | head -c 10'); // ランダムなキーを生成
    $result = run("php artisan down --secret=$secret");
    writeln($result);
});

実行してみましょう。

Select hosts: (comma separated)
  [0] staging
  [1] production
 > 0
task app:down
[staging] stagingのホストをメンテナンスモードにしますか？ [y/N] n
[staging] 実行はキャンセルされました.
ERROR: Task app:down failed!

上では、小文字のnをタイプすることで実行をキャンセルできます。もちろん大文字のNでも同じです。ちなみに、[y/N]とNが大文字表示されているのは、デフォルトがNoということで、単にnやNをタイプせずにリターンキーを押すことでもキャンセルとなります。

確認のプロンプトを入れることで過ちの防止となりましたが、確認の上で実行としたときに、実行後に本当にアプリがダウンとなったか確かめたいですね。それは、php artisan aboutに表示されるMaintenance Modeの行を見ることで確認できます。

desc('メンテナンスモードにする');
task('app:down', function () {
    $host = currentHost()->getAlias();
    if (! askConfirmation("<comment>$host</comment>のホストをメンテナンスモードにしますか？", false)) {
        writeln('<error>実行はキャンセルされました.</error>');
        exit(1);
    }

    cd('{{deploy_path}}');
    $secret = run('echo $RANDOM | md5sum | head -c 10');
    $result = run("php artisan down --secret=$secret");
    writeln($result);

    //　以下でダウンされていか確認
    $result = run('php artisan about | grep -i maintenance');
    writeln($result);
});

実行してみましょう。

Select hosts: (comma separated)
  [0] staging
  [1] production
 > 0
task app:down
[staging] stagingのホストをメンテナンスモードにしますか？ [y/N] y
[staging]
   INFO  Application is now in maintenance mode.

   INFO  You may bypass maintenance mode via [http://localhost/3d895d8b57].
[staging]   Maintenance Mode ................................................... ENABLED

ENABLEDはメンテナンスモードとなって落ちているということで、実行は成功です。OFFと表示されていればダウンとならなかったということで異常が起こったということです。

deployerで複数サイトを管理（１）

Sat, 28 Mar 2026 07:19:49 +0900

同じLaravelのプログラムを複数のサイトにインストールしていると、いちいちそれらのサイトにsshしてプログラムの変更のインストール（デプロイ）が面倒になってきます。こんなときに、とっても助けとなるのがDeployer。今回はそのツールの紹介です。

Deployerのインストール

まず、Laravelのプロジェクトにdeployerをインストール。

$ composer require deployer/deployer --dev

インストール後に、vendor/bin/depが作成されます。このコマンドは頻繁に使用されるので、bashの初期設定のファイルに~/.bashrcに以下のようにエイリアスを入れて、

.bashrc

...
alias dep='vendor/bin/dep'
...

以下を実行します。

. ~/.bashrc

これで、コマンドラインでdepだけで実行できます。

Deployerの初期化

Deployerは、先のdepのコマンドを使用してタスクを実行するために、プロジェクトのルートディレクトリにdeployer.phpのファイルが必要です。そのファイルの作成には以下を実行します。

$ dep init

以下のように選択肢が表示され順に答えていきます。最後のHosts以外はデフォルト（括弧の中に表示されている）を選択しています。

Select recipe language [php]:
  [0] php
  [1] yaml
 > 

 Select project template [common]:
  [0 ] cakephp
  [1 ] codeigniter
  [2 ] codeigniter4
  [3 ] common
  [4 ] composer
  [5 ] contao
  [6 ] craftcms
  [7 ] drupal7
  [8 ] drupal8
  [9 ] flow_framework
  [10] fuelphp
  [11] joomla
  [12] laravel
  [13] magento
  [14] magento2
  [15] pimcore
  [16] prestashop
  [17] provision
  [18] shopware
  [19] silverstripe
  [20] spiral
  [21] statamic
  [22] sulu
  [23] symfony
  [24] typo3
  [25] wordpress
  [26] yii
  [27] zend_framework
 > 

 Repository [git@github.com:larajapan/example.git]:
 >

 Project name [example]:
 >

 Hosts (comma separated) []:
 > www.larajapan.com,staging.larajapan.com

Successfully created deploy.php

作成されたdeployer.phpは、

deployer.php

namespace Deployer;

require 'recipe/common.php';

// Config

set('repository', 'git@github.com:larajapan/example.git');

add('shared_files', []);
add('shared_dirs', []);
add('writable_dirs', []);

// Hosts

host('www.larajapan.com')
    ->set('remote_user', 'deployer')
    ->set('deploy_path', '~/example');
host('staging.larajapan.com')
    ->set('remote_user', 'deployer')
    ->set('deploy_path', '~/example');

// Hooks

after('deploy:failed', 'deploy:unlock');

上での設定は、・ depでsshでdeployerのユーザーとしてアクセス可能なホストが２つある。www.larajapan.comとstaging.larajapan.com ・どちらのホストもLaravelのアプリは、~/exampleのディレクトリにあるです。

deployer.phpは、もちろん手動で編集可能なので上の設定ではいくらでも変更が可能です。

複数のサイトにいっぺんにアクセス

準備ができたところ、早速以下を実行してみてください。

$ dep run date

ホストの選択肢が表示されます。１番目つまり0を選択するとそのホストへsshしてdateコマンドを実行します。

Select hosts: (comma separated)
  [0] www.larajapan.com
  [1] staging.larajapan.com
 > 0
[www.larajapan.com] Thu Mar 26 08:07:54 JST 2026

選択が面倒なら、コマンドラインでもホストを指定できます。

$ dep run date www.larajapan.com

さらに、長いホスト名のタイプが面倒なら、deployer.phpを編集して、ホストのエイリアスを指定できます。

// Hosts

host('production')
    ->setHostname('www.larajapan.com')
    ->set('remote_user', 'deployer')
    ->set('deploy_path', '~/example');
host('staging')
    ->setHostname('staging.larajapan.com')
    ->set('remote_user', 'deployer')
    ->set('deploy_path', '~/example');

とすれば、

$ dep run date production

と実行できます。

最後に、定義されている全部のサイトで実行したいなら、allを渡します。

$ dep run date all
[production] Thu Mar 26 08:12:02 JST 2026
[live] Thu Mar 26 08:12:04 JST 2026

便利ですね。

ホスト情報をYAMLファイルにする

ホストが２つくらいなら、deploy.php内でのホストの定義で十分ですが、これが10個もなると読みづらくなります。そのような場合は、ホストの定義をYAMLのファイルに抽出して分けることが可能です。

hosts.yml

hosts:
  production:
    hostname: www.larajapan.com
    remote_user: deployer
    deploy_path: ~/example

  staging:
    hostname: staging.larajapan.com
    remote_user: deployer
    deploy_path: ~/example

定義があった元の部分では、以下のようにimportに置き換えます。

deploy.php

// Hosts

import('hosts.yml');

整理されてすっきりしました。

開発のタスクを整理するためのツール

Wed, 17 Dec 2025 07:48:04 +0900

開発に関わるタスクとして手動で実行するコマンドは日に日に増える一方です。Laravelのシンプルなプロジェクトでも、コード作成後にはpint（コード自動整形ツール）、PHPStan（静的解析ツール）、そしてpest（テスト）を必ず実行します。また、ブラウザで動作チェックするために

ローカル環境を立ち上げるコマンドたち、さらに、gitのようなバージョン管理のためのコマンド実行もあります。問題はこれらのコマンドすべてを覚えるのは大変なのと、いくつかのコマンドは１つ１つタイプして実行するより、まとめて実行して簡素化もしたいです。つまり、タスクを整理するツールは必須です。今回はこれらのツールの紹介です。

開発に必要なタスクの種類

まず、私の開発環境をもとにして、どのようなタスクがあるかグループして整理してみます。

コード作成後に実行するタスク

コード自動整形ツール：pint、rector
静的解析ツール：phpstan
テストツール：phpunit、pest
バージョンコントロール：git commit, push, branch, mergeなど

ローカル開発環境を立ち上げるタスク

コンテナ―の立ち上げ：sail up
ウェブサーバー：php artisan server
CSSやスクリプトのビルド・ホットリロード：npm run dev

これらを実行して、ブラウザーでの動作確認が可能となります。

インストール作業のためのタスク

バージョンコントロール：git pull
ライブラリのインストール：　composer install
データーベース変更：php artisan migrate
キャッシュの作成：php artisan config:cache, event:cache, route:cache

他にも、ログのチェックのために単に、less storage/logs/laravel.logの実行とかもありますね。

さて、これらを整理するツールを紹介です。

composer

composerは基本的にはphpのプロジェクトで使用するパッケージを管理するコマンドですが、新規のLaravelプロジェクトをインストールすると、以下のように、composer.json内に"scripts"のセクションがあり、いくつかのタスクがグループされて実行を可能としています。

composer.json

{
...
   "scripts": {
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi"
        ],
        "post-update-cmd": [
            "@php artisan vendor:publish --tag=laravel-assets --ansi --force"
        ],
        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "@php artisan key:generate --ansi",
            "@php -r \"file_exists('database/database.sqlite') || touch('database/database.sqlite');\"",
            "@php artisan migrate --graceful --ansi"
        ],
        "dev": [
            "Composer\\Config::disableProcessTimeout",
            "npx concurrently -c \"#93c5fd,#c4b5fd,#fb7185,#fdba74\" \"php artisan serve\" \"php artisan queue:listen --tries=1\" \"php artisan pail --timeout=0\" \"npm run dev\" --names=server,queue,logs,vite"
        ],
        "test": [
            "@php artisan config:clear --ansi",
            "@php artisan test"
        ]
    },
...

例えば、

$ composer dev

を実行すれば、以下のコマンドを、

ウェブサーバーの起動：php artisan server
キューを継続的にモニター・処理：php artisan queue
ログをモニター：php aritsan pail
CSSやスクリプトのビルド・ホットリロード：npm run dev

皆いっぺんに並行実行します。以下は実行時のコマンド画面です。

つまり、composer.jsonのファイルを編集して、自由に必要なタスクのコマンドをグループ化して実行が可能というわけです。

npm

npmは、composerと違ってphpではなくjs関連のパッケージの管理ツールですが、composerと同様に、package.jsonに"script"のセクションがあり、先のようなグループタスクを以下のように設定が可能です。

{
    "private": true,
    "type": "module",
    "scripts": {
        "build": "vite build",
        "dev": "vite",
        "start": "concurrently -c \"#93c5fd,#c4b5fd,#fb7185,#fdba74\" \"php artisan serve\" \"php artisan queue:listen --tries=1\" \"php artisan pail --timeout=0\" \"npm run dev\" --names=server,queue,logs,vite"
    },
...

実行は、以下のコマンドとなります。

$ npm run start

make

C言語のプログラマー（昔は誰しもそうであった）ならとても馴染みのあるmakeコマンドは、タスクコマンドの整理にも使用できます。

makeの典型的な使用は、まずMakefileを作成して、そこでターゲットとソースコードの依存を指定し、それを作成するためのコマンドを記述します。

例えば、以下では、

Makefile

foo: foo.c
	cc foo.c -o foo

１行目は、ターゲットは実行可能なファイル、fooであり、その生成のためにC言語のソースコード、foo.cに依存することを示します。もし、foo.cがfooより古いあるいは存在しないなら、２行目以降に指定されたコマンドを実行します。そこでは、ccはＣのコンパイラーが記述されていて、-oで生成されるバイナリーのファイル名を指定されています。この２行目では必ず、行先頭にタブ文字を含むことが必要です。空白文字ではだめです。結構センシティブなので注意を。

この実行は、

$ make

となります。

さて、このMakefileでは、コンパイルでなくとも他のタスクの指定にも使うことが可能です。以下では、先のcomposer.jsonやpackage.jsonのように、ブラウザチェックのために必要なコマンドの起動を指定します。

Makefile

.PHONY: dev

dev:
	npx concurrently -c "#93c5fd,#c4b5fd,#fb7185,#fdba74" \
	"php artisan serve" \
	"php artisan queue:listen --tries=1" \
	"php artisan pail --timeout=0" \
	"npm run dev" \
	--names=server,queue,logs,vite

最初の.PHONY: devは、devが先のCソースコードのコンパイルの例とは異なりターゲットがファイルではないこと意味します。また、dev:の行は、ターゲット名のみであり、その依存元はありません。そして、続く行は実際に実行されるコマンドです。これはcomposerやnpmと同様です。しかし、バックスラッシュを使用して改行できたり、コマンドすべてを引用符で囲む必要もないので読みやすくできます。

私がmakeが好きなのは、開発のタスクの実行コマンドを、パッケージ管理が使用目的のcomposer.jsonやpackage.jsonから明確に分けることができること、そしてbashなどのシェルスクリプトでよく使われる変数、条件式、ループを取り入れることも可能です。、さらにLaravelで使用する.envも読み込むことも可能なことです。

例えば、.envと.env.exampleを比べて使う変数名に漏れがないか調べるには、Makefileを以下のように設定できます。

Makefile

include .env

ENV_EXAMPLE=`grep '=' .env.example | awk -F'=' '{ print $$1}' | sort -u`
ENV_ACTUAL=`grep -v '^\#' .env | grep '=' | awk -F'=' '{ print $$1}' | sort -u`

env:
	for i in $(ENV_ACTUAL); do \
		if ! grep -q "^$$i=" .env.example; then echo "not found $$i in .env.example"; fi; \
	done; \
	for i in $(ENV_EXAMPLE); do \
		if ! grep -q "^$$i=" .env; then echo "not found $$i in .env"; fi; \
	done

Rectorでリファクタリングを自動化　その３

Sun, 04 Aug 2024 06:58:49 +0900

以前にリファクタリングを自動化できるツール、Rectorを紹介しました。前回の記事ではRector側で用意された変換ルールに則ってリファクタする方法をお伝えしました。しかし、Rectorの真骨頂はむしろ自分で変換ルールを作成して各々の環境に合わせて自由にカスタマイズ出来る点にあります。直近の実務でそちらに触れる機会がありましたのでご紹介致します。

Rectorのインストール(おさらい）

前回の記事からだいぶ時間が経ってしまったのでプロジェクトにrectorをセットアップする手順からおさらいします。まず、以下でrectorをプロジェクトにinstallして下さい。

$ composer require rector/rector --dev

2024/08/03時点でversion 1.2.1がinstallされました。次に、初回実行して設定ファイルを作成します。

$ vendor/bin/rector

 No "rector.php" config found. Should we generate it for you? [yes]:
 > yes

rector.phpがルートディレクトリに作成されました。そちらの編集については後ほど解説致します。

自作ルールでリファクタリングを自動化

例えば、直近で私が携わった案件ではそれまで定数で管理していた値をPHP8.1の導入と共にEnumへ切り替えるリファクタをRectorで自作ルールを作成して行いました。今回はそちらのケースを例として紹介します。

定数をEnumに変換する

以下の様なモデルクラスがあったとします。

app/Models/Order.php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Factories\HasFactory;

class Order extends Model
{
    use HasFactory;

    // order status constants
    const ORDER_STATUS_ORDERED = 0;
    const ORDER_STATUS_SHIPPED = 1;
    const ORDER_STATUS_CANCELED = 2;

    protected $table = 'order';

    protected $primaryKey = 'order_id';

    protected $guarded = ['order_id', 'created_at', 'updated_at'];

    // キャンセルされた？
    public function isCanceled()
    {
        return $this->status === self::ORDER_STATUS_CANCELED;
    }

    // 売上として計上された注文
    public function scopeAsRevenue($query)
    {
        return $query->whereIn('status', [self::ORDER_STATUS_ORDERED, self::ORDER_STATUS_SHIPPED]);
    }

}

このクラスではorder_statusというプロパティの値を定数で管理しています。そして、それらを以下のOrderStatusというEnumに切り替えたいとします。

app/Enums/OrderStatus.php

namespace App\Enums;

enum OrderStatus: int
{
    case ORDERED = 1;
    case SHIPPED = 2;
    case CANCELED = 3;
}

具体的にはコードを以下の様に書き換えます。

self::ORDER_STATUS_CANCELED
↓
OrderStatus::CANCELED->value

カスタムルール作成

こちらの公式ドキュメントを参考に進めます。まず、カスタムルールを定義するクラスを作成します。

$ vendor/bin/rector custom-rule

// 作成するカスタムルール名を指定（ReplaceConstantToEnumValueとしました）
What is the name of the rule class (e.g. "LegacyCallToDbalMethodCall")?:
> ReplaceConstantToEnumValue

Generated files
===============

* utils/rector/tests/Rector/ReplaceConstantToEnumValueRector/Fixture/some_class.php.inc
* utils/rector/tests/Rector/ReplaceConstantToEnumValueRector/config/configured_rule.php
* utils/rector/src/Rector/ReplaceConstantToEnumValueRector.php
* utils/rector/tests/Rector/ReplaceConstantToEnumValueRector/ReplaceConstantToEnumValueRectorTest.php

[OK] Base for the "ReplaceConstantToEnumValueRector" rule was created. Now you can fill the missing parts

[OK] We also update composer.json autoload-dev, to load Rector rules. Now run "composer
dump-autoload" to update paths

[OK] We also update /***/rector/phpunit.xml, to add a rector test suite.
You can run the rector tests by running: phpunit --testsuite rector

実行が完了するとルートディレクトリにutilsディレクトリが作成されます。utilsディレクトリの構造は以下の様になっているはずです。

$ tree utils

utils
└── rector
    ├── src
    │   └── Rector
    │       └── ReplaceConstantToEnumValueRector.php
    └── tests
        └── Rector
            └── ReplaceConstantToEnumValueRector
                ├── ReplaceConstantToEnumValueRectorTest.php
                ├── Fixture
                │   └── some_class.php.inc
                └── config
                    └── configured_rule.php

composer.jsonにutils配下のクラスをオートロードする設定が追加されていますので反映させておきましょう。

$ composer dump-autoload

カスタムルールを定義

作成されたReplaceConstantToEnumValueRector.phpを編集してカスタムルールを定義していきましょう。このクラスにはデフォルトで３つのメソッドが定義されています。

getRuleDefinition()
getNodeTypes()
refactor()

１つずつ解説します。

getRuleDefinition()

こちらのメソッドではリファクタの前後でコードがどの様に変更されるか、を定義します。こちらのメソッドは他の開発者がルールを理解しやすくする為です。また、ドキュメントを作成する際に使える様ですが、そちらはまだ深掘りしていないので今回は割愛します。getRuleDefinition()は以下の様に実装しました。

utils/rector/src/Rector/ReplaceConstantToEnumValueRector.php

...
    public function getRuleDefinition(): RuleDefinition
    {
        return new RuleDefinition('Replace Constant to Enum', [
            new CodeSample(
                // BEFORE
                <<<'CODE_SAMPLE'
ORDER_STATUS_ORDERED
CODE_SAMPLE
                ,
                // AFTER
                <<<'CODE_SAMPLE'
OrderStatus::ORDERED->value
CODE_SAMPLE
            ),
        ]);
...

getNodeTypes()

こちらはリファクタの対象となるnodeを指定するメソッドです。nodeとはソースコードの構成要素の事で、クラスやメソッド、変数、条件式などです。Rectorはソースコードをnodeから成るツリー構造（AST）として解析し、nodeを操作する事でコードを変換しています。指定可能なnodeはこちらにまとめられています。例えば、今回は定数を操作したいのでClassConstFetch::classを指定します。

utils/rector/src/Rector/ReplaceConstantToEnumValueRector.php

...
    /**
     * @return array<class-string<Node>>
     */
    public function getNodeTypes(): array
    {
        // select node type
        return [ClassConstFetch::class];
    }
...

今回はClassConstFetchのみですが、複数指定する事も可能です。ここで指定したnodeがfetchされ次に解説するrefactor()の引数に渡されます。

refactor()

fetchしたnodeに変更を加えてコードをリファクタします。まず、引数で渡された$nodeがどういうものなのか見てみましょう。refactor()内にeval(\Psy\sh())を挿入してrectorを実行してみると以下の様に出力されました。（rectorの実行方法については後で解説します。）

From utils/rector/src/Rector/ReplaceConstantToEnumValueRector.php:48:
    46:     public function refactor(Node $node): ?Node
    47:     {
  > 48:         eval(\Psy\sh());
    49: 
    50:         $constName = $this->getName($node->name);
> $node
= PhpParser\Node\Expr\ClassConstFetch {#24984
    +class: PhpParser\Node\Name {#24985
      +parts: [
        "self",
      ],
    },
    +name: PhpParser\Node\Identifier {#24986
      +name: "ORDER_STATUS_CANCELED",
    },
  }

getNodeTypes()で指定した通り、ClassConstFetchクラスのインスタンスが代入されていますね。ここでfetchしたnodeはself::ORDER_STATUS_CANCELEDに当たる部分なので、クラス名部分がself、変数名部分がORDER_STATUS_CANCELEDとしてそれぞれclass, nameプロパティから辿れます。それによって、更にリファクタしたい対象を絞り込む事ができます、以下の様に。

utils/rector/src/Rector/ReplaceConstantToEnumValueRector.php

...
    /**
     * @param ClassConstFetch $node
     */
    public function refactor(Node $node): ?Node
    {
        $constName = $this->getName($node->name);

        // ORDER_STATUS_* の場合のみリファクタ
        if (Str::startsWith($constName, 'ORDER_STATUS_')) {
            // リファクタ処理
        }

        return $node;
    }
...

$this->getName($node->name)の部分で変数名部分を取得し、それがORDER_STATUS_から始まるならリファクタ処理を実行、としました。

次にリファクタ処理を実装します。リファクタ処理はOrderStatus::XXX->valueを表現するnodeを新たに作成して返却します。nodeの作成は$this->nodeFactoryのメソッドをcallして行います。（実行可能なメソッドはRector\PhpParser\Node\NodeFactoryをご覧ください。）以下の様に実装しました。

utils/rector/src/Rector/ReplaceConstantToEnumValueRector.php

...
    /**
     * @param ClassConstFetch $node
     */
    public function refactor(Node $node): ?Node
    {
        $constName = $this->getName($node->name);

        // ORDER_STATUS_*
        if (Str::startsWith($constName, 'ORDER_STATUS_')) {
            // ORDER_STATUS_以降を取得
            $case = Str::after($constName, 'ORDER_STATUS_');

            // OrderStatus::XXX のnodeを作成
            $constFetch = $this->nodeFactory->createClassConstFetch('App\\Enums\\OrderStatus', $case);

            // OrderStatus::XXX にvalueプロパティを参照させる（OrderStatus::XXX->value）
            return $this->nodeFactory->createPropertyFetch($constFetch, 'value');
        }

        return $node;
    }
...

これでカスタムルールの作成が完了です。

リファクタ実行

最後にrector.phpを設定してリファクタを実行してみましょう。rector.phpは以下の様に設定しました。

rector.php

declare(strict_types=1);

use Rector\Config\RectorConfig;
use Utils\Rector\Rector\ReplaceConstantToEnumValueRector;

return RectorConfig::configure()
    ->withPaths([
        __DIR__ . '/app/Models/Order.php',
    ])
    ->withRules([
        ReplaceConstantToEnumValueRector::class,
    ])
    ->withImportNames();

withPaths()にてリファクタを適用するファイルを指定、withRules()にて適用するルールを指定しています。また、OrderStatusが完全修飾名となっているのでwithImportNames()を追加して名前空間をインポート（use App\Enums\OrderStatus;を追加）するようにしています。これでrectorを実行してみます。実際にリファクタを適用する前にコードがどの様に変化するのか、dry runで確認してみましょう。

$ vendor/bin/rector --dry-run        
 1/1 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%
1 file with changes
===================

1) app/Models/Order.php:1

    ---------- begin diff ----------
@@ @@

 namespace App\Models;

+use App\Enums\OrderStatus;
 use Illuminate\Database\Eloquent\Model;
 use Illuminate\Database\Eloquent\Factories\HasFactory;

@@ @@
     // キャンセルされた？
     public function isCanceled()
     {
-        return $this->status === self::ORDER_STATUS_CANCELED;
+        return $this->status === OrderStatus::CANCELED->value;
     }

     // 売上として計上された注文
     public function scopeAsRevenue($query)
     {
-        return $query->whereIn('status', [self::ORDER_STATUS_ORDERED, self::ORDER_STATUS_SHIPPED]);
+        return $query->whereIn('status', [OrderStatus::ORDERED->value, OrderStatus::SHIPPED->value]);
     }

 }
    ----------- end diff -----------

Applied rules:
 * ReplaceConstantToEnumValueRector
                                                                                                                        
 [OK] 1 file would have been changed (dry-run) by Rector

差分を見ての通り、self::ORDER_STATUS_XXXだった箇所がOrderStatus::XXX->valueに変換されていますね。問題なさそうなのでdry runオプションを外して実行します。

$ vendor/bin/rector

以下が変換後のOrder.phpです。

app/Models/Order.php

namespace App\Models;

use App\Enums\OrderStatus;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Factories\HasFactory;

class Order extends Model
{
    use HasFactory;

    // order status constants
    const ORDER_STATUS_ORDERED = 0;
    const ORDER_STATUS_SHIPPED = 1;
    const ORDER_STATUS_CANCELED = 2;

    protected $table = 'order';

    protected $primaryKey = 'order_id';

    protected $guarded = ['order_id', 'created_at', 'updated_at'];

    // キャンセルされた？
    public function isCanceled()
    {
        return $this->status === OrderStatus::CANCELED->value;
    }

    // 売上として計上された注文
    public function scopeAsRevenue($query)
    {
        return $query->whereIn('status', [OrderStatus::ORDERED->value, OrderStatus::SHIPPED->value]);
    }

}

変換後のファイルを見ると定数の定義部分が残っていますね。こちらもまた別のカスタムルールを作成して削除できます。こうして１つずつ作業を棚卸ししてRectorのカスタムルールを作成していく事で膨大なリファクタ作業を大幅に短縮させる事が可能です。是非試してみて下さい。

参照

Rectorでリファクタリングを自動化　その１ Rectorでリファクタリングを自動化　その２

【mac】phpbrewで複数のバージョンを切り替えて使う

Tue, 27 Jun 2023 03:30:18 +0900

個人で色々試したいものがある時に最新のPHPが必要となる事が多々あります。そんな時、今まではHomebrewで両方のversionをインストールして環境変数のパスを手作業で切り替えていましたが、正直面倒です。今回はPHPBrewを使ってそんな面倒が解消されるか試してみます。今回の記事は私の作業環境であるmacOSでの話となります、ご承知ください。

PHPBrew

前々からPHPBrew自体は知っていましたが、ローカルには既にHomeBrewで複数のversionがインストールされていいた為、試してはいませんでした。今回、Laravel10.xのインストールを試すのにPHP8.1以上が必須となった為、そちらのインストールに使用してみます。

READMEに書いてありますが、PHPBrewは異なるPHPのversionをホームディレクトリ配下（macだと~/.phpbrew/php配下）にビルドしインストールするツールです。PHPBrewはバージョン毎にディレクトリを分けてインストールする為、それぞれが独立しており、管理や使用するバージョンの切り替えが容易となる様です。恐らくバージョン切り替え時は単に参照のパスを書き換えているのでしょうね。これは期待大です。

OSのサポート

PHPBrewはUnix系のOSでサポートされているようです。今回紹介するのはmacOSでの手順ですが、他にもLinuxのディストリビューション（Ubuntu, Debian, RHEL, Fedoraなど）でも使えるようです。

install

早速、試してみましょう。まず、install前にRequirementから各OSごとに事前にinstallが必要なパッケージ等が書いてあるのでチェックします。macOSの場合はHomebrewが必要との事でした。私の環境には既にinstallされているので飛ばします。

次にcurlでphpbrewをダウンロードし、/usr/local/bin配下に配置します。

curl -L -O https://github.com/phpbrew/phpbrew/releases/latest/download/phpbrew.phar

# chmodで実行権限を付ける
chmod +x phpbrew.phar

# /usr/local/bin 配下にphpbrewとして設置
mv phpbrew.phar /usr/local/bin/phpbrew

/usr/local/bin配下はパスが通っているので、以下のようにどこからでも呼び出せるようになったはずです。

which phpbrew
>>> /usr/local/bin/phpbrew

次に、phpbrewを初期化します。

phpbrew init

初期化が完了すると $HOME/.phpbrew 配下に必要なファイルが生成されます。

ls ~/.phpbrew
>>> bashrc          build           php             phpbrew.fish

Terminal起動時に必要な機能を読み込ませる為に、.bashrc または .zshrc に以下の行を追記します。（私の環境では.zshrcに追記した）

~/.zshrc

[[ -e ~/.phpbrew/bashrc ]] && source ~/.phpbrew/bashrc

追記後にsourceコマンドで.zshrcから設定を読み直しましょう。

source ~/.zshrc

最後にライブラリ探索用のプレフィックスをセットしてinstall完了です。これをセットしないとライブラリが見つからない旨のエラーが沢山出てしまいます。

phpbrew lookup-prefix homebrew

PHPbrewを使ってPHPをインストール

phpbrewの準備ができたところで任意のVersionのPHPをインストールしてみましょう。今回はPHP8.1をインストールします。まず、インストール可能なPHPのバージョンを確認します。

phpbrew known
>>>===> Fetching release list...
Downloading https://www.php.net/releases/index.php?json=1&version=8&max=100 via curl extension
Downloading https://www.php.net/releases/index.php?json=1&version=7&max=100 via curl extension
8.2: 8.2.7, 8.2.6, 8.2.5, 8.2.4, 8.2.3, 8.2.2, 8.2.1, 8.2.0 ...
8.1: 8.1.20, 8.1.19, 8.1.18, 8.1.17, 8.1.16, 8.1.15, 8.1.14, 8.1.13 ...
8.0: 8.0.29, 8.0.28, 8.0.27, 8.0.26, 8.0.25, 8.0.24, 8.0.23, 8.0.22 ...
7.4: 7.4.33, 7.4.32, 7.4.30, 7.4.29, 7.4.28, 7.4.27, 7.4.26, 7.4.25 ...
7.3: 7.3.33, 7.3.32, 7.3.31, 7.3.30, 7.3.29, 7.3.28, 7.3.27, 7.3.26 ...
7.2: 7.2.34, 7.2.33, 7.2.32, 7.2.31, 7.2.30, 7.2.29, 7.2.28, 7.2.27 ...
7.1: 7.1.33, 7.1.32, 7.1.31, 7.1.30, 7.1.29, 7.1.28, 7.1.27, 7.1.26 ...
7.0: 7.0.33, 7.0.32 ...

最新は8.2までありますね、古いバージョンは7.0まで指定できる様です。インストール可能なリストに8.1も含まれているので、次のコマンドでインストールします。ビルドに時間が掛かるようで、私の環境では15分ほど掛かりました。

phpbrew install 8.1 +default +dbs +apxs2

8.1の最新のバージョンをインストールしたいので、マイナバージョン（8.1.XのX部分）は指定しませんでした。 Versionの後に指定している+default +dbs +apxs2というのはバリアントと呼ばれるものです。

バリアント

バリアントとは、通常のPHPをビルド・インストール際に指定するオプションを抽象化したものです。DBのドライバであったり、opensslなどのライブラリであったり、PHPで有効にしたい機能をオプションとして指定できます。バリアント無しだと最小構成でインストールされます。+defaultだとよく使われるバリアントがまとめてインストールされます。また、今回のインストールではDB（mysql）を使用する為の+dbs、Apache2を使用する為の+apxs2を追加で指定しました。以下のコマンドで、指定可能なバリアントが確認できます。

phpbrew variants
>>>
Variants: 
  all, apxs2, bcmath, bz2, calendar, cgi, cli, ctype, curl, dba, debug, dom, 
  dtrace, editline, embed, exif, fileinfo, filter, fpm, ftp, gcov, gd, 
  gettext, gmp, hash, iconv, imap, inifile, inline, intl, ipc, ipv6, json, 
  kerberos, ldap, libgcc, mbregex, mbstring, mcrypt, mhash, mysql, opcache, 
  openssl, pcntl, pcre, pdo, pear, pgsql, phar, phpdbg, posix, readline, 
  session, soap, sockets, sodium, sqlite, static, tidy, tokenizer, wddx, 
  xml, xmlrpc, zip, zlib, zts


Virtual variants: 
  dbs: sqlite, mysql, pgsql, pdo
  mb: mbstring, mbregex
  neutral: 
  small: bz2, cli, dom, filter, ipc, json, mbregex, mbstring, pcre, phar, 
  posix, readline, xml, curl, openssl
  default: bcmath, bz2, calendar, cli, ctype, dom, fileinfo, filter, ipc, 
  json, mbregex, mbstring, mhash, pcntl, pcre, pdo, pear, phar, posix, 
  readline, sockets, tokenizer, xml, curl, openssl, zip
  everything: dba, ipv6, dom, calendar, wddx, static, inifile, inline, cli, 
  ftp, filter, gcov, zts, json, hash, exif, mbstring, mbregex, libgcc, 
  pdo, posix, embed, sockets, debug, phpdbg, zip, bcmath, fileinfo, ctype, 
  cgi, soap, pcntl, phar, session, tokenizer, opcache, imap, ldap, tidy, 
  kerberos, xmlrpc, fpm, dtrace, pcre, mhash, mcrypt, zlib, curl, readline, 
  editline, gd, intl, sodium, openssl, mysql, sqlite, pgsql, xml, gettext, 
  iconv, bz2, ipc, gmp, pear

+defaultには以下が含まれている様です、

default: bcmath, bz2, calendar, cli, ctype, dom, fileinfo, filter, ipc, 
  json, mbregex, mbstring, mhash, pcntl, pcre, pdo, pear, phar, posix, 
  readline, sockets, tokenizer, xml, curl, openssl, zip

話をインストールに戻します。installコマンドが完了したらlistコマンドでインストール済みのバージョン一覧に表示されるか確認しましょう。

phpbrew list
>>>
* (system)
  php-8.1.20

アスタリスク（*）が付いているのが現在使用中のバージョンです。(system)はHomebrewでインストールしたシステムデフォルトのバージョン（8.0.28がインストールされています）の事です。PHPBrewによって php-8.1.20 がインストールされた様ですね。このバージョンに切り替えるにはuseコマンドで指定します。

phpbrew use php-8.1.20

バージョンが切り替わったか、確認してみましょう。

php -v
>>>
PHP 8.1.20 (cli) (built: Jun 20 2023 21:18:43) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.20, Copyright (c) Zend Technologies

8.1.20 になりましたね。尚、このままでは一度Terminalを再起動するとまたシステムデフォルトの8.0.28に戻ってしまいます。PHPBrewでインストールしたPHPをデフォルトで使用するにはswitchコマンドで指定します。

phpbrew switch php-8.1.20

逆にPHPBrewの使用をやめてシステムデフォルトに戻したい場合は

phpbrew switch-off

それまでに使用していた環境も残しつつ、別バージョンをインストールして試せるのは安心感があって良いですね。

まとめ

以上、PHPBrewのインストールから基本的な操作の解説でした。Homebrewでも複数のバージョンをインストールして切り替える事は可能でしたが、冒頭で書いたように手動で切り替えが必要な部分があります。最近L10.xの検証などでバージョンを切り替える頻度が多いため、コマンド一発で切り替えられるPHPBrewは重宝しそうです。

Rectorでリファクタリングを自動化　その２

Fri, 12 May 2023 00:50:55 +0900

前回の記事ではRectorを使ってプロジェクト内の古い記法を書き換える手順を紹介しました。書き換えたい記法が１つの場合は前回の解説で十分だと思いますが、例えば、PHPのアップグレードに合わせて新たに導入された記法をまとめて適用したい、という場合は Set Lists を使うのがオススメです。今回はそちらの手順を紹介します。

Set Lists

セットリストはいくつかのルールをトピック別にグループ化したものです。例えば設定ファイルを以下の様に書き換えると、PHP8.0で導入された記法をまとめて適用することができます。

rector.php

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;
use Rector\Set\ValueObject\SetList;

return static function (RectorConfig $rectorConfig): void {

    // app 配下のみを対象にする
    $rectorConfig->paths([
        __DIR__ . '/app',
    ]);

    // PHP8.0で導入された変更を適用する
    $rectorConfig->sets([SetList::PHP_80]);
};

指定可能なセットリストは以下です。

https://github.com/rectorphp/rector/blob/main/packages/Set/ValueObject/SetList.php

PHPバージョン別に導入された記法であったり、コーディングスタイルであったり、デッドコードであったり、色々ありますね。

各セットリストで適用される変更はRules OverviewのCategoriesから確認できます。

Level Sets

PHPのバージョンアップ用にLevel Set Listというセットリストも用意されています。これは、指定したバージョン以前のruleもまとめて適用したい場合に使えます。例えば、前項のサンプルコードの様に、

$rectorConfig->sets([SetList::PHP_80]);

とした場合はPHP8.0のruleのみ適用されますが、PHP7.2, 7.3, 7.4 のruleもまとめて適用したい場合は

$rectorConfig->sets([LevelSetList::UP_TO_PHP_80]);

とすれば変更に含まれます。

一部のruleを無視する

ruleをまとめて適用できるセットリストは便利ですが、プロジェクトによってはセットリストに含まれる１部のruleを除外したいケースがあるかもしれません。その場合は以下の様にskip()を使って除外したいruleを指定します。

例えば、以下のように変更するとswitch文をmatch文に変更するルールが無視されます。

rector.php

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;
use Rector\Set\ValueObject\LevelSetList;
use Rector\Php80\Rector\Switch_\ChangeSwitchToMatchRector;

return static function (RectorConfig $rectorConfig): void {

    // app 配下のみを対象にする
    $rectorConfig->paths([
        __DIR__ . '/app',
    ]);

    // PHP8.0で導入された変更を適用する
    $rectorConfig->sets([LevelSetList::UP_TO_PHP_80]);

    // switch -> match への変更を無視する
    $rectorConfig->skip([
        ChangeSwitchToMatchRector::class,
    ]);
};

まとめ

いかがでしたでしょうか。

普段PHPのバージョンを上げる際は廃止される記法の書き換えはmustで行いますが、新しい記法の導入には慎重になりがちです。

その理由の１つに、書き換えた結果どれ位コードが良くなるか分からないから、というのがあります。

しかし、Rectorを活用することで取り敢えず書き換えてみる、その上で取り入れるかどうか検討してみる、といった事もできそうです。

参照

Rectorでリファクタリングを自動化　その１ Rectorでリファクタリングを自動化　その３

Rectorでリファクタリングを自動化　その１

Mon, 01 May 2023 01:30:18 +0900

前回紹介したmatch式や Constructor Property Promotion のように新しい記法が導入されることでボイラープレートが駆逐されコードがより簡潔に読みやすくなります。しかし、長年運用されているプロジェクトなどでは書き換え必要な箇所が多く、導入するのに及び腰になってしまいがちです。Rectorを使うことでそんな億劫な作業が一瞬で完了するかもしれませんよ。

Rectorとは？

About Rectorより

「Rector」とは、どんなPHPプロジェクトでも実行可能なPHPツールであり、瞬時にアップグレードや自動リファクタリングを実行できます。

という事で、まさにPHP8から導入されたsyntaxで書き換えたい、という私の要求にマッチしています。それらを自動で行なってくれるなら大助かりです。

現時点（2023/04/22）で ver 0.15.23 が最新で実行にはPHP7.2以上が必要となっています。

どんなツールか早速使って体感してみましょう。

インストール

新しく作成したLaravelのprojectにてインストールしました。

composer require rector/rector --dev

すると vendor/bin/rector が追加されます。

vendor/bin/rector --version
>> Rector 0.15.25

設定ファイルを追加

次に設定ファイルを（rector.php）プロジェクトに追加します。

vendor/bin/rector init

// rector.php を作成するか問われるので yes とタイプ
No "rector.php" config found. Should we generate it for you? [yes]:
> yes

[OK] The config is added now. Re-run command to make Rector do the work!

プロジェクトのルートディレクトリに rector.php が作成されました。デフォルトでは以下の状態です。

rector.php

<?php

declare(strict_types=1);

use Rector\CodeQuality\Rector\Class_\InlineConstructorDefaultToPropertyRector;
use Rector\Config\RectorConfig;
use Rector\Set\ValueObject\LevelSetList;

return static function (RectorConfig $rectorConfig): void {
    $rectorConfig->paths([
        __DIR__ . '/app',
        __DIR__ . '/bootstrap',
        __DIR__ . '/config',
        __DIR__ . '/lang',
        __DIR__ . '/public',
        __DIR__ . '/resources',
        __DIR__ . '/routes',
        __DIR__ . '/tests',
    ]);

    // register a single rule
    $rectorConfig->rule(InlineConstructorDefaultToPropertyRector::class);

    // define sets of rules
    //    $rectorConfig->sets([
    //        LevelSetList::UP_TO_PHP_80
    //    ]);
};

リファクタリングしたいパスは

$rectorConfig->paths([...]);

にて指定できます。

また、適用したい変更をruleとして指定します。

$rectorConfig->rule(InlineConstructorDefaultToPropertyRector::class);

// 複数のruleをまとめて指定するならrules
$rectorConfig->rules([
    InlineConstructorDefaultToPropertyRector::class,
    InlineIfToExplicitIfRector::class
]);

Rectorで扱うリファクタリングは主に記法の統一なので、「こういう時はこう書きましょう」というルールを定めるイメージですね。

Rules Overview にて指定可能なルールがまとめられていますので、ご確認を。

実践

前回紹介した Constructor Property Promotion についてリファクタリング可能か試してみましょう。

まず、以前の記事で使用した例と同じ Person.php を app/Models/ 配下に作成します。

app/Models/Person.php

<?php

namespace App\Models;

class Person
{
    public string $name;
    public int $age;
    public string $sex;
 
    public function __construct(string $name, int $age, string $sex)
    {
        $this->name = $name;
        $this->age = $age;
        $this->sex = $sex;
    }
}

次に、rector.php を以下のように書き換え設定します。

rector.php

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;
use Rector\Php80\Rector\Class_\ClassPropertyAssignToConstructorPromotionRector;

return static function (RectorConfig $rectorConfig): void {

    // app 配下のみを対象にする
    $rectorConfig->paths([
        __DIR__ . '/app',
    ]);

    // Constructor Property Promotion を適用するruleを追加
    $rectorConfig->rule(ClassPropertyAssignToConstructorPromotionRector::class);
};

Constructor Property Promotion に書き換えるruleはこちらにありました。

準備が整ったので書き換えてみましょう。まずは–dry-runを付けて実行します。

vendor/bin/rector process --dry-run

–dry-runではコード自体は変更されません。変更前後の差分が表示されるので、それを見て意図通りの変更が適用されるか事前確認します。

1 file with changes
===================

1) app/Models/Person.php:3

    ---------- begin diff ----------
@@ @@

 class Person
 {
-    public string $name;
-    public int $age;
-    public string $sex;
- 
-    public function __construct(string $name, int $age, string $sex)
+    public function __construct(public string $name, public int $age, public string $sex)
     {
-        $this->name = $name;
-        $this->age = $age;
-        $this->sex = $sex;
     }
 }
    ----------- end diff -----------

Applied rules:
 * ClassPropertyAssignToConstructorPromotionRector (https://wiki.php.net/rfc/constructor_promotion https://github.com/php/php-src/pull/5291)



 [OK] 1 file would have changed (dry-run) by Rector

意図通りの変更が施されていますね。問題無かったので今度は–dry-runオプションを省いて実行します。

vendor/bin/rector process

Person.php がリファクタリングされ以下となりました。

app/Models/Person.php

<?php

namespace App\Models;

class Person
{
    public function __construct(public string $name, public int $age, public string $sex)
    {
    }
}

まとめ

長くなってしまったのでRector導入編、ということで一旦ここで切ります。今回の記事では掘り下げられなかったSet Listsについては次回以降の記事で紹介できればと思います。

今回は解説用なので１ファイルのみのリファクタリングとなりましたが、大きいプロジェクトであれば数十数百のファイルにコマンド一発で変更が適用されるので記法を置換する際にはとても便利なツールだと思います。

また、今回は古い記法を置換する目的で触ってみましたが、例えばチームで開発している際に以前に紹介されたpintなどと同様にコードスタイルを統一する目的でも活用できるのでは、と思います。

参照

Rectorでリファクタリングを自動化　その２ Rectorでリファクタリングを自動化　その３

光速のVite

Sun, 30 Oct 2022 07:08:54 +0900

ここ1年位で良く聞くようになったVite。Vue.jsの生みの親であるEvan Youさん開発、との事なので、 Vue.jsとの親和性が高いのだろうな、と。Laravel + Vue.js のスタックで開発する機会があれば使ってみたいな、と。私の中ではその程度の位置付けでした。

しかし、今年の６月、Laravel 9.2.0のリリース時のTaylerさんの以下のツイートを見て、認識を改めました。

Today we're pumped to announce that new Laravel projects use Vite to bundle frontend assets. Breeze and Jetstream have been updated as well. 🔥

Experience lightning fast Hot Module Replacement when using the new Breeze / Vite stack with Inertia Vue or React. ⚡
— taylor otwell 🪐 (@taylorotwell) June 28, 2022

光速のHMR。。。是非使ってみたい！

Viteが採用された理由

従来のLaravelはアセットバンドラにwebpackをラップしたLaravel-Mixを使うのが一般的でした。この決定を知った時、私はViteについて冒頭に述べた程度の認識だったので、

「なぜViteに変えるの？Laravel-Mixの何がダメなの?」と、思いました。因みに、同様の質問がTwitterで投げられており、Taylerさんがシンプルに

“much faster(断然速いから)"と答えていました。

この業界においてスピードは正義ですから、より速いツールが開発されたら導入しない理由はないですよね。でも何がどう速いのでしょうか？もっと知りたくなり調べてみました。

調べていく内に、Laravel-MixとViteは全く別物、ということが分かってきました。

Laravel-Mixの問題点

Viteが速いということは、Laravel-Mixが遅いという事ですが、具体的にどの部分が遅かったのでしょうか？

従来のLaravelの開発ではnpm run devを実行すると、resources配下から必要なアセットファイル（cssやjsなど）をかき集め、依存関係を解決しつつ１ファイルにまとめるという処理が行われていました。アセットバンドルについてはlaravel-mixでフロントエンドを開発にてkhino氏が詳しく解説しているので是非ご一読下さい。

開発者のアクションとしては、

jsファイルを変更する
npm run dev を実行しアセットをバンドル（ビルドともいう）する
ビルドした成果物をブラウザで確認する

といった感じです。

プロジェクト規模が大きくなりファイル数が多くなるとバンドル処理に時間が掛かり、開発効率が落ちてしまいます。私のようにjsをふりかけ程度にしか使っていない場合は大したこと無いですが、VueでSPAを開発している場合などは、上記のフローを高頻度で繰り返し開発するため、変更〜確認までにラグがある事は大きなストレスになります。

Viteはノーバンドル

ではViteはどうなのか？

公式ページに詳しく書いてありますが、Viteは開発サーバにおいて基本バンドルしません。パッケージやライブラリなど開発者が基本変更しないようなファイルは事前バンドルされるのですが、開発者が頻繁に変更するソースコードについてはバンドルせずブラウザに提供するのです。

最近のブラウザはES6で導入されたモジュール機能(import, export)に対応しており、ブラウザが表示するページに必要なモジュールを把握しそれらをimportしてくれます。そして、開発者がファイルを編集した際はViteがその変更を把握し、変更されたモジュールのみ再読み込みしてくれるのです。

アセットのバンドルも無ければ、リロード範囲も最小限な為、前項で問題とした変更〜確認までのラグというのが最小限に抑えられるという訳です。

Viteを体感してみる

冒頭のTaylerさんのTweetにある通り、Laravel 9.2.0 以降ではViteがフロントエンドのデフォルトビルダとして採用されており、npm run devを実行するとViteがHMRモードで起動します。

HMRとはHot Module Replacementの略でコードを変更し保存するとページのリロード無しでブラウザに変更が反映されます。

驚いたのは、保存してからブラウザに反映されるまでの速さです。文字通り一瞬で全くラグを感じませんでした。Vite恐るべし。

本番用にはバンドルする

開発時においてはバンドルせずにアセットを提供する事で開発者をハッピーにしてくれるViteですが、本番においてはバンドルした方がハッピーな様です。

なぜなら、ノーバンドルでアセットを提供した場合、ブラウザが逐次必要なモジュールをネットワーク経由で取得する必要があり非効率だからです。通常ネットワーク経由でデータを取得する際、細切れになったデータをロードするよりも、それらを１つにまとめてロードした方が効率的なのです。

開発時においてそれが問題にならないのは取得するデータが全てローカルに存在し、ネットワーク経由で取得する必要が無い為です。

まとめ

長く（と言っても数年）Laravel-Mixを使って開発していると、ついアセットはバンドルするもの、という固定観念に縛られがちですが。開発時は敢えてバンドルせず、ブラウザ側で出来ることはブラウザに任せよう、という思い切った試みがパズルのピースのように完璧にバチッとはまっており、改めて素晴らしい発明だなぁ、と思いました。Evan Youさん、あっぱれです。

Laravel Pintをカスタム設定

Wed, 21 Sep 2022 11:35:58 +0900

私らの開発環境が最近やっとphp 8.0となりましたので、Laravel Pint（ピント）なるものを使ってみました。正式にLaravelの開発チームから登場したコードスタイル整形のツールですが、なんのことはない、Larajapanでも以前から数回紹介したphp-cs-fixerを土台にしたLaravel版です。しかし、より簡単になりました。

以前に紹介したのは、「コードスタイルを統一するツール」です。ここでも、同様な醜い(Ugly Class）のコードを用意して、Laravel Pintを紹介しましょう。

インストール

Laravelのプロジェクトのルートのディレクトリにおいて、以下を実行します。

$ composer require laravel/pint --dev

開発環境でしか必要ないので、最後の引数–devは忘れないように。

実行

実行もいたって簡単です。php-cs-fixerと違って、コード整形のためのルールの設定はまったく要りません。完全にLaravel用にデフォルト設定になっています。

$ ./vendor/bin/pint
 ......................................................

 ───────────────────────────────────────────────────────────────── Laravel
 PASS   ....................................................... 54 files

もちろん、何も変えてないのでエラーはゼロでPASSです。

今度は、前回作成したUglyクラスのファイルを追加して、

namespace App\Models;

use Log;
use Illuminate\Database\Eloquent\Model;
use DB;

class Ugly extends Model
{
	public function test ($x, $y)
	{

if ($x == 1)
{
	//
} else if ($y == 2) { /* */ }

	}
}

再度実行すると、

$ ./vendor/bin/pint
  .....................................................✓.

  ───────────────────────────────────────────────────────────────── Laravel
    FIXED   ................................. 55 files, 1 style issue fixed
  ✓ app/Models/Ugly.php indentation_type, elseif, braces, function_declara…

しっかり、修正（FIXED）されて、

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Ugly extends Model
{
    public function test($x, $y)
    {
        if ($x == 1) {
    //
        } elseif ($y == 2) { /* */
        }
    }
}

綺麗に整形されました。

カスタム設定

Laravel Pintは、デフォルトで完全にLaravelのコードスタイルとしてくれます。しかし、ちょっとだけ私がカスタマイズしたい部分があります。

コードにおけるオブジェクトの表示です。私は以下のように、=>で項目を揃えたいのです。

	protected $rules = [
		'cost'       => 'required|integer|min:0',
		'cost_ship'  => 'required|integer|min:0',
		'cost_other' => 'required|integer|min:0',
		'commission' => 'required|numeric|min:0',
	];

しかし、これをpintで実行すると、

    protected $rules = [
        'cost' => 'required|integer|min:0',
        'cost_ship' => 'required|integer|min:0',
        'cost_other' => 'required|integer|min:0',
        'commission' => 'required|numeric|min:0',
    ];

となってしまいます。もちろんそれがLaravelのデフォルトのスタイルなのですが。

これを強制しないようにするには、設定ファイルが必要となります。以下のファイル(pint.json）をプロジェクトのルートディレクトリに置きます。

pint.json

{
    "preset": "laravel",
    "rules": {
        "binary_operator_spaces":{"default":"single_space","operators":{"=>":null}}
    },
    "exclude": [
        "bootstrap",
        "src"
    ]
}

上のrulesのルールは、以下のphp-cs-fixerで使用するものと同じです。 https://mlocati.github.io/php-cs-fixer-configurator/#version:3.11|fixer:binary_operator_spaces

しかし、そこでの設定はphpの配列となります。以下のように。

    'binary_operator_spaces' => [
        'default' => 'single_space',
        'operators' => ['=>' => null],
    ],

pintツールは、phpなのになぜか設定ファイルはjsonフォーマットです。ということで、tinkerで以下のように変換して、pint.jsonに入れる必要あります。

>>> json_encode(['binary_operator_spaces' => [
        'default' => 'single_space',
        'operators' => ['=>' => null],
    ]]);
=> "{"binary_operator_spaces":{"default":"single_space","operators":{"=>":null}}}"

Laravel 8.x更新で変わったこと（４）php-cs-fixer

Wed, 17 Nov 2021 13:00:34 +0900

Laravel 8とは直接は関係ないのですが、以前ここで紹介したコード整形プログラムのphp-cs-fixerもバージョンアップとなりました。それにより使用していたその設定ファイルも変更の必要あります。

php-cs-fixerはコードを整形するプログラムで、開発者がひとりでももちろんですが複数となったときに特にコードのスタイルの統一に便利です。スタイルの指定、例えばインデントをタブでなく４つの空白文字とする、とかの指定は、すべてphp-cs-fixerの設定ファイルで行います。

まず、バージョン3となって、その設定ファイルとキャッシュファイル名が以下のように変更となりました。

バージョン２では、

.php-cs
.php-cs.cache

がバージョン３では、

.php-cs-fixer.php
.php-cs-fixer.cache

また、スタイル指定のルールも少し変更があります。Laravelのプロジェクトのために、以前と同様に以下のスレッドから取得して

https://gist.github.com/laravel-shift/cab527923ed2a109dda047b97d53c200

私のgistとしました。この記事の最後に掲載したのでフリーで使用してください！

設定のルールに関しては以下に説明あります。調査が必要なら参考に。

https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/master/doc/rules/index.rst

php-cs-fixerの使用はいたって簡単です。

新規に使用するなら、まず

$ composer require friendsofphp/php-cs-fixer --dev

を実行してインストールし、設定ファイル.php-cs-fixer.phpを私のgistから作成して、Laravelのプロジェクトのルートディレクトリから以下を実行すれば、必要な整形を自動でしてくれます。

$ vendor/bin/php-cs-fixer fix

以下がLaravelのプロジェクト用の設定ファイルです。

メールの送信（３）メール受信サービス　Mailhog

Sun, 10 Jan 2021 13:03:22 +0900

前回紹介したMailtrapに比べて機能は劣りますが、十分代わりとなるしかもオープンスース（つまり無料）のMailhogの紹介です。このプログラムと知り合ったのは、Laravelの最新バージョン8のsailのパッケージで使用されていたからです。sailはDockerを使用して簡単に開発環境を作成できる素晴らしいものなのですが、Dockerの１つのコンテイナーとしてMailhogがインストールされます。sailの紹介は別の機会として、今回は単独でのインストールです。

インストール

まず、Mailhogはphpで作成されたプログラムでなく、Goの言語で書かれコンパイルされたバイナリのプログラムです。

以下がソースコードのレポジトリです。

https://github.com/mailhog/MailHog

しかし、ソースコードをコンパイルするやっかいなことは必要でありません。すでにコンパイルされたバイナリを以下からダウンロードできます。

https://github.com/mailhog/MailHog/releases/v1.0.0

この最新のリリースはもう３年以上も前なのは少し気になりますが、上のリンク先の画面の下方にOSごとのバイナリのダウンロードリンクがあります。

ここでは、私のFedoraの仮想環境でLinuxバージョンを選択します。

これをダウンロードして、mailhogと改名して/usr/local/binに移します。また、chmodを実行して適切なパーミッションを与えます。

# mv MailHog_linux_386 /usr/local/bin/mailhog
# chmod 755 mailhog

次にコマンドラインで、mailhogを実行します。このリンク先のようなスクリプトを作成して、OSのサービスとして立ち上げてもOKです。

$ mailhog 
2021/01/07 08:42:42 Using in-memory storage
2021/01/07 08:42:42 [SMTP] Binding to address: 0.0.0.0:1025
[HTTP] Binding to address: 0.0.0.0:8025
2021/01/07 08:42:42 Serving under http://0.0.0.0:8025/
Creating API v1 with WebPath: 
Creating API v2 with WebPath:

これでMailhogがメールを受信できる準備ができました。

Laravelの環境変数の設定

Laravelのプロジェクトでは、.envを編集して以下のようにメール送信の設定をします。

...
MAIL_MAILER=smtp
MAIL_HOST=0.0.0.0
MAIL_PORT=1025
MAIL_USERNAME=null
MAIL_PASSWIRD=null
MAIL_ENCRYPTION=null
MAIL_FROM_ADDRESS=test@example.com
MAIL_FROM_NAME=test
...

MailTrapのような設定ですが、PortやEncryptが違うことに注意を。

メール送信テスト

準備が整ったところで、tinkerでまずテキストメールを送信

$ php artisan tinker
Psy Shell v0.10.4 (PHP 7.2.24 — cli) by Justin Hileman
>>> Mail::raw('Hello', function($m) { $m->subject('hello')->to('test@example.com'); });
=> null
>>>

ブラウザを開いて、http://localhost:8025にアクセスすると、以下の画面が表示されます。

メール届いていますね！

メールの中身も閲覧できます。

今度は、アプリからHTMLのメールを送信します。

いいですね。ちゃんと表示されています。

さて、HTMLソースはどうでしょう。

う～ん。Quoted-printableがそのままです。例えば、上の画面の青背景は、「確認」の日本語なのですがこれじゃ読めません。もちろん、メールをファイルとしてダウンロードしてOutlookでHTMLソースを見ることが可能ですが、ちょいと不便です。

ここの部分残念ですが、自分のメールアカウントを使用せずに開発のテストとしては十分と思います。無料であることを考えたら、なおさら。

最後に、先のmailhogのプログラムの実行を停止したら、デフォルトではメモリにメールを保存なので受信したメールはすべて消えてしまいます。それが嫌なら、mongodbにメールを保存するオプションもあります。

メールの送信（２）メール受信サービス　Mailtrap

Sun, 03 Jan 2021 03:20:18 +0900

LaravelのマニュアルのMailのセクションでは、Mailtrapというサービスが紹介されています。開発中はGmailのアドレスの送信すればいいものの、なにゆえに必要なのか疑問を持っていました。しかし、先日LaravelのNotificationのHTMLメールでHTMLのタグがどう使われているかチェックするのに困ったことがあり、Mailtrapのサービスを使用してみました。

Mailtrapのようなサービスの必要性

これ考えてみましょう。開発では、これが意外と理由あるのです。

まず、通常使用している自分のメールアカウントに開発サイトから送信されるメールを一緒にしたくありません。しかも、テストのために何回も何回もプログラムからメールを送信して、いつもそれらを読んだ後削除するから、Gmailなどは学習して勝手にスパムあるいはゴミ箱に入れてしまいます。いちいちゴミ箱を見るのも面倒です。

それなら、メールフィルターで送信元で仕分ければとか、違うGmailアカウントを作成すれば、とか言われそうです。

しかし、開発では、１つのプロジェクトで複数の届け先のテストが必要なときがあります。例えば、違う会員で違う内容の送信となるときでは、違うメールアドレスでのテストが必要です。そうなら、いくつものフィルターの設定やメールアカウントが必要となり、いちいち設定が面倒なのです。

また、HTMLメールだと、特にLaravelでは最近マークダウンとかコンポーネントとか使用していて、最終的に生成されるメールのHTMLがどうなるかをチェックしたいときがあります。しかし、HTMLだとQuoted-printableのフォーマットであるし、Gmailでオリジナルのデータを見ても通常のHTMLとは違うのでわけがわからないのです。こんな感じです。

ということで、これらの開発者が直面する問題を解決すべく、このようなサービスがあるわけです。

サインアップ

英語版しかないのですが、まずサインアップ。アカウントは、メールアドレスとパスワードだけで作成可能です。GoogleやGithubなどのアカウントがすでにあるならそれを通してログインしてもOKです。

無料版なのでチャージされることないので心配ないです。

Laravelの環境変数の設定

以下の画面で、Laravelを選択したら、.envにそのままコピーできる環境設定を表示してくれます。

Mailtrapのインボックス

さっそく、メールを送信してみます。Laravelで会員登録完了時に送信されるメールアドレス確認のメールです。HTMLのメールです。

見れましたね。どのメールアドレスに送信してもmailtrapのInboxに入ります。

中身のHTMLソースを見てみましょう。

これなら、通常のブラウザで見るHTMLソースと同じようです。つまり読めます。並んでいるタブの「Raw」をクリックして比べてみてください。

無料はいつまで？

この時点においては、無料版は1ヶ月500通までの受信OKで、~~3ヶ月まで~~永遠に無料です。有料のプランとしては、月9ドルから始まります。

コードスタイルを統一するツール

Sat, 05 Dec 2020 01:09:45 +0900

一緒に働くプログラマが増えると、まず気づくのは他のプログラマのコードのスタイルが自分とは違うことです。みなそれぞれ独自のスタイルとなる理由付けがあるのですが、ある程度統一されないと他者にとってコードを理解するのに時間がかかるようになります。しかし個人の慣習を変えてもらうのはいつも難しい。そこで登場するのが、以前にも紹介したコードスタイル修正のツール、php-cs-fixer。最近そのLaravel用のルールセットを見つけたので、それを合わせて再紹介です。

インストール

Laravelのプロジェクトのルートのディレクトリにおいて、以下を実行します。

$ composer require friendsofphp/php-cs-fixer --dev

開発環境でしか必要ないので、最後の引数–devは忘れないように。

次に、ルールセットの設定です。先に「Laravel用のルールセットを見つけた」と書きましたが、それは、私がよく使うLaravelアップグレードの有料サービス、Laravel Shiftのクリエイターが作成したものです。以下のgistで取得できます。彼のサービスでもこれが使われています。

https://gist.github.com/laravel-shift/cab527923ed2a109dda047b97d53c200

これをコピペして、.php_csのファイルを作成します。

実行

実行はいたって簡単です。

$ vendor/bin/php-cs-fixer fix
Loaded config default from "/vol1/usr/www/repos/repos/l7x/.php_cs".
Using cache file ".php_cs.cache".
   1) app/Http/Controllers/Auth/RegisterController.php
   2) app/Http/Middleware/CheckForMaintenanceMode.php
   3) routes/web.php

Fixed all files in 0.108 seconds, 14.000 MB memory used

fixの引数は、修正の実行を指示します。そして修正されたファイルが修正後にリストされます。

どんな修正が行われるかの一例として、以下のようなファイルを作成してみました。

namespace App;

use Log;
use Illuminate\Database\Eloquent\Model;
use DB;

class Ugly extends Model
{
	public function test ($x, $y)
	{

if ($x == 1)
{
	//
} else if ($y == 2) { /* */ }

	}
}

思い切って醜いコードにしました。

まず、修正を実行するまえに–dry-runでどの修正ルールが適用されるかをチェックします。

$ vendor/bin/php-cs-fixer fix --dry-run -vv
Loaded config default from "/vol1/usr/www/repos/repos/l7x/.php_cs".
Runtime: PHP 7.2.16
Using cache file ".php_cs.cache".
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSF
Legend: ?-unknown, I-invalid file syntax (file ignored), S-skipped (cached or empty file), .-no changes, F-fixed, E-error
   1) app/Ugly.php (indentation_type, blank_line_after_opening_tag, elseif, function_declaration, braces, ordered_imports)

Checked all files in 0.050 seconds, 14.000 MB memory used

上で指摘されているのは、修正時に適用するルールセットのことです。説明すると、

indentation_type：表示では見えないですが、タブ文字が使われてるところあります。タブを空白文字に変換必要。
blank_line_after_opening_tag：namespaceの宣言の前には改行が必要。
elseif：else ifでなくelseifを使用に変換必要。
function_declaration：関数名と引数名の間のスペースの削除が必要。
braces：ブレース（波括弧）の場所がおかしいので修正必要。
ordered_imports：インポート(use)の宣言がABC順でないので揃える必要あり。

これらのルールのすべては以下で説明あります。

https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/2.16/doc/rules/index.rst

たくさんありますね。使用したいルールは、先の.php_csで設定するのですが、たくさんあるゆえに、Laravel Shiftのクリエーターから拝借というわけです。

さて、修正した結果は以下のようになりました。

namespace App;

use DB;
use Illuminate\Database\Eloquent\Model;
use Log;

class Ugly extends Model
{
    public function test($x, $y)
    {
        if ($x == 1) {
            //
        } elseif ($y == 2) { /* */
        }
    }
}

読みやすくなりました。

最後に、拝借した.php_csの設定ですが、私が気に入らない部分がひとつありました。

それは、phpdoc_summaryのルールです。

修正前：

/**
 * これはテスト
 */
class Ugly extends Model
{
...

修正後：

/**
 * これはテスト.
 */
class Ugly extends Model
{
...

ようく見ると、修正後には「これはテスト.」とコメントの最後にピリオドが入ります。つまり句点がないので親切にも追加されます。ちなみに、句点(。)だとピリオドはつきません。

これが余計なお世話と思うなら、.php_csのファイルにおいて、以下のように無効とできます。

...
    'phpdoc_summary' => false,
...

最後に、.php_cs_cacheが実行時に作成されるので、これは.gitignoreに含むことをお忘れずに。

Laravelへの移行（３）管理画面のスターターパッケージ　Laravel-AdminLTE

Sun, 06 Sep 2020 01:17:16 +0900

前回に引き続いて、Laravelを使用したBootstrapの管理画面のスターターパッケージの紹介です。いかに新規のプロジェクトの管理画面を速く立ち上げるかが目的です。前回は、Core UIをベースにしたパッケージでしたが、今度は、Admin LTEをベースにしたものです。両方ともBootstrapのバージョン４をもとにしています。

インストール

Laravel Boilerplateでは、Laravelそのものも含むzipファイルをダウンロードしてインストールという形式でしたが、Laravel-AdminLTEでは、まずLaravelのプロジェクトをコマンドラインで作成してから、Laravel-AdminLTEのパッケージjeroennoten/laravel-adminlteをcomposerでプロジェクトにインストールします。その際には、依存するパッケージalmasaeed2010/adminlteもインストールされます。 almasaeed2010/adminlteのパッケージがAdmin LTEの無料版のCSSフレームワークで、jeroennoten/laravel-adminlteのパッケージがLaravelのプロジェクトにおいて、管理画面のbladeファイル、レイアウト設定やメニューなどの機能を提供します。

ルック

残念ながらLaravel-Admin LTEのデモサイトがないのですが、以下のような感じです。

ログイン画像

管理画面画像

config/app.phpで設定が必要ですが、日本語も対応しています。

Admin LTEに関しては、こちらでいろいろなUIを閲覧できます。

設定

Laravel Boilerplateと比べて、デフォルトでインストールされている機能は少ないですが、以下のベーシックなレイアウトの設定が独自のconfig/adminlte.phpのファイルから簡単にできます。

タイトル
ファビコン
ロゴ画像
ユーザーメニュー
これは、画面右上のログインしたユーザー名（ここではkenji）をクリックしたときの表示。

レイアウト

例えば、上の画面の設定では、固定のナビバーとフッターを指定しています。

  'layout_topnav' => null,
  'layout_boxed' => null,
  'layout_fixed_sidebar' => false,
  'layout_fixed_navbar' => true,
  'layout_fixed_footer' => true,

認証の画面表示のCSSクラス
body、content、sidebar、topnavなどのcssクラス
サイドバーのルック
ユーザーのプロフィールやダッシュボードやログアウトなどのURL
Laravel MIXの使用
サイドバーのメニューの指定
配列で指定できます。階層もOKです。以下は上のメニューの設定の一部。
```
                                    
```
style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;">'menu' => [ [ 'text' => 'search', 'search' => true, 'topnav' => true, ], [ 'text' => 'blog', 'url' => 'admin/blog', 'can' => 'manage-blog', ], [ 'text' => 'pages', 'url' => 'admin/pages', 'icon' => 'far fa-fw fa-file', 'label' => 4, 'label_color' => 'success', ], ['header' => 'account_settings'], [ 'text' => 'profile', 'url' => 'admin/settings', 'icon' => 'fas fa-fw fa-user', ], [ 'text' => 'change_password', 'url' => 'admin/settings', 'icon' => 'fas fa-fw fa-lock', ], [ 'text' => 'multilevel', 'icon' => 'fas fa-fw fa-share', 'submenu' => [ [ 'text' => 'level_one', 'url' => '#', ], style="color:#f92672">...


サイドバーのメニューのフィルター。権限によりメニューのオン・オフが可能となります。
プラグイン。datatablesやselect2などのjsの指定。


これら設定は、以下の場所で詳細がドキュメントされています。
https://github.com/jeroennoten/Laravel-AdminLTE#6-configuration
採用できそう？
気に入ったのは、基本的な設定が簡単にconfigファイルで行えることです。また、Laravel Boilerplateと違って、独立したパッケージとして提供されているので、将来のパッケージの更新の面では管理しやすいと思います。



Laravelへの移行（２）管理画面のスターターパッケージ　Laravel Boilerplate
Sun, 30 Aug 2020 09:32:09 +0900
前回ではセッションを共有することで、現行のPHPのプログラムと新規のLaravelのプログラムの行き来が可能となりました。もう現行に縛られることはないので、新規の画面のルックも最新のレスポンシブ対応のBootstrapを取り入れてみます。管理画面の移行を前提に、Laravelを使用したBootstrapの管理画面のスターターパッケージをいくつか紹介します。今回はLaravel Boilerplateをご紹介します。
デモ
Laravel Boilerplateは、現在Laravel6.xと7.xの２つのバージョンがあります。
ウェブサイトは、https://laravel-boilerplate.com/index.html
デモサイトがあるので早速見てみましょう。
https://demo.laravel-boilerplate.com/login
以下の情報でログインできます。
管理者:
User: admin@admin.com
Password: secret
ユーザー:
User: user@user.com
Password: secret
ログイン画面は、

管理者としてログインすると管理画面となりますが、以下はそのユーザー管理画面、

とちょっと日本語変だけれど日本語にも対応しています。
ルックは、以下のBoostrapバージョン４対応のCore UIを使用しています。これを見るといろいろなことができそうでワクワクしますね。
追加されたcomposerのパッケージ
インストールして標準装着されている機能をチェックしたいなら、composer.jsonを見るのが手っ取り早いです。
以下は、Laravel 7.xのデフォルトのcomposerのrequireのセクションです。
...
    "require": {
        "php": "^7.2.5",
        "fideloper/proxy": "^4.2",
        "fruitcake/laravel-cors": "^1.0",
        "guzzlehttp/guzzle": "^6.3",
        "laravel/framework": "^7.0",
        "laravel/tinker": "^2.0",
        "laravel/ui": "^2.1"
    },
...
以下は、Laravel boilerplateの同様なセクションです。
...
   "require": {
        "php": "^7.2.5",
        "albertcht/invisible-recaptcha": "^1.9",
        "arcanedev/log-viewer": "7.x",
        "darkghosthunter/laraguard": "^2.0",
        "fideloper/proxy": "^4.2",
        "fruitcake/laravel-cors": "^2.0",
        "guzzlehttp/guzzle": "^6.3",
        "jamesmills/laravel-timezone": "^1.9",
        "lab404/laravel-impersonate": "^1.6",
        "langleyfoxall/laravel-nist-password-rules": "^4.1",
        "laravel/framework": "^7.22.4",
        "laravel/socialite": "^4.3",
        "laravel/tinker": "^2.0",
        "laravel/ui": "^2.0",
        "livewire/livewire": "^1.0",
        "rappasoft/laravel-livewire-tables": "^0.1",
        "rappasoft/lockout": "^2.1",
        "spatie/laravel-activitylog": "^3.14",
        "spatie/laravel-permission": "^3.11",
        "tabuna/breadcrumbs": "^1.0"
    },
...
いくつか追加されたパッケージを紹介すると、


arcanedev/log-viewer

Laravelのログも含めて、作成されたログファイルを管理画面でログのメッセージのレベルにマッチした色付きで閲覧できるようです。



darkghosthunter/laraguard

「2ファクタ認証」のパッケージです。最初から必要でないかもしれないですが、オプションとしてあるのはいいですね。



lab404/laravel-impersonate

これは管理者があたかもユーザーになりすますためのパッケージです。すでにLaravelにその機能あったような。



rappasoft/laravel-livewire-tables

これは以前紹介したjqueryのdatatablesのlivewire版です。



spatie/laravel-activitylog

こちらは以前紹介した、DBの変更履歴記録と同様なパッケージです。



spatie/laravel-permission

これは上に掲載したユーザー管理の画面において、それぞれのユーザーにロール（役割）を割り当てるためのパッケージです。それにより、ログインした管理者がどの画面にアクセスが可能かを操作します。結構なパッケージです。



tabuna/breadcrumbs

このブログでいつか紹介しようと思っていたのですが、パンくず表示のための、とても有名な、https://github.com/davejamesmiller/laravel-breadcrumbsパッケージがありました。しかし、残念なことに作者の都合で今年更新ストップとなりました。しかし、嬉しいことに、違うプログラマがそれをもとに新たなパッケージを作成したのがこれです。まだ使用したことありませんが、いつか紹介したいです。


追加されたnode-jsのパッケージ
今度は、jsのパッケージの方を見てみます。
composerと同様に、laravel 7.xでは、
...
    "devDependencies": {
        "axios": "^0.19",
        "bootstrap": "^4.0.0",
        "cross-env": "^7.0",
        "jquery": "^3.2",
        "laravel-mix": "^5.0.1",
        "lodash": "^4.17.13",
        "popper.js": "^1.12",
        "resolve-url-loader": "^3.1.0",
        "sass": "^1.15.2",
        "sass-loader": "^8.0.0",
        "vue-template-compiler": "^2.6.11"
    }
...
Laravel Boilerplateでは、
...
    "devDependencies": {
        "@coreui/coreui": "^3.0.0",
        "@coreui/icons": "^1.0.1",
        "@fortawesome/fontawesome-free": "^5.12.1",
        "@popperjs/core": "^2.0.6",
        "alpinejs": "^2.3.5",
        "axios": "^0.19",
        "bootstrap": "^4.5.0",
        "cross-env": "^7.0",
        "jquery": "^3.5.1",
        "laravel-mix": "^5.0.1",
        "lodash": "^4.17.19",
        "perfect-scrollbar": "^1.5.0",
        "popper.js": "^1.16.1",
        "resolve-url-loader": "^2.3.1",
        "sass": "^1.20.1",
        "sass-loader": "^8.0.0",
        "sweetalert2": "^9.8.2",
        "vue": "^2.5.17",
        "vue-template-compiler": "^2.6.10"
    }
...
こちらも追加されたパッケージを見てみましょう。

@coreui/coreui、@coreui/icons

テンプレートとして使用しているCore UIのパッケージです。なるほどnpmで管理するのですね。アイコンも1500以上あるようです。ちなみに、Core UIを使用しているのは、管理者画面の部分のみです。


@fortawesome/fontawesome-free

これは非常に有名なアイコンのライブラリです。有料版もありますが、ここでは無料版を使用です。先の、Core UIのアイコンと合わせて膨大な数のアイコンから選択可能となります。


alpinejs
こちらはLivewireの作者のjsフレームワークです。日本語のマニュアルもありますね。


sweetalert2
こちらは、jsのalert()のベターバージョンのようですね。興味あります。


さて、これ採用できそう？
機能が盛りだくさん、というのが印象です。しかし使いこなすには、彼ら独自のディレクトリの構造（Domainなど）があり、すべて理解する必要あり時間がかかりそうです。かと言って、要らない機能のパッケージを外して簡単化するのは、影響する部分を考えると難しそうだし。
また、resources/viewsのディレクトリの構造やその中のbladeファイルを見ると、コンポーネントとか使用してとてもフレキシブルにしていますが、細分化しすぎの感がありこれまた理解に時間がかかりそうです。また、多言語対応なので、国際的なプロジェクトの作成には良いかもしれませんが、日本語だけしか必要ないとなると複雑すぎです。
あと、管理画面のメニューを管理する機能があればよいのですが、残念ながらありません。
これを採用するかどうかは別として、知らないパッケージがどう使われているかはとても参考になりそうで、時間かけて理解するのは価値はあります。ということで次回は違うLaravelのスターターパッケージ（？）を見てみます。


Let's Encrypt　無料のセキュア認証
Sun, 05 Jul 2020 02:00:43 +0900
このブログサイトのように、自分でサーバー(AWS EC2）を持ち、サイトをセットアップしていると、いろいろと出費があります。AWSのサービスに対してのお金とともに、昨今のウェブセキュリティ強化ゆえに、セキュア認証の取得にも年に１回出費があります。
今年はなぜかその認証の日までに業者からの催促のEメールも来ずに、リマインダーのためのカレンダーにも入れていなかったおかげで、認証が期限切れとなっていると知らず。次の日に朝にサイトにアクセスすると「安全な接続ではありません！」の警告画面となってしまいました。
これはいかん、と慌てたのですが、これはいいチャンス、巷で有名な無料のLet’s Encryptやらを試して見ようではないか、となりました。インストールのツールもあり便利そうです。

Let's Encrypt
Let’s Encryptは、もとMozzila（Firefoxブラウザで有名な）の社員が2014年から始めた事業なのですが、Let’s Encryptがどれだけ有名かというと、今年の２月の時点で、なんと10億サイトにセキュア認証がインストールされています。
ウェブサイトにセキュア認証をインストールするには、通常、プライベートキーやCSRをコマンドで作成して、Digicertのような会社に認証してもらい、SSL証明書が発行され、それをウェブサーバーにインストールします。面倒なうえに認証まで待つ必要もあり時間がかかり、しかも有料です。しかし、Let’s Encryptでは、それらの作業をすべて自動化したCertbotという便利なツールがあり、意外と簡単です。
Let’s Encryptのセキュア認証のインストールをこれから説明しますが、ここでの話は私の環境、つまりAmazon Linux（Amazon Linux 2ではない）で、ウェブサーバーにはapacheを使用という限定された環境での話なので、注意してください。
Certbotをインストール
Certbotのサイトへ行くと、どのウェブサーバー、どのSystemという選択があり、それぞれにおいて適切な指示をリストした画面に飛ばしてくれます。しかし、残念なことに私が使用しているAmazon LinuxがSystemの選択がありません。
近いのは、Cent OSかな、ということで、私は、https://certbot.eff.org/lets-encrypt/centos6-apacheのインストラクションを選びました。
それによると、まず以下のシェルスクリプトをダウンロードしてコマンドラインで実行可能とします。
$ wget https://dl.eff.org/certbot-auto
$ sudo mv certbot-auto /usr/local/bin/certbot-auto
$ sudo chown root /usr/local/bin/certbot-auto
$ sudo chmod 0755 /usr/local/bin/certbot-auto
Certbotの実行
通常は、この実行だけで済むのですが、残念、早速エラーとなりました。
$ sudo /usr/local/bin/certbot-auto certonly --apache
FATAL: Amazon Linux support is very experimental at present...
if you would like to work on improving it, please ensure you have backups
and then run this script again with the --debug flag!
Alternatively, you can install OS dependencies yourself and run this script
again with --no-bootstrap.
Amazon Linuxはまだ実験段階ということで、デバッグオプションを追加して再度実行します。
$ sudo /usr/local/bin/certbot-auto certonly --apache --debug	
Bootstrapping dependencies for Amazon... (you can skip this with --no-bootstrap)
...
Complete!
Creating virtual environment...
Traceback (most recent call last):
  File "<stdin>", line 27, in <module>
  File "<stdin>", line 19, in create_venv
  File "/usr/lib64/python2.7/subprocess.py", line 185, in check_call
    retcode = call(*popenargs, **kwargs)
  File "/usr/lib64/python2.7/subprocess.py", line 172, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib64/python2.7/subprocess.py", line 394, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1047, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
なんだか進んだな、と思ったら最後にエラーです。
調査してみると、私の環境のPythonのバージョンが古いようです。
ということで、前段階でインストールされたバージョン2.7に切り替えます。
$ sudo alternatives --config python

There are 2 programs which provide 'python'.

  Selection    Command
-----------------------------------------------
 + 1           /usr/bin/python2.6
*  2           /usr/bin/python2.7

Enter to keep the current selection[+], or type selection number: 2
そして、すでに完了した段階をスキップするために、–no-bootstrapを追加して再度実行します。
$ sudo /usr/local/bin/certbot-auto certonly --apache --debug --no-bootstrap
Creating virtual environment...
Installing Python packages...
Installation succeeded.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Enter email address (used for urgent renewal and security notices)
 (Enter 'c' to cancel): kenji@lotsofbytes.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: larajapan.com
2: www.larajapan.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for larajapan.com
http-01 challenge for www.larajapan.com
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/larajapan.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/larajapan.com/privkey.pem
   Your cert will expire on 2020-09-30. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le
セキュア認証の作成、成功です！
さて、上で何が起こっているかを説明すると、まず、必要な環境を作成して必要なライブラリのインストールを行った後、以下が問われます。

	緊急の場合や更新のお知らせのためにEメールアドレス
	同意するか。Aをタイプしてください。
        先のEメールを共有してよいか。YあるいはNのタイプです。
	どのサイトのHttpsが必要か。既存のapacheの設定からリスト作成してれます。指定するならコンマ区切りで番号を、すべてなら単にリターンします。

これらを回答すると、/etc/letsencryptのディレクトリに以下のようにSSL認証関連のいろいろなファイルが作成されます。
$ cd /etc/letsencrypt
$ tree
.
├── accounts
│   └── acme-v02.api.letsencrypt.org
│       └── directory
│           └── 20adce2f0bc35e942a75b71a4716e1c3
│               ├── meta.json
│               ├── private_key.json
│               └── regr.json
├── archive
│   └── larajapan.com
│       ├── cert1.pem
│       ├── chain1.pem
│       ├── fullchain1.pem
│       └── privkey1.pem
├── csr
│   └── 0000_csr-certbot.pem
├── keys
│   └── 0000_key-certbot.pem
├── live
│   ├── larajapan.com
│   │   ├── cert.pem -> ../../archive/larajapan.com/cert1.pem
│   │   ├── chain.pem -> ../../archive/larajapan.com/chain1.pem
│   │   ├── fullchain.pem -> ../../archive/larajapan.com/fullchain1.pem
│   │   ├── privkey.pem -> ../../archive/larajapan.com/privkey1.pem
│   │   └── README
│   └── README
├── options-ssl-apache.conf
├── renewal
│   └── larajapan.com.conf
└── renewal-hooks
    ├── deploy
    ├── post
    └── pre
apacheの設定
作成された認証関連のファイルを使用するために、apacheの設定ファイル、/etc/httpd/conf/httpd.conf、あるいは、httpd-vhosts.confを以下のように編集します。
<VirtualHost *:443>
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/larajapan.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/larajapan.com/privkey.pem
..
設定後、apacheを再起動します。
$ sudo service httpd restart
セキュア認証の確認
さて、セキュア認証が問題なくインストールされているか、確認してみましょう。
以下のサイトで検証できます。
https://www.ssllabs.com/ssltest
私のサイトのURLを入れて、

Aになりました！

セキュア認証の更新
巷の有料なセキュア認証は、たいて１年か２年間更新しなくて済むのですが、、実はこの認証は９０日ごとに更新される必要あります。
それも自動化するために、以下でのクロンの設定が必要です。
$ echo "0 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/certbot-auto renew -q" | sudo tee -a /etc/crontab > /dev/null
９０日後に実際、うまく更新されるかどうか報告しますね。


composerのあれこれ
Mon, 17 Sep 2018 06:13:39 +0900
新規のLaravelのプロジェクトを作成するときや、ライブラリを追加するときに使用するcomposerのコマンド。Laravelの陰で一見地味な存在に見えます。しかし、このおかげでphp言語のライブラリのインフラが整備され、アプリのモダンな開発の基盤を提供しているなくてはならないコマンドです。今回はこのコマンドに注目してみます。
composerのインストール
1回実行すれば何もしないのですっかり忘れていたけれど、以下が正しいインストール方法。これによると。
$ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
$ php -r "if (hash_file('SHA384', 'composer-setup.php') === '544e09ee996cdf60ece3804abc52599c22b1f40f4323403c44d44fdfdd586475ca9813a858088ffbc1f233e9b180f061') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
$ php composer-setup.php
$ php -r "unlink('composer-setup.php');"
上を実行すると、composer.pharのファイルが作成されます。開発環境なら、自分のホームのbinのディレクトリに、グローバルで使用したいなら、ルート権限で以下のように適切なディレクトリへ移します。
$ mv composer.phar /usr/local/bin/composer
composer.pharの作成時には、ホームディレクトリに、.composerのディレクトリ（あるいは、.config/composer）が作成されます。
.composer
├── cache
├── keys.dev.pub
└── keys.tags.pub
今はほとんど空ですが、将来はすでにインストールしたパッケージのキャッシュやlaravelなどのコマンドの保存場所となります。
Laravelのパッケージのインストール
composerのコマンドが使えるようになったところで、laravelのパッケージをインストールします。
$ composer global require "laravel/installer"
globalのオプションは、ホームディレクトリの.composerのディレクトリにファイルをインストールすることを指定します。インストール後は、.composerのディレクトリは以下のような感じになります。
.composer
├── cache
│   ├── files
│   │   ├── guzzlehttp
│   │   ├── laravel
│   │   ├── psr
│   │   └── symfony
│   └── repo
│       └── https---repo.packagist.org
├── composer.json
├── composer.lock
├── keys.dev.pub
├── keys.tags.pub
└── vendor
    ├── autoload.php
    ├── bin
    │   └── laravel -> ../laravel/installer/laravel
    ├── composer
    ├── guzzlehttp
    ├── laravel
    │   └── installer
    ├── psr
    └── symfony
vendor/bin/laravelのコマンドに気づいたと思いますが、Laravelのプロジェクトの作成に使われるコマンドです。簡単に実行できるように、.bashrcなどのファイルにおいて、$PATHに、$HOME/.composer/vendor/binを追加しておいてください。
Laravelのプロジェクトの作成
ここまで来ると、プロジェクトの作成は簡単です。インストールしたいディレクトリへ行き以下を実行します。
$ laravel new new-project
注意が必要なのは、上のコマンドの実行では最新のLaravelのバージョン（今なら、5.7）がインストールされることです。
バージョンを指定したいなら、composerコマンドの登場です。
$ composer create-project --prefer-dist laravel/laravel new-project "5.5.*"
composerのオプション
新規のLaravelのプロジェクトを作成したところで、いったい何のパッケージがインストールされたのでしょう？
ホームディレクトリの.composerと同様に、vendorのディレクトリを見るとパッケージに対応していろいろなディレクトリが作成されています。
パッケージの情報をより見たいなら、
composer show
の実行です。
$ composer show
beyondcode/laravel-dump-server        1.2.1    Symfony Var-Dump Server for Laravel
dnoegel/php-xdg-base-dir              0.1      implementation of xdg base directory specification for php
doctrine/inflector                    v1.3.0   Common String Manipulations with regard to casing and singular/plural rules.
doctrine/instantiator                 1.1.0    A small, lightweight utility to instantiate objects in PHP without invoking their constructors
doctrine/lexer                        v1.0.1   Base library for a lexer that can be used in Top-Down, Recursive Descent Parsers.
dragonmantank/cron-expression         v2.2.0   CRON for PHP: Calculate the next or previous run date and determine if a CRON expression is due
egulias/email-validator               2.1.5    A library for validating emails against several RFCs
erusev/parsedown                      1.7.1    Parser for Markdown.
fideloper/proxy                       4.0.0    Set trusted proxies for Laravel
filp/whoops                           2.2.1    php error handling for cool kids
fzaninotto/faker                      v1.8.0   Faker is a PHP library that generates fake data for you.
hamcrest/hamcrest-php                 v2.0.0   This is the PHP port of Hamcrest Matchers
jakub-onderka/php-console-color       0.1     
jakub-onderka/php-console-highlighter v0.3.2  
laravel/framework                     v5.7.3   The Laravel Framework.
laravel/tinker                        v1.0.7   Powerful REPL for the Laravel framework.
...
他のパッケージをインストールしたいなら、例えば、スプレッドシートのライブラリをインストールしたいなら、
composer require “phpoffice/phpspreadsheet”
を実行します。
composer.jsonのファイルも更新されて、“phpoffice/phpspreadsheet”: “^1.4”の行が追加されます。
{
    "name": "laravel/laravel",
    "description": "The Laravel Framework.",
    "keywords": ["framework", "laravel"],
    "license": "MIT",
    "type": "project",
    "require": {
        "php": "^7.1.3",
        "fideloper/proxy": "^4.0",
        "laravel/framework": "5.7.*",
        "laravel/tinker": "^1.0",
        "phpoffice/phpspreadsheet": "^1.4"
    },
...
開発のみに使用するパッケージは、
composer require barryvdh/laravel-debugbar –dev
と、–devオプションをつけて実行します。実行後は、composer.jsonのrequire-devセクションも以下のように更新されています。
...
    "require-dev": {
        "barryvdh/laravel-debugbar": "^3.2",
        "beyondcode/laravel-dump-server": "^1.0",
        "filp/whoops": "^2.0",
        "fzaninotto/faker": "^1.4",
        "mockery/mockery": "^1.0",
        "nunomaduro/collision": "^2.0",
        "phpunit/phpunit": "^7.0"
    },

...
手動でこのファイルを編集してパッケージを追加したときには、
composer update
を実行します。他のパッケージの更新やパッケージ間の依存のチェックもあり、時間がかかります。
上記のコマンドの実行で、composer.jsonが編集されることを見てきましたが、composer.lockというファイルも更新されます。このファイルは、プロジェクトのデプロイにおいて重要です。開発環境でテストされたプログラムと同じパッケージの同じパージョンを、本環境にプログラムをデプロイする必要あります。それには、
composer install
を本サイトで実行します。このコマンドは、composer.lockのデータに従って開発環境と同じパッケージの同じバージョンのファイルをインストールしてくれます。
さらに、
composer install –no-dev
と、–no-devオプションを付ければ、開発だけに必要なパッケージは一切インストールはしません。
composer.jsonとcomposer.lockはそれゆえに、gitなどで必ずバージョン管理する必要があります。


ティンカーでリクエスト（Request）
Sat, 09 Jun 2018 09:00:44 +0900
前回に引き続いてリクエストの話です。ブラウザがないとリクエスト（Request）のオブジェクトが作成できない、とは限りません。Laravelならコマンドラインで作成できます。どうやって？
リクエストオブジェクトの作成
コマンドラインと言えばもちろん、tinkerのことです。以下のように、クラスのcreate()メソッドを使って、リクエストのオブジェクトを作成できます。
Psy Shell v0.9.3 (PHP 7.1.14 — cli) by Justin Hileman

>>> $request = \Illuminate\Http\Request::create('http://localhost', 'GET', ['name' => 'test']);

=> Illuminate\Http\Request {#2324
     ⚠: Symfony\Component\VarDumper\Exception\ThrowingCasterException {#2309
       #message: "Unexpected ErrorException thrown from a caster: Undefined index: ",
     },
     +attributes: Symfony\Component\HttpFoundation\ParameterBag {#2320},
     +request: Symfony\Component\HttpFoundation\ParameterBag {#2322},
     +query: Symfony\Component\HttpFoundation\ParameterBag {#2321},
     +server: Symfony\Component\HttpFoundation\ServerBag {#2317},
     +files: Symfony\Component\HttpFoundation\FileBag {#2318},
     +cookies: Symfony\Component\HttpFoundation\ParameterBag {#2319},
     +headers: Symfony\Component\HttpFoundation\HeaderBag {#2316},
   }
Laravelのリクエストは、Symfonyのクラスがベースになっているようです。createは、Laravelのクラスのメソッドではなく、Symfonyのクラスのメソッドです。参考のために、以下にその定義の一部を掲載します。
SymfonyComponentHttpFoundationRequest.php
    /**
     * Creates a Request based on a given URI and configuration.
     *
     * The information contained in the URI always take precedence
     * over the other information (server and parameters).
     *
     * @param string               $uri        The URI
     * @param string               $method     The HTTP method
     * @param array                $parameters The query (GET) or request (POST) parameters
     * @param array                $cookies    The request cookies ($_COOKIE)
     * @param array                $files      The request files ($_FILES)
     * @param array                $server     The server parameters ($_SERVER)
     * @param string|resource|null $content    The raw body data
     *
     * @return static
     */
    public static function create($uri, $method = 'GET', $parameters = array(), $cookies = array(), $files = array(), $server = array(), $content = null)
    {
    ..
先のtinkerの実行では、create()の3番目のパラメータに、連想配列で値（[’name’ => ’test’]）を渡しました。ということは、以下のtinkerの実行で変数の取り出し可能です。
>>> $request->all();

=> [
     "name" => "test",
   ]

>>> $request->input();

=> [
     "name" => "test",
   ]

>>> $request->name;

=> "test"

>>> $request->input('name');

=> "test"

>>> $request->get('name');

=> "test"
>>>
前回に説明したことが、ここで簡単にシミュレートできるのです。
そして、さらに、こんなこともテストできます。簡単なValidationのテストです。
>>> $request->validate(['name' => 'required']);

=> [
     "name" => "test",
   ]

>>> $request->validate(['name' => 'required|alpha']);

=> [
     "name" => "test",
   ]

>>> $request->validate(['name' => 'alpha']);
=> [
     "name" => "test",
   ]

>>> $request->validate(['name' => 'numeric']);
Illuminate/Validation/ValidationException with message 'The given data was invalid.'
>>>
Validationに成功したら、入力の連想配列を返し、失敗したらValidationExceptionを返します。
tinkerの便利さは、いちいちプログラムを書かずに、ブラウザを立ち上げることなしに、テストできることです。こんな便利なツールを習得せずに、Laravelを語ることはできません。


Laravelの開発に必須な私のツール
Sat, 26 May 2018 02:27:27 +0900
Laravelをウェブアプリの開発の使い始めてから、もうかれこれ5年になろうとしています。Laravelのバージョンも4から5になりさらに進化し続けています。こう経験が長くなると、使用する開発ツールも年々増えてきます。その中で、もうこれがないと開発できない！というものもいくつかあります。
バージョン管理：Git
コードのバージョン管理まったくなしで開発していた時代があったのが信じられないくらい、gitは毎日毎日使用しています。ブランチの作成、差分のチェック(git diff)、コードのマージ(git merge)、プログラムのリバート(git checkout)、ときにハードのリセット(git reset –hard)などなど、もうこれなしでプログラマとして生きていくのは不可能。Laravelだから必要というわけでないですが、ほとんどLaravelの採用とともに、バージョン管理をsubversionからgitに乗り換えてから、後ろを振り向くことはありません。
また、コマンドラインで実行するgitのプログラムだけでなく、それに伴うインフラのサービスも必須です。このブログで紹介しているLaravelの日本語レポジトリは、有名なgithub.comを使用し、プライベートのプロジェクトには、bitbucket.comを使用しています。それぞれ長所、短所ありますが、後者はプライベートのレポをいくら作成しても無料なゆえに開発チームで使用しています。
開発ヘルパー：debugbar
以前にも紹介したツールです。
Debugbarで楽々デバッグ
https://github.com/barryvdh/laravel-debugbar
Laravelのコミュニティーには、Laravelの作者も含めて、賢い人がたくさんいます。debugbarを作成した人もそのひとり。このようなツール、Laravelの以前から欲しかったものです。ブラウザに、現在の画面でLaravelで使用された、リクエスト(Request)、セッション(Session)、DBクエリ(Queries)、認証(Auth)の情報がすべて出てくるので、すぐにコード内の状況がわかります。また、debug()をコードに入れることで、dd()を使用せずに、情報をデバッグ画面に表示できます。最近気づいたことでは、実行したDBクエリーに対応するファイルの行数まで表示されます。嬉しいこと、このうえない！

開発ヘルパー：tinker
これも以前紹介したコマンドツール。
もっとティンカー(tinker)を使おう！
コマンドツールというと、覚えることが多くて大変と思われるかもしれないですが、慣れてくるともう離れられない。プログラムのファイルを作成することなしにちょいちょいとテストできるからです。
そして、Laravel5.5のバージョンでは、嬉しい改善があります。
例えば、Laravel 5.5以前のバージョンでは、
Psy Shell v0.9.3 (PHP 7.1.15 — cli) by Justin Hileman
>>> use App\User;
>>> User::find(5);
=> App\User {#2307
     id: 5,
     name: "hogeuser01",
     email: "hoge01@example.com",
     created_at: "2018-04-04 14:20:37",
     updated_at: "2018-04-04 14:20:37",
   }
今までいちいちとタイプしていたクラスの宣言（上のuse App\User;）を、
Psy Shell v0.9.3 (PHP 7.1.15 — cli) by Justin Hileman
>>> User::find(5);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#2316
     id: 5,
     name: "hogeuser01",
     email: "hoge01@example.com",
     created_at: "2018-04-04 14:20:37",
     updated_at: "2018-04-04 14:20:37",
   }
このように指定しなくても自動的に探してエイリアスとして覚えてくれるので、1行分のタイプが必要なくなり、ますます使いやすくなりました。
コードチェック：phan
これも以前紹介したコマンドツール。
phanは楽しい！
タイプレスのphp言語にＣ言語のようなタイプチェックをもたらしてくれるツールです。これが開発に貢献する度合いは、すでに紹介したツールと比べて小さいのだけれど、これで発見したエラーは貴重です。改善して欲しいのは、Traitを使用すると誤診の警告が多いこと。将来に期待しています。
テスト：phpunit
アプリの機能が増えるにつれ、コードの複雑さが増してくると、バグの修正であれ機能の変更であれ、他の部分への影響が大きくなります。もちろん、仕様を整理したり、Laravelのようなフレームワークを導入して管理性を高めるのだけれど、人間がなす業、見過ごしや間違いがもちろん起きます。自分自身でないテスターにテストさせても間違いがスルーしてしまいます。
こうした中で、頼りとなってくるのはユニットテスト。単に、今までの機能が変更により壊れていないかを確認してくれだけでなく、今まで作成・蓄積してきた関数の使用方法もテストのプログラムを読むことで理解できます。特にLaravelのバージョンの更新後に、phpunitの実行でエラーがないことを確認するだけでも自分が作成したプログラムに自信が持てます。
最近は、開発自体もまずはユニットテストから始めるテストドリブン（Test Driven Development）の開発に移行しつつあります。もちろん、通常の開発だけに比べてより時間がかかるのですが、その時間が将来に起こるかもしれない、冷っとする経験を少なくしてくれると思うとかけがえのないものです。
その他
他にも開発に関わるツールは、たくさんあります。テキストエディタのsublimeや、仕様管理に使っているGoogle Sheet、スマホもＰＣも一度に閲覧できるブラウザ、blixなどあります。感慨深いのは、5年前にはどれもこれも使用したこともないツールばかり、中にはこの世に存在しないものも。次の5年間はどうなるのでしょう？


Laravel Shiftでバージョンを更新
Thu, 18 Jan 2018 04:59:38 +0900
Laravelのメジャーのバージョンは、以下のように、ほぼ年に2回のペースでリリースされています。

頻繁に更新されることは、Laravelがいつもアクティブである証拠でとても良いのですが、追い付いていくのが大変なのが現状です。
もちろん便利な機能が登場してきたり、今まで複雑だったことが簡単にできるようなったりとかプラスの面が多いのですが、過去には、バージョン間でフレームワークのディレクトリのレイアウトが変わったり、関数名が変わったりと、ほとんど書き直しを強制される結果となることもあります。
さらに、お客さんのプロジェクトとなれば、バージョンの更新ではＵＩは何も変わらないので、どうコストを正当化するのかも頭が痛いことです。しかし、バージョンアップしないとLaravelのサポートが期限切れとなるし、便利な新しい機能も使えないし。。。
こういうときに、見つけたのが、バージョン更新サービスの、Laravel Shift

早速、このサービスを利用して、私のLaravel5.3の日本語のリポジトリを5.4に更新してみましょう。
残念ながら英語のサービスですが、すでにgithubやbitbucketのリポジトリを使用しているならことは簡単です。

  ホームページで「Get Started Now」をクリックすると、以下のようなポップアップが登場します。
  
  
  Gitのレポジトリにログインします。
  
　
  Laravel Shiftがgithubの私のレポジトリにアクセスすることを許可します。
　
　
  Welcome画面が表示されます。そこの右上の「New Shift」をクリックして次の画面へ進みます。
　
　
  更新先のバージョンを選択します。ここでは5.3から5.4なので、「Laravel 5.4」にマウスを持っていき、「Purchase」をクリックします。
　
  
  更新元のレポジトリとブランチ名を入力します。
  
  
  支払い画面です。「Purchase Shift」をクリックします。
  
  
  クレジットカード情報を入れます。
　
  
  カード決済が完了すると、作業が開始されます。プロジェクトのサイズにもよりますが、完了するとステータスのアイコンが変わり終了です。
　
  

これで、Laravel Shiftのサイトでの作業は終わりです。領収書のＥメールも送信されます。
一方、gifthub.comの方では、プルリクエストが作成され、shift-のプレフィックスのブランチが作成されています。
プルリクエストの内容は以下で閲覧できます。
https://github.com/lotsofbytes/larajapan/pull/2
このブランチでは、コミットは６つ存在し、先のプルリクエストでそれらに関して説明が記されています。この説明は十分理解する必要あり。
作成されたブランチがそのまま使用できるのではなく、以下の作業が必要と書かれています。

    	作成されたブランチをgitでチェックアウトしてください。
   	プルリクエストのすべてのコメントをレビューしてください。追加の変更を行う必要があるかもしれません。
    	Laravel 5.4の更新のために依存部分を更新してください。
    	composer updateを実行してください。失敗するなら--no-scriptsを付けて再度実行してください
    	徹底的にテストしてください/li>

以上をこなして実行してみると、動作しましたね！
もちろん今回はとてもシンプルなプロジェクトでの更新なので、調整も最低限度と思いますが、大きなプロジェクトではShiftのブランチで簡単にはいかないと思います。しかし、LaravelのサイトでのUpgrade Guideを読んで、現在のプロジェクトを手動で更新、または新バージョンをまっさらでインストールして、そこにプログラムを１つ１つ移行していくなどの作業よりは、Shiftを使うとスタート時点でかなり違うかなと感じです。今回は１１ドルとコストも低いし。
私のクライアントのプロジェクトでは、5.2 ⇒ 5.3 ⇒ 5.4 ⇒ 5.5と3回Larvel Shiftの作業が必要となるわけですが、試してみようと思います。


もっとティンカー(tinker)を使おう！
Wed, 27 Dec 2017 06:29:23 +0900
今年最後の投稿です。まだまだ投稿のネタはたくさんあります。来年も楽しみに！
tinkerに関しては、以前に紹介していますが、私には現在もなくてはならないコマンドラインツール。
このツール、実は機能が豊富にあるということ最近気づきました。ますます好きになりました。
私がtinkerを利用する一番の理由は、Laravelの知らない、あるいは正確なシンタックスを覚えていないメソッドをテストしたいときです。dd()入れてブラウザで実行して結果をチェックするのは面倒、unit testを書くには大袈裟なとき、tinkerが一番です。
例えば、以下pluckの関数のパラメータ、どっちが配列のインデックスになるのだっけ？　all()のコールは必要だっけ？　・・というときに。
$ php artisan tinker
Psy Shell v0.8.11 (PHP 7.0.23 — cli) by Justin Hileman
>>> use App\User;
>>> User::all()->pluck('id', 'name');
=> Illuminate\Support\Collection {#705
     all: [
       "kenji" => 1,
       "test" => 2,
     ],
   }
>>> User::all()->pluck('name', 'id');
=> Illuminate\Support\Collection {#703
     all: [
       1 => "kenji",
       2 => "test",
     ],
   }
>>> User::pluck('name', 'id');
=> Illuminate\Support\Collection {#705
     all: [
       1 => "kenji",
       2 => "test",
     ],
   }
>>>
と、いちいちマニュアルをチェックすることなしに、まずは実行して試す。
実行した結果だけでなく、プログラム自体の表示も可能です。
>>> show User
  >  9| class User extends Authenticatable
    10| {
    11|     use Notifiable;
    12|         use CanResetPassword;
    13| 
    14|     /**
    15|      * The attributes that are mass assignable.
    16|      *
    17|      * @var array
    18|      */
    19|     protected $fillable = [
    20|         'name', 'email', 'password',
    21|     ];
    22| 
    23|     /**
    24|      * The attributes that should be hidden for arrays.
    25|      *
    26|      * @var array
    27|      */
    28|     protected $hidden = [
    29|         'password', 'remember_token',
    30|     ];
    31| }
クラス全体だけでなく、指定のメソッドのコード部分も。実際は以下の画像のように、綺麗な色付きで表示されるので読みやすいです。

bashのhistoryのように、今まで実行した履歴も閲覧可能です。
>>> hist
0: use App\User;
1: User::all()->pluck('id', 'name');
2: User::all()->pluck('name', 'id');
3: User::pluck('name', 'id');
histの結果は、とても長くなるので、一部だけを閲覧することも可能です。
>>> hist --show 1..3
0: use App\User;
1: User::all()->pluck('id', 'name');
2: User::all()->pluck('name', 'id');
3: User::pluck('name', 'id');
さらに、履歴を–replayで再実行可能です。
>>> hist --show 2 --replay
Replaying 1 line of history
-->   User::all()->pluck('name', 'id');
=> Illuminate\Support\Collection {#708
     all: [
       1 => "kenji",
       2 => "test",
     ],
   }
histには、他にも–head、–tail、–grepのオプションがあります。
さらに、tinkerは、php関数のマニュアルも出力することも可能です。
まず、設定として、マニュアルをダウンロードします。ファイルは11MBのサイズです。
mkdir ~/.local/share/psysh
cd ~/.local/share/psysh
wget http://psysh.org/manual/ja/php_manual.sqlite
関数のマニュアルを表示するには、docを利用します。例えば、
>>> doc array_shift
とタイプすれば、

と日本語で表示してくれます。また、Laravelの関数では、クラスのパス名を指定すれば、
>>> doc \Illuminate\Http\Request::input
public function input($key = null, $default = null)

Description:
  Retrieve an input item from the request.

Param:
  string             $key     
  string|array|null  $default 

Return:
  string|array
と説明が見れます。
最後に、Laravelのtinkerは、以下のPsySHのラッパーです。
https://github.com/bobthecow/psysh
こんな便利なツールを開発してくれて、ありがとう！


PSR2変換ツール
Sat, 09 Dec 2017 02:30:18 +0900
前回で説明したPHPのコーディングスタイルの基準PSR2、これをすべて覚えて手動で実行しようというのは到底無理なこと、そこで登場するのが、php-cs-fixer、自動でそれを行ってくれるツールです。
インストールはいたって簡単。
今回は、phanやphpunitとは違い、プロジェクトが使用しているLaravelやPHPのバージョンに合わせる必要はないので、プロジェクトごとではなくグローバルに、つまり自分のホームディレクトリでのインストールとします。
$ composer global require friendsofphp/php-cs-fixer
これを実行すると、いくつかの必要なパッケージがインストールされます。
そして、~/.composer/vendor/bin/php-cs-fixerにファイル（実際はシムリンク）が作成されます。
どこでもこれが実行できるように、.bahsrcに以下の設定を入れておくことを勧めます。
.bashrc
...
export PATH="$PATH:$HOME/.composer/vendor/bin"
...
実行も簡単。例えば、変換対象のファイルを、test.phpとすると、
$ php-cs-fixer fix test.php
Loaded config default.
Using cache file ".php_cs.cache".
   1) test.php

Fixed all files in 0.193 seconds, 10.000 MB memory used
test.phpが、デフォルトのルールで、PSR1とPSR2に基づいて変換されます。
以下は、前回の例のファイルを崩したものです。
<?php

namespace Vendor\Package;
use FooInterface;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;
class Foo extends Bar implements FooInterface {

    protected $a, $b, $c;

    public function sampleMethod( $a,$b = null )
    {
        if ( $a === $b )
		{
            bar();
        }
		elseif ($a > $b)
		{
            $foo->bar($arg1);
        }
		else
		{
            BazClass::bar($arg2,$arg3);
        }
    }
}
?>
これをphp-cs-fixerで修正すると、前回のように
<?php

namespace Vendor\Package;

use FooInterface;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;

class Foo extends Bar implements FooInterface
{
    protected $a;
    protected $b;
    protected $c;

    public function sampleMethod($a, $b = null)
    {
        if ($a === $b) {
            bar();
        } elseif ($a > $b) {
            $foo->bar($arg1);
        } else {
            BazClass::bar($arg2, $arg3);
        }
    }
}
となります。
php-cs-fixerの実行では、.php_cs.cacheのファイルが作成されます。この中には、使用されたJSON設定が収められています。バージョン管理には要らないファイルなので、.gitignoreなどに含むようにしてください。

さて、php-cs-fixerを使用してLaravelのプロジェクト全体をPSR2準拠に変換します。Laravelのプロジェクトにはいろいろなディレクトリがあるために、変換必要なファイルだけを指定する必要があります。そのためには以下のような設定ファイル.php_csが必要です。
.php_cs
<?php

$finder = PhpCsFixer\Finder::create()
    ->exclude('bootstrap/cache')
    ->exclude('storage')
    ->exclude('vendor')
    ->in(__DIR__)
    ->name('*.php')
    ->notName('*.blade.php')
    ->ignoreDotFiles(true)
    ->ignoreVCS(true)
;

return PhpCsFixer\Config::create()
    ->setRules(array(
        '@PSR2' => true,
    ))
    ->setFinder($finder)
;
設定ファイル自体がphpのプログラムです。そこで見られるように、bootstrap/cache, storage, vendorのディレクトリ以外のphpファイルはすべてPSR2準拠に変換してくれます。しかし、bladeのファイルはphpファイルでないゆえに変換しません。
このファイルを、Laravelプロジェクトのルートディレクトリに置きます、そして変換は、そこで以下の実行だけです。
$ php-cs-fixer fix
変換前に、gitのブランチをこのために作成しておいてから実行してください。例えば、新ブランチをpsr2と命名して、変換後に差分をチェックしたいなら、
$ git diff master -w
と実行すれば、タブからスペースへの変更以外の変更をチェックできます。
最後に、このツールの作者は、有名なphpフレームワーク、symfonyのフレームワークの作者でもあります。Laravelのライブラリの一部はsymfonyのを利用しています。


phanは楽しい！(2) laravel編
Fri, 10 Nov 2017 02:45:14 +0900
前回紹介した楽しい開発ツールphanを、今回はLaravelのプロジェクトに適用してみます。さて、どれだけ楽しくなるか！
まず、Laravel 5.4の私の日本語開発用のレポジトリをインストールします。
$ git clone git@github.com:lotsofbytes/larajapan.git
次に、phanのパッケージをインストールします（注１）
$ cd larajapan
$ composer require --dev phan/phan
インストールできたところで、phanの設定をします。
.phanのディレクトリを作成して、config.phpのファイルを作成します。
config.php
return [
    // 解析のためにクラスやメソッドの情報を取得するディレクトリ。
    // これらと、以下の exclude_analysis_directory_list で指定した
    // ディレクトリとの差分が解析チェックの対象となる
    'directory_list' => [
        'app',
        'routes',
        'vendor'
    ],

    // 解析チェックの対象から除外するディレクトリ。
    'exclude_analysis_directory_list' => [
       'vendor'
    ],
];
設定ファイルが用意できたところで、最初のphanの実行をしてみましょう。
$ vendor/bin/phan -p 
app/Auth/Notifications/ResetPassword.php:51 PhanTypeMismatchArgument Argument 2 (parameters) is string but \route() takes array defined at vendor/laravel/framework/src/Illuminate/Foundation/helpers.php:707
app/Auth/Passwords/CanResetPassword.php:16 PhanUndeclaredProperty Reference to undeclared property \App\Auth\Passwords\CanResetPassword->email
app/Auth/Passwords/CanResetPassword.php:27 PhanUndeclaredMethod Call to undeclared method \App\Auth\Passwords\CanResetPassword::notify
app/Providers/RouteServiceProvider.php:54 PhanUndeclaredMethod Call to undeclared method \Illuminate\Routing\Route::namespace
app/Providers/RouteServiceProvider.php:68 PhanUndeclaredMethod Call to undeclared method \Illuminate\Routing\Route::namespace
routes/api.php:16 PhanUndeclaredClassMethod Call to method middleware from undeclared class \Route
routes/channels.php:14 PhanUndeclaredClassMethod Call to method channel from undeclared class \Broadcast
routes/console.php:16 PhanUndeclaredClassMethod Call to method command from undeclared class \Artisan
routes/console.php:17 PhanUndeclaredVariable Variable $this is undeclared
routes/web.php:14 PhanUndeclaredClassMethod Call to method get from undeclared class \Route
routes/web.php:22 PhanUndeclaredClassMethod Call to method get from undeclared class \Route
routes/web.php:23 PhanUndeclaredClassMethod Call to method post from undeclared class \Route
routes/web.php:24 PhanUndeclaredClassMethod Call to method post from undeclared class \Route
routes/web.php:27 PhanUndeclaredClassMethod Call to method get from undeclared class \Route
routes/web.php:28 PhanUndeclaredClassMethod Call to method post from undeclared class \Route
routes/web.php:31 PhanUndeclaredClassMethod Call to method get from undeclared class \Route
routes/web.php:32 PhanUndeclaredClassMethod Call to method post from undeclared class \Route
routes/web.php:33 PhanUndeclaredClassMethod Call to method get from undeclared class \Route
routes/web.php:34 PhanUndeclaredClassMethod Call to method post from undeclared class \Route
routes/web.php:36 PhanUndeclaredClassMethod Call to method get from undeclared class \Route
たくさんエラー出てきました。
その中でもPhanUndeclaredClassMethodが多い。これは宣言されていないクラスのメソッドをコールしているエラーです。
例えば、一番多いエラーとなっているRouteのクラスは、Laravel特有のFacade（ファサード）です。ネームスペースnamespaceがあるクラスと違い、phanにとっては解析が難しいようです。
調査したところ、IDEヘルパーの開発ツールを使用して、stabのファイルを作成することで回避できそうです。Laravelのstabのファイルの作成には、まず以下を実行してide-helperのパッケージをインストールします。
$ composer require --dev barryvdh/laravel-ide-helper
次に、config/app.phpを編集して以下を追加、
Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider::class
このパッケージは、debugbarの開発者が作成したものです。本来は、phpStormなどのIDEのエディターでのヘルパーが目的（それゆえにlaravel-ide-helper）ですが、ファサードのクラスのメソッドを宣言してくれるために、phanでも役に立つようです。
app.php
..
    'providers' => [  
..
        /*                                                                                                                                                                                                         
        * Package Service Providers...                                                                                                                                                                            
        */                                                                                                                                                                                                        
        Laravel\Tinker\TinkerServiceProvider::class,                                                                                                                                                               
        Barryvdh\Debugbar\ServiceProvider::class,
        Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider::class,

..
そして、以下を実行。
$ php artisan ide-helper:generate
_ide_helper.phpのファイルが実行したディレクトリに作成されます。これを、.phan/stabsのディレクトリを作成して移します。
$ mkdir .phan/stabs
$ mv _ide_helper.php .phan/stabs
さらに、このファイルを利用するために、.phan/config.phpも編集が必要です。
config.php
return [
    // 解析のためにクラスやメソッドの情報を取得するディレクトリ。
    // これらと、以下の exclude_analysis_directory_list で指定した
    // ディレクトリとの差分が解析チェックの対象となる
    'directory_list' => [
　　　　 '.phan/stabs',
        'app',
        'routes',
        'vendor'
    ],

    // 解析チェックの対象から除外するディレクトリ。
    'exclude_analysis_directory_list' => [
       '.phan',
       'vendor'
    ],
];
これで実行準備完了です。再度実行してみましょう。
$ vendor/bin/phan -p
app/Auth/Notifications/ResetPassword.php:51 PhanTypeMismatchArgument Argument 2 (parameters) is string but \route() takes array defined at vendor/laravel/framework/src/Illuminate/Foundation/helpers.php:707
app/Auth/Passwords/CanResetPassword.php:16 PhanUndeclaredProperty Reference to undeclared property \App\Auth\Passwords\CanResetPassword->email
app/Auth/Passwords/CanResetPassword.php:27 PhanUndeclaredMethod Call to undeclared method \App\Auth\Passwords\CanResetPassword::notify
app/Providers/RouteServiceProvider.php:54 PhanUndeclaredStaticMethod Static call to undeclared method \Illuminate\Support\Facades\Route::middleware
app/Providers/RouteServiceProvider.php:68 PhanUndeclaredStaticMethod Static call to undeclared method \Illuminate\Support\Facades\Route::prefix
routes/api.php:16 PhanUndeclaredStaticMethod Static call to undeclared method \Route::middleware
routes/channels.php:14 PhanUndeclaredStaticMethod Static call to undeclared method \Broadcast::channel
routes/console.php:17 PhanUndeclaredVariable Variable $this is undeclared
PhanUndeclaredClassMethodのエラーが少なくなりました。しかし、残り未宣言のエラーの解決は現段階では無理そうです。実際宣言されていにも関わらず、その情報をphanに伝えることが自動のツールでは不可能だからです。将来に期待しましょう。
とりあえず、ここでは-iオプションで、この未宣言のエラーを無視することにします。
$ vendor/bin/phan -p -i
app/Auth/Notifications/ResetPassword.php:51 PhanTypeMismatchArgument Argument 2 (parameters) is string but \route() takes array defined at vendor/laravel
-iで、エラーは１つだけとなりました。
このエラーは、以下のroute()の2番目の引数が配列である必要があるということで、
app/Auth/Notifications/ResetPassword.php
..
   public function toMail($notifiable)                                                                                                                                                                            
    {                                                                                                                                                                                                              
        return (new MailMessage)                                                                                                                                                                                   
            ->subject('パスワードリセット')                                                                                                                                                                        
            ->greeting('パスワードリセット')                                                                                                                                                                       
            ->line('パスワードリセットリンクの送信のリクエストがありました。')                                                                                                                                     
            ->action('リセットパスワード', url(config('app.url').route('password.reset', [$this->token], false)))                                                                                                    
            ->line('リクエストされていなかったら、無視してください。');                                                                                                                                            
    }     
..
と編集して解決できました。
ということで、インストールは”そう楽しくなさそうな”ツールですが、もし大きなプログラムがあるなら一度でも試してください。私のプロジェクトではいくつか重要なバグをみつけてくれてそれだけでも十分な貢献です。これからも、検証のツールとしてunit testとともに重要なものになりそうです。
ひとつ注意することは、この実行には空きメモリが２ＧＢ以上必要です。残念ながら私のテスト環境のawsのsmall（メモリ2GB）のインスタンスでは実行不可能でした。仮想の開発環境（メモリ4GB）で実行可能でした。
注１
composerで、phpdocumentor/reflection-docblockのバージョンのコンフリクトが出ました。すでにインストールされているそのパッケージのバージョンは4.1.1ですが、phan/phanが必要とするものはそれよりも昔のバージョン。ということで、
coomposer.json
..
   "require": {
        "php": ">=5.6.4",
        "barryvdh/laravel-debugbar": "~2.4",
        "laravel/framework": "5.4.*",
        "laravel/tinker": "~1.0",
        "phpdocumentor/reflection-docblock": "4.1.1 as 3.3.0"
    },
..
4.1.1 as 3.3.0として4.1.1のバージョンを3.3.0のバージョンとして扱ってもらうことで解決できました。


phanは楽しい！(1)
Sat, 28 Oct 2017 02:40:40 +0900
php７に更新したら使ってみたいと思っていたツールがありました。
このphpの静的解析ツールツールの名前は、Phan。ファンと呼びます。多分、楽しいという英語のfunにひっかけて。Githubでは、以下で公開されています。
https://github.com/phan/phan
さて、これがどうして重要なツールかというと、
phpはもともと開発の敷居を落とすためにCやJavaなどと違ってデータタイプを宣言しなくてよいプログラム言語、しかしプログラムが大きくなり複雑になってくると逆にその緩さが多くの間違いの原因となります。
例えば、
test.php
function double($i)
{
  return $i*2;
}

$x = '文字列';

echo double($x);
これを実行するとphpではエラーなしに、0を返します。関数doubleは数字を引数に期待しているはずなのに、phpは数字でなく文字列を渡しても問題なく処理してしまいます。もちろん、ここでの実行は意図的ですが、もし間違いで文字列を渡してしまったら、そのコードがもし他のコードの奥に隠れていたら、原因がわからないバグになりかねません。
phanは、ここの間違いをphpのプログラムを実行することなし（それゆえに静的解析）に見つけてくれる重要な開発検証ツールなのです。
まずは、phanのインストールからなのですが、今回はphanの紹介ということで、Laravelなしの環境でのインストールです。次回には、より複雑なLaravelプログラムの環境でのphanの実行を説明します。
さて、簡単にインストールできるよ、と行きたいのですが、実際は少々ややこしく、astのモジュールとphanのパッケージの２ステップのインストールとなります。
１．astのモジュールのインストール
ast(abstract syntax tree、抽象シンタックスツリー)は、phanに不可欠なphpプログラムの解析モジュールで、特定のプログラムでなくマシン全体でのグローバルのインストールとなります。そして、多分たいていの環境ではデフォルトでインストールされていないと思います。
まずは、そのモジュールが存在するかどうかのチェックとして、
$ php -m
の実行で、astがでて来なかったら、以下を実行してください。
$ pecl install ast
その後、/etc/php.iniを編集して、
extension=ast.so
を追加します。
残念ながらここでくじけたら、もうphanは使えません。くじけたくないなら、以下の開発者のgithubを見てください。
https://github.com/nikic/php-ast
話それますが、このastの開発者、いろいろ面白いツール作成しています。プログラムのコンパイルなどの理論に興味のある方は是非以下も。
https://github.com/nikic
２．phanのインストール
次は以下を実行して、パッケージをインストールします。
$ composer require --dev phan/phan
–devは、開発だけに使用という意味です。
これで、現在のディレクトリは、
.
├── composer.json
├── composer.lock
├── test.php
└── vendor
    ├── autoload.php
    ├── bin
    ├── composer
    ├── felixfbecker
    ├── netresearch
    ├── nikic
    ├── phan
    ├── phpdocumentor
    ├── psr
    ├── sabre
    ├── symfony
    └── webmozart
となります。test.phpは先ほどの例のプログラム。
３．phanの実行
実行は簡単です。ターゲットのファイルを指定するのみです。
$ ./vendor/bin/phan test.php
これを実行すると、何も出力ありません！
何がおかしいのでしょう？
phanは、エラーを出すには関数の引数のデータタイプが必要なのです。phpではそのためにDocblock（ドクブロック）をコメントの中に入れる必要あります。test.phpを編集して、@param float $iを関数定義の直上のコメントに入れます。
/**                                                                                                                                                                                                                
 * @param float $i                                                                                                                                                                                                   
 * @return float                                                                                                                                                                                                    
 */                                                                                                                                                                                                                
function double($i)                                                                                                                                                                                                
{                                                                                                                                                                                                                  
  return $i*2;                                                                                                                                                                                                     
}                                                                                                                                                                                                                  
                                                                                                                                                                                                                   
$x = '文字列';                                                                                                                                                                                                     
                                                                                                                                                                                                                   
echo double($x);
再度、phanを実行すると、
test.php:14 PhanTypeMismatchArgument Argument 1 (i) is string but \double() takes float defined at test.php:7
とエラーを出してくれます。もちろん、$x = 1.5と数字ならエラーは出ません。
簡単なphanの実演でしたが、このツールを活用するにはDocblockの作成がまず必要ということです。Docblockの作成はちょっと面倒な作業かもしれません。しかし、phpはバージョン5から、関数で型宣言ができ、sublimeなどの最近のエディターはそれを探知して、自動的にエディタでドクブロックも作成してくれます。また、それをもとにAPIドキュメントも作成してくれるツールもあります。ドクブロックは必須となっている昨今です。しかし、最終的には、１つの間違いでも減らしたいかどうかなのです。
　
　
最後に、このツールは、つい最近までは、phan/phanではなくetsy/phanという名前でした。
　

　
このetsy（エッチーあるいはイッチーと発音）というのはetsy.comハンドクラフトの人が自分の作品を販売できるサイトです。基本的にはハンドメードのものしか販売ダメという方針で人気があり、2014年末で登録会員（売る方でなく買う方）がなんと5400万人という。
そして凄いことに、この大きなスケールのサイトは、なんとphpで動いています。さらにでかいFacebookもPHPという話だからそう驚く必要はないですけれど。そして、それゆえに、今回のようなphpの開発のためのプログラムツールを公開してくれています。


Laravelのアップグレードとgitでのバージョン管理
Thu, 26 Oct 2017 04:41:12 +0900
Gitは、開発になくてはならないバージョン管理のツール。Laravelのバージョンをアップグレードがあるときは、フォルダーやファイルが入れ替わるためにGitで新ブランチを作成してから、更新作業を行います。しかし、問題はこの新ブランチは現在のマスターの複製であるため、以前のバージョンのファイルがすでに存在することです。
新しいバージョンと入れ替える１つの方法は、.git以外のフォルダーやファイルをすべて削除して、そこに新バージョンのLaravelを入れ直す。しかし、これを行うとGitで保存されている以前の変更やログぼ履歴が残ってしまい、新しくゼロからスタートができません。新しいバージョンでの開発は、あたかもまっさらからのように始めたい。
前回のLaravel 5.4のレポジトリ作成時にこの問題とぶつかり、どうしたら良いものやらと調査した結果、以下のような手順になりました。
masterを5.3ブランチと改名
現在は、masterにいます。
$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
　
masterを5.3のブランチに改名します。
$ git branch -m master 5.3
　
リモートレポジトリ(github)にプッシュします。
$ git push origin 5.3
　
5.4ブランチを作成してmasterに改名
現在は、5.3のブランチにいます。
$ git branch -a
* 5.3
  remotes/origin/5.3
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
　
まずは、親なしの5.4ブランチを作成します。親なし–orphanとすることによりブランチの変更やログの履歴が削除されます。この時点ではすべてのフォルダーやファイルはチェックアウトされていません。そして、それらをresetで全部削除します。残っているのは、.gitのディレクトリのみです。
$ git checkout --orphan 5.4
$ git reset --hard
　
次に、ここにLaravel 5.4の初期ファイルを入れますが、.gitのディレクトリがあるためにエラーがでて入れることができません。それゆえに、一旦tmpのディレクトリに入れてから中身を移します。.env.exampleなどのドットファイルも移していることに注意してください。.gitを違うディレクトリに移してから、同ディレクトリに作成してもいいですね。そして、gitのディレクトリを戻す。
$ composer create-project --prefer-dist laravel/laravel tmp 5.4.*
$ mv tmp/* tmp/.[^.]* .
$ rmdir tmp
　
追加されたフォルダーやファイルをコミットします。そして、5.4ブランチをmasterに改名します。
$ git add .
$ git commit -m 'Laravel 5.4 init'
$ git branch -m master
　
そして最後にレポジトリ(github)にプッシュします。全部入れ替えるので –forceオプションが必要です。
$ git push -u origin master --force
$ git branch -a
* master
  remotes/origin/5.3
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
ということで、githubでは以下のようにドロップダウンに２つのブランチが見えます。



Debugbarで楽々デバッグ
Mon, 06 Jun 2016 03:25:24 +0900
以前に紹介した、Debugbar。
私には、もうなくてはならないものになりました。対象の画面で実行されたDBのクエリーはすべて見ることができるし、セッションの中身の値も確認できる。
そして、もうひとつ、プログラムの中で自分が見たいという変数をdebug()のヘルパー関数で、以下のように使用すれば、
class UserController extends Controller
{
	public function getUpload()
	{
		return view('user/upload');
	}

	public function postUpload(Request $request)
	{
		debug($request->all());

		$file = $request->file('file');

		$filename = $file->getClientOriginalName();

		$request->file('file')->move(public_path('images'), $filename);
	}
}
以下の画面のように、バーで表示してくれます。

行をクリックすれば、詳細を表示します。



ユーザー認証（１４）Debugbar
Fri, 12 Feb 2016 08:26:57 +0900
マルチ認証のトピックが続いていますが、同じブラウザを使用して「会員」と「管理者」の両方にログインしたらどうなるのでしょう？
ログインはブラウザのクッキーを使用して、サーバーのセッションと繋がっています。Laravelはそれぞれに違うセッション、違うクッキーを使用するのでしょうか？それとも同じセッションで違う情報を保持するのでしょうか？興味ありませんか？
ということで、便利なツールの紹介とともに、認証のセッションがどうなっているかチェックしてみましょう。
ここで紹介するツールはDebugarというLaravelのためのツールです。
これをインストールすると、画面下にDebugarの情報パネルが表示され、実行したLaravelの様々な情報を見ることができます。
例えば、以下は会員のログイン成功直後の画面ですが、実行したDBのクエリーを見ることができます。DBテーブルusersに対するクエリーがあります。

このツールのインストールはとても簡単です（GitHubにリポあります）。
まず、以下を実行します。
composer require barryvdh/laravel-debugbar
composer.jsonが更新されライブラリがダウンロードされインストールされます。
次に、config/app.phpに以下を追加します。
...
   'providers' => [
...
       Barryvdh\Debugbar\ServiceProvider::class,
   ],

   'aliases' => [
...
      'Debugbar' => Barryvdh\Debugbar\Facade::class,
   ],
];
これで完了です。
先の会員ログインを実行では、DBのクエリーの情報を見ることができましたが、セッションはどうなのでしょう？

赤丸の部分がセッションの情報を見るボタンです。そして赤の四角の部分が、会員が認証されていることを示す情報です。login-user..の部分です。
さて、同じブラウザでもう１つタブを作成して今度は、管理画面にログインしてみましょう。以下が、ログイン成功後のセッション値です。

値が増えていますね。しかし、今度は、login-admin..と違う名前となっていますね。
つまり、セッションの中でguardの値をセッションの変数名として使い分けているわけです。


アーティザンのティンカー
Wed, 12 Aug 2015 12:44:26 +0900
前回の投稿「ダーティーなレコード」で、DBレコードが更新されたかどうか、簡単に実験してチェックできるツールを紹介しましょう。
ララベルにはコマンドで実行できる強力なツール、その名もアーティザン(Artisan)があります。このアーティザン、Macを含めてUnix系の開発者には便利でこのうえないツール。しかも、複数のコマンドがあるわけでなく、１つのコマンドでオプションを変えるだけでいろいろなことができる優れもの。
$ php artisan list
とタイプすればたくさんのオプションのヘルプがでてきます。
さて、この中でとてもユニークなのが、今回紹介するTinker
$ php artisan tinker

Psy Shell v0.4.4 (PHP 5.5.25 - cli) by Justin Hileman
>>>
まず、Eloquentのモデルを利用してレコードを取ってきましょう.
>>> use App\Models\Product
=> false
>>> $product = Product::find(1)
=> <App\Models\Product #000000000db510bc000000004b81eec1> {
       product_id: 1,
       created_at: "2015-04-25 12:22:10",
       updated_at: "2015-08-05 13:15:25",
       name: "test product",
       price: "1000"
   }
>>>
次に、価格（price）を更新してみます。
>>> $product->price = "2000"
=> "2000"
>>> $porduct->isDirty()
=> true
>>> $product->save()
=> true
>>> $product
=> <App\Models\Product #000000000ee7a5b70000000066692faa> {
       product_id: 1,
       created_at: "2015-04-25 12:22:10",
       updated_at: "2015-08-11 09:33:23",
       name: "test product",
       price: "2000"
   }
>>>
isDirty()は変更されたのでもちろんtrue、また update_atも更新時の日時に更新されています。
今までのDBのクエリの履歴を見たいなら、
>>> DB::getQueryLog()
=> [
       [
           "query"    => "select * from `product` where `product`.`product_id` = ? limit 1",
           "bindings" => [
               3
           ],
           "time"     => 0.56
       ],
       [
           "query"    => "update `product` set `updated_at` = ?, `price` = ? where `product_id` = ?",
           "bindings" => [
               "2015-08-11 09:33:23",
               "2000",
               3
           ],
           "time"     => 3.13
       ]
   ]
>>>
さて、今度は同じ値を入れてみましょう。
>>> $product->price = "2000"
=> "2000"
>>> $product->isDirty()
=> false
>>> $product->save()
=> true
>>> $product
=> <App\Models\Product #000000000ee7a5b70000000066692faa> {
       product_id: 1,
       created_at: "2015-04-25 12:22:10",
       updated_at: "2015-08-11 09:33:23",
       name: "test product",
       price: "2000"
   }
>>>
レコードではダーティーではなく(false)、またsave()しているにもかかわらず、update_atの値にも変化ありませんね。
ここで、DB::geQueryLog()を実行すれば、さきとまったく同じ履歴が出てきます。つまり、DBの処理は何もなかったを証明します。
ティンカー便利ですね。ブラウザを使わなくとも、ユニットテストを書かなくても、ここでテストができるのが便利です。
追記：
今回のティンカーは、バージョン5.1のララベルを使用しています。他のバージョンでは、コマンドのプロンプトのシンボルが違ったりや行末のセミコロンの必須となったります。ご注意を。

開発ツール on ララジャパン

deployerで複数サイトを管理（２）タスクを定義

Laravelアプリをダウンさせるタスクを定義

タスクを強化

deployerで複数サイトを管理（１）

Deployerのインストール

Deployerの初期化

複数のサイトにいっぺんにアクセス

ホスト情報をYAMLファイルにする

開発のタスクを整理するためのツール

開発に必要なタスクの種類

コード作成後に実行するタスク

ローカル開発環境を立ち上げるタスク

インストール作業のためのタスク

composer

npm

make

Rectorでリファクタリングを自動化 その３

Rectorのインストール(おさらい）

自作ルールでリファクタリングを自動化

定数をEnumに変換する

カスタムルール作成

カスタムルールを定義

getRuleDefinition()

getNodeTypes()

refactor()

リファクタ実行

参照

【mac】phpbrewで複数のバージョンを切り替えて使う

PHPBrew

OSのサポート

install

PHPbrewを使ってPHPをインストール

バリアント

まとめ

Rectorでリファクタリングを自動化 その２

Set Lists

Level Sets

一部のruleを無視する

まとめ

参照

Rectorでリファクタリングを自動化 その１

Rectorとは？

インストール

設定ファイルを追加

実践

まとめ

参照

光速のVite

Viteが採用された理由

Laravel-Mixの問題点

Viteはノーバンドル

Viteを体感してみる

本番用にはバンドルする

まとめ

Laravel Pintをカスタム設定

インストール

実行

カスタム設定

Laravel 8.x更新で変わったこと（４）php-cs-fixer

メールの送信（３）メール受信サービス Mailhog

インストール

Laravelの環境変数の設定

メール送信テスト

メールの送信（２）メール受信サービス Mailtrap

Mailtrapのようなサービスの必要性

サインアップ

Laravelの環境変数の設定

Mailtrapのインボックス

無料はいつまで？

コードスタイルを統一するツール

インストール

実行

Laravelへの移行（３）管理画面のスターターパッケージ Laravel-AdminLTE

インストール

ルック

設定

採用できそう？

Laravelへの移行（２）管理画面のスターターパッケージ Laravel Boilerplate

デモ

Rectorでリファクタリングを自動化　その３

Rectorでリファクタリングを自動化　その２

Rectorでリファクタリングを自動化　その１

メールの送信（３）メール受信サービス　Mailhog

メールの送信（２）メール受信サービス　Mailtrap

Laravelへの移行（３）管理画面のスターターパッケージ　Laravel-AdminLTE

Laravelへの移行（２）管理画面のスターターパッケージ　Laravel Boilerplate

Let's Encrypt　無料のセキュア認証