PHP on ララジャパン

混乱してはいけないLaravelの動的プロパティ - PHP8.2で廃止となった編

Mon, 20 May 2024 08:31:31 +0900

さあ大変です。PHP 8.2において動的プロパティが廃止(Deprecated）となりました。PHP 9.0ではErrorExceptionが投げられるようです。動的プロパティをたくさん使っているLaravelのプログラムは大丈夫なのでしょうか？

動的プロパティが廃止とはどういうこと？

空のクラスを作成します。

app/Models/Person.php

namespace App\Models;

class Person
{
    //
}

PHP 8.1では、好き勝手に動的プロパティを作成できます。

> use App\Models\Person;
> $person = new Person;
= App\Models\Person {#5068}

> $person->first_name = 'Joe';
= "Joe"

> $person->first_name;
= "Joe"

しかし、同様なコードの実行をPHP 8.2下で行うと、

> use App\Models\Person;
> $person = new Person;
= App\Models\Person {#5068}

> $person->first_name = 'Joe';

   DEPRECATED  Creation of dynamic property App\Models\Person::$first_name is deprecated.

= "Joe"

と、しっかり廃止のエラーが表示されます。Deprecated（廃止）なのでDisabled（無効）になったわけではなくエラーとはならずに警告のみです。つまり、実行はされているので値はGETできます。

> $person->first_name;
= "Joe"

もちろん、動的プロパティでなくプロパティがクラスで予め宣言されているなら問題ありません。

app/Models/Person.php

namespace App\Models;

// 以下はModelを継承していないことに注意
class Person
{
    public string $first_name;
}

と定義したなら、以下のようにfirst_nameをセットしても、警告なしです。

> use App\Models\Person;
> $person = new Person;
= App\Models\Person {#5068
    +first_name: ? string,
  }

> $person->first_name = 'Joe';
= "Joe"

PHP 8.2以降で動的プロパティに対応するには、どうしたらよいのでしょう？

マジックメソッドを使う

前回説明したマジックメソッドを使用するなら問題ありません。

app/Models/Person.php

namespace App\Models;

// 以下はModelを継承していないことに注意
class Person
{
    protected array $attributes = [];

    //　プロパティの値を取得
    public function __get(string $key ) : ?mixed
    {
        if (isset($this->attributes[$key])) {
            return $this->attributes[$key];
        }

        return null;
    }

    //　プロパティを設定
    public function __set(string $key, mixed $value)
    {
        $this->attributes[$key] = $value;
    }
}

ということは、LaravelのEloquentやCollectionを使用したコードを書き換える必要はなしです。良かったです。安堵！

stdClassを使う

stdClassを使っても動的プロパティの作成が警告なしに可能となります。

> $person = new StdClass;
= {#5072}

> $person->first_name = 'Joe';
= "Joe"

さらに、stdClassを継承してクラスを作成してもOKです。

app/Models/Person.php

namespace App\Models;

use stdClass;

class Person extends stdClass;
{
    //
}

Attributeを使う

PHP8.0 から導入されたAttributeを使用しても動的プロパティの作成が可能です。

つまり、

app/Models/Person.php

namespace App\Models;

// 以下は、動的プロパティ許可としています
#[\AllowDynamicProperties]
class Person
{
    //
}

参照

混乱してはいけないLaravelの動的プロパティ – Eloquent編混乱してはいけないLaravelの動的プロパティ – Collection編混乱してはいけないLaravelの動的プロパティ – 裏側編

混乱してはいけないLaravelの動的プロパティ - 裏側編

Wed, 15 May 2024 23:27:32 +0900

今回は、Laravelの動的プロパティの裏側を見てみます。つまり、どうしてインスタンスのプロパティがメソッドのコールとなるのか。

マジックメソッド

知って入ればなんのことはないですが、phpではマジックメソッドという関数をクラスで定義すれば、クラスで定義されているメソッドを、インスタンスのプロパティとしてアクセスすることができます。

簡単にマジックメソッドの説明をしましょう。

まずは、Personというクラスを作成します。Modelsのネームスペースに入れてありますが、デモのためにEloquentのModelクラスは継承しません。

app/Models/Person.php

namespace App\Models;

// 以下はModelを継承していないことに注意
class Person
{
    protected array $attributes = [];

    //　プロパティの値を取得
    public function __get(string $key ) : ?mixed
    {
        if (isset($this->attributes[$key])) {
            return $this->attributes[$key];
        }

        return null;
    }

    //　プロパティを設定
    public function __set(string $key, mixed $value)
    {
        $this->attributes[$key] = $value;
    }

    //　すべてのプロパティをリスト
    public function getAttributes(): array
    {
        return $this->attributes;
    }
}

２つの_（アンダースコア）で始まるメソッド名、__get()と__set()がマジックメソッドです。

tinkerで実行すると、以下のようにインスタンスに好きなプロパティ名で値を与えることができます。

> use App\Models\Person;
> $person = new Person;
= App\Models\Person {#5077}

> $person->first_name = 'Joe';
= "Joe"

> $person->last_name = 'Biden';
= "Biden"

裏では、上のクラスの定義の__set()、つまりミューテーターが実行されています。その証拠に、$attributeの中身を見ると、

> $person->getAttributes();
= [
    "first_name" => "Joe",
    "last_name" => "Biden",
  ]

と連想配列に値が入っています。

また、__get()の定義のために、

> $person->first_name;
= "Joe"

> $person->last_name;
= "Biden"

とそれぞれのプロパティの値を取り出すことが可能です。

しかし、$attributesにキーがないプロパティにアクセスすると、

> $person->full_name;
= null

とnullを返します。

プロパティがなかったらメソッドコール

さて、今度はプロパティが存在しないときにメソッドをコールしてみましょう。プロパティがfull_nameならfullName()をコールするように対応してみました。

namespace App\Models;

use Illuminate\Support\Str;

class Person
{
    protected array $attributes = [];

    public function __get(string $key ) : mixed
    {
        if (isset($this->attributes[$key])) {
            return $this->attributes[$key];
        }

        // full_nameがキーなら、fullName()をコール
        if (method_exists($this, Str::camel($key))) {
            return $this->{Str::camel($key)}();
        }

        return null;
    }
    
    ...

    // 新規に定義
    protected function fullName()
    {
        return $this->attributes['first_name'].' '.$this->attributes['last_name'];
    }
}

実行すると、full_nameの動的プロパティの値が返ります。

> $person->full_name;
= "Joe Biden"

もちろん、LaravelのModelのクラスではいろいろなケースがあるので、その動的プロパティのメカニズムはこれよりはるかに複雑ですが、マジックメソッドを使用して対応するのは同じです。

Laravelでのマジックメソッド

さて、Laravelで本当にマジックメソッドが使用されているか確認してみましょう。

まずは、EloquentのModelクラスでは、以下のように、マジックメソッドが定義されています。

vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php

namespace Illuminate\Database\Eloquent;

...
abstract class Model implements Arrayable, ArrayAccess, CanBeEscapedWhenCastToString, HasBroadcastChannel, Jsonable, JsonSerializable, QueueableEntity, Stringable, UrlRoutable
{
...
   /**
     * Dynamically retrieve attributes on the model.
     *
     * @param  string  $key
     * @return mixed
     */
    public function __get($key)
    {
        return $this->getAttribute($key);
    }

    /**
     * Dynamically set attributes on the model.
     *
     * @param  string  $key
     * @param  mixed  $value
     * @return void
     */
    public function __set($key, $value)
    {
        $this->setAttribute($key, $value);
    }
...

このコードレベルではすっきりしていますが、興味ある方は奥までコードを辿ってみてください。いろいろなケースの対応がされています。

そして、Collectionでは、HigherOrderCollectionProxyのクラスの中で、マジックメソッドが定義されています。

vendor/laravel/framework/src/Illuminate/Collections/HigherOrderCollectionProxy.php

namespace Illuminate\Support;

/**
 * @mixin \Illuminate\Support\Enumerable
 */
class HigherOrderCollectionProxy
{
...
    /**
     * Proxy accessing an attribute onto the collection items.
     *
     * @param  string  $key
     * @return mixed
     */
    public function __get($key)
    {
        return $this->collection->{$this->method}(function ($value) use ($key) {
            return is_array($value) ? $value[$key] : $value->{$key};
        });
    }

    /**
     * Proxy a method call onto the collection items.
     *
     * @param  string  $method
     * @param  array  $parameters
     * @return mixed
     */
    public function __call($method, $parameters)
    {
        return $this->collection->{$this->method}(function ($value) use ($method, $parameters) {
            return $value->{$method}(...$parameters);
        });
    }
}

他のどのクラスでマジックメソッドが使用されているか、vendor/laravel/のディレクトリで、grepしてみました。いろいろありますね。

framework/src/Illuminate/Routing/Route.php
framework/src/Illuminate/View/InvokableComponentVariable.php
framework/src/Illuminate/Database/Eloquent/Model.php
framework/src/Illuminate/Database/Eloquent/Builder.php
framework/src/Illuminate/Bus/Batch.php
framework/src/Illuminate/Conditionable/HigherOrderWhenProxy.php
framework/src/Illuminate/Auth/GenericUser.php
framework/src/Illuminate/Mail/Events/MessageSent.php
framework/src/Illuminate/Queue/Jobs/DatabaseJobRecord.php
framework/src/Illuminate/Support/ViewErrorBag.php
framework/src/Illuminate/Support/ValidatedInput.php
framework/src/Illuminate/Support/Optional.php
framework/src/Illuminate/Support/Fluent.php
framework/src/Illuminate/Support/Stringable.php
framework/src/Illuminate/Http/Request.php
framework/src/Illuminate/Http/Resources/DelegatesToResource.php
framework/src/Illuminate/Testing/TestResponse.php
framework/src/Illuminate/Testing/TestComponent.php
framework/src/Illuminate/Container/Container.php
framework/src/Illuminate/Collections/HigherOrderCollectionProxy.php
framework/src/Illuminate/Collections/Enumerable.php
framework/src/Illuminate/Collections/Traits/EnumeratesValues.php

参照

混乱してはいけないLaravelの動的プロパティ – Eloquent編混乱してはいけないLaravelの動的プロパティ – Collection編混乱してはいけないLaravelの動的プロパティ – PHP8.2で廃止となった編

Laravel 11.xのインストール

Sat, 06 Apr 2024 07:52:04 +0900

早いものでL10がリリースされてからもう１年が経ちました。個人的な感想ですがL10では正直なところそこまで大きな変更が無かった様に思います。しかし大抵その様な場合は水面下で激しい議論が酌み交わされており次バージョンにてドラスティックな変更がやってくるもの。さてさてL11はどうなるやら、一緒に見ていきましょう！

サポート

いつも通りサポート表の確認から。まず、注意すべき点としてL11ではPHP8.2以上が必須となっています。前回のL9からL10にアップグレードする際もPHP8.0から8.1へPHPのVer要件が引き上げられました。忙しない感じもしますが、今回もPHP8.2が未インストールの場合は予め環境にインストールしておきましょう。macOSの方はphpbrewを使うと複数バージョンをインストールして切替られるので便利ですよ。

新規プロジェクト作成

早速L11をインストールしてみましょう。

$ composer create-project laravel/laravel L11.x

インストール完了後にプロジェクトディレクトリに移動し、バージョンを確認してみます。

$ cd L11.x
$ php artisan --version
>> Laravel Framework 11.0.7

2024年3月18日現在、11.0.7がインストールされました。続いて、ビルドインサーバを起動してみます。

php artisan serve

お馴染みのメニューが表示されました。

L10と比べて凝ったデザインになりましたね。続いて従来のバージョンからの変更点についてチェックしていきます。

ファイル構成の変更

Streamlined Application Structureというのが今回のアップデートの目玉のようです。要はファイル構成の変更ですが、方向性としてはより簡素で合理的な構造を目指す意図があるようです。その為、app配下の更新頻度が低いと判断されたファイル群が省かれ、各ファイルで行っていた設定はbootstrap/app.phpに集約されメソッドベースで設定する事となりました。以下がインストール直後のbootstrap/app.phpです。

bootstrap/app.php

use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Exceptions;
use Illuminate\Foundation\Configuration\Middleware;

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        commands: __DIR__.'/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        //
    })
    ->withExceptions(function (Exceptions $exceptions) {
        //
    })->create();

withMiddleware()

ミドルウェアの設定に関するファイル群、app/Http/Middleware（ディレクトリごと）とapp/Http/Kernel.phpが削除され、それらで行っていた設定はwithMiddleware()で行います。

withExceptions()

以前はapp/Exceptions/Handler.phpにて、アプリケーション上で発生するあらゆる例外を検知しレポート（ログや通知など）やレンダリング（エラー画面の表示）の制御を行っていましたが、こちらも削除されwithExceptions()にまとめられました。

withCommands()

上に表示したbootstrap/app.phpにはありませんがwithCommands()というメソッドもあります。こちらのメソッドでは元々app/Console/Kernel.phpにて行っていたCommandクラスのディレクトリを指定できます。従来通り、app/Console/Commands配下のコマンドクラスは何も設定せずとも自動でロードされますが、もし他のディレクトリに分けて運用している場合はこのメソッドを使って追加登録する必要があります。

その他、bootstrap/app.php にて行える設定についてはvendor/laravel/framework/src/Illuminate/Foundation/Configuration/ApplicationBuilder.php をご確認下さい。

ServiceProviderの統合

app/Providers配下もとてもスッキリしたものになりました。AppServiceProviderクラスを除き以下の４つのServiceProviderクラスが削除されました。

AuthServiceProvider
BroadcastServiceProvider
EventServiceProvider
RouteServiceProvider

従来はAuthServiceProviderではModelとPolicyの紐付けを、EventServiceProviderではEventとListenerの紐付けを行なっていましたが、L11.xではそれらはAppServiceProviderのboot()にてGate::policy()やEvent::listen()を用いて行う様です。

app/Providers/AppServiceProvider.php

namespace App\Providers;

use Illuminate\Support\Facades\Gate;
use Illuminate\Support\Facades\Event;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        // ModelクラスとPolicyクラスの紐付け
        Gate::policy(
            YourModel::class,
            YourPolicy::class,
        );

        // EventクラスとListenerクラスの紐付け
        Event::listen(
            YourEvent::class,
            YourListener::class,
        );
    }
}

集約されてしまうことでAppServiceProviderが肥大化してしまうのでは？と心配になりますが、Laravel標準のディレクトリ構造、且つ、標準の命名規則に従って開発していれば大抵はLaravelが自動でクラス同士の紐付けを行なってくれるので手動で設定が必要なケースはそう多くなさそうです。（ModelクラスとPolicyクラスの自動紐付けについてはPolicyで認可チェックにて解説しているので是非そちらもチェックしてみてください。）

シンプルになったControllerの基底クラス

Controllerクラスの基底クラスであるApp\Http\Controllers\Controller.phpもシンプルになりました。

app/Http/Controllers/Controller.php

namespace App\Http\Controllers;

abstract class Controller
{
    //
}

只の真っさらなabstractクラスですね。以下のL10.xのと見比べてみてください。以前はIlluminate\Routing\Controllerを継承し、２つのトレイトAuthorizesRequestsとValidatesRequestsをuseしていました。

app/Http/Controllers/Controller.php

namespace App\Http\Controllers;

use Illuminate\Foundation\Auth\Access\AuthorizesRequests;
use Illuminate\Foundation\Validation\ValidatesRequests;
use Illuminate\Routing\Controller as BaseController;

class Controller extends BaseController
{
    use AuthorizesRequests, ValidatesRequests;
}

これらのトレイトは削除された訳では無く「必要あれば適宜使ってね」という事の様です。例えば以前にPolicyで認可チェックにて紹介したコントローラヘルパのauthorize()を使用して認可チェックを行う場合はAuthorizesRequestsが必要となります。

once()

最後にリリースノートを読んでいてこれは便利そうだ、と思った新しいヘルパ関数once()を紹介します。この関数は引数に指定したコールバックの結果をそのプロセスの間中キャッシュしてくれるというものです。これは例えばDBに保存しているマスタデータを取得する際などに便利そうです。例として以下にDBに保存された都道府県名を取得するコードを書いてみました。

app/Models/Prefecture.php

namespace App\Models;

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

class Prefecture extends Model
{
    use HasFactory;

    protected $table = 'prefecture';

    public static function list(): array
    {
        return once(fn () => self::pluck('name')->all());
    }
}

once()を使って一度データを取得すれば2回目以降の呼び出しではキャッシュから参照されるのでクエリが発行されず効率的です。同一プロセス上で何度も参照が必要な場合に有効ですね。因みに以前は以下の様にstaticプロパティに退避するなどして対応していました。once()なら1行で書ける処理ですが、以前は5行も必要でした。

...
static $list;

public static function list(): array
{
    if (! isset(self::$list)) {
        self::$list = self::pluck('name')->all();
    }

    return self::$list;
}

Laravel的パーミッションの設定（visibility）

Sun, 24 Dec 2023 08:10:43 +0900

従来はプログラムから特定のパスにディレクトリやファイルを追加する際、それらのパーミッションの変更にはPHPのchmod()を使用していました。しかし、最近ドキュメントを読み返してみてLaravelらしいやり方を学んだのでまとめます。

デフォルトの権限

まずはStorageファサードを使用してstorage配下にディレクトリやファイルを追加した場合に、それらのパーミッションがどうなっているのか確認してみましょう。config/filesystems.phpの設定をデフォルトの状態から変更していない前提で話を進めます。tinkerで以下を実行してみてください。

// ディレクトリを作成
> Storage::makeDirectory('memos');
= true
// ファイルを作成
> Storage::put('memos/todo.txt', '今日のTODOリスト...');
= true

ディスクを指定していないのでデフォルトのlocalディスクドライバが選択され、storage/app配下にmemos/todo.txtが追加されたはずです。追加されたディレクトリとファイルのパーミッションを確認してみましょう。

$ ls -la storage/app/ | grep memos
drwx------  3 hikaru  staff   96 12 12 22:53 memos

$ ls -la storage/app/memos/todo.txt
-rw-r--r--  1 hikaru  staff  20 12 12 23:12 storage/app/memos/todo.txt

※ユーザ名及びグループ名は実行環境毎に異なるので仮です。ご自身の環境の値に置き換えて読み進めてください。上記の実行結果から分かる通りパーミッションは以下の通りになっていました。

memosディレクトリ（rwx------）: ユーザのみフルアクセス可能
todo.txt（rw-r--r--）: 誰でも閲覧可能、書き込みはユーザのみ可能

todo.txt自体は誰でも閲覧可能となっていますが、memosディレクトリ自体の権限がユーザにのみ付与されているので、他のユーザはその配下にアクセスする事ができません。アクセスしようとするとPermission deniedと表示されます。memosディレクトリも誰でも閲覧可能とするにはどうすれば良いでしょうか？

visibilityの設定

Laravelにおいてはパーミンションの事をvisibilityと呼ぶ様です。visibilityの設定値はpublicかprivateの２択に簡略化されており、ローカルであれクラウドであれ同じ操作でアクセス権の設定を行えます。詳しくは公式ドキュメントをご確認ください。visibilityを設定するにはsetVisibility()を使用します。第一引数にvisibilityを設定するターゲットを、第二引数にpublic or privateを指定します。例えば、前項のmemosディレクトリをpublicにするなら、

> Storage::setVisibility('memos', 'public');
= true

権限をチェックしてみましょう。

$ ls -la storage/app/ | grep memos
drwxr-xr-x  3 hikaru  staff   96 12 12 23:39 memos

誰でも閲覧可能となりましたね。今度は逆にtodo.txtをprivateにしてみましょう。

> Storage::setVisibility('memos/todo.txt', 'private');
= true

権限を確認するとユーザhikaruのみ閲覧可能となっていました。

$ ls -la storage/app/memos/todo.txt
-rw-------  1 hikaru  staff   25 12 12 23:43 todo.txt

デフォルトの設定ではpublicとprivateを指定した場合のアクセス権についてまとめると以下の通りになっていました。

filesystems.phpで詳細設定

publicやprivateによって設定されるアクセス権をより細かくカスタマイズしたいケースがあるかもしれません。その場合はfilesystems.phpにて指定する事ができます。以下はデフォルトのlocalディスクドライバの設定です。

config/filesystems.php

...
    'disks' => [

        'local' => [
            'driver' => 'local',
            'root' => storage_path('app'),
            'throw' => false,
        ],
...

これを次のように変更してみます。

config/filesystems.php

...
    'disks' => [

        'local' => [
            'driver' => 'local',
            'root' => storage_path('app'),
            'throw' => false,
            'directory_visibility' => 'public',
            'visibility' => 'public',
            'permissions' => [
                'file' => [
                    'public' => 0664,
                    'private' => 0600,
                ],
                'dir' => [
                    'public' => 0775,
                    'private' => 0700,
                ],
            ]
        ],
...

directory_visibilityとvisibilityはディレクトリやファイルを追加した際のデフォルトのvisibilityを指定しています。前項ではディレクトリ追加時のvisibilityがprivateになっていましたが、publicに変更しました。そして、permissions内ではファイルとディレクトリにおけるpublicとprivateを指定した際に割り当てるパーミッションを8進数で指定します。上記ではpublic時にグループユーザにも書き込み権限を付与しました。設定通りにアクセス権が付与されるか、再度tinkerでチェックしてみましょう。

> Storage::makeDirectory('memos2');
= true

権限を確認すると

$ ls -la storage/app/ | grep memos2
drwxr-xr-x  2 hikaru  staff   64 12 21 20:27 memos2

あれれ、グループユーザに書き込み権限が付与されていません。何故でしょう？しばらくソースコードと睨めっこしてやっと気づきました。犯人はumaskです。Storage::makeDirectory()は内部的にPHPのmkdir()を使用しているのですが、そちらのドキュメントにはこう書かれています。

また permissions は、現在設定されている umask の影響も受けます。 umask を変更するには umask() を使用します。

umaskとはUnix系OSにおいてディレクトリやファイルを追加した際のアクセス権を指定するコマンドです。例えば、私の環境、macOSではデフォルトでは標準的な022が指定されており、基本パーミッションである0777から022を引いた0755がデフォルトのパーミッションとなります。ドキュメントに書かれている通り、umask()で制限を解除してからディレクトリ作成コマンドを実行してみましょう。

> umask(000);
= 18
> Storage::makeDirectory('memos3');
= true
> Storage::put('memos3/todo.txt', '今日のTODOリスト...');
= true

パーミッションを確認すると

$ ls -la storage/app/ | grep memos3
drwxrwxr-x  3 hikaru  staff   96 12 21 20:48 memos3
$ ls -la storage/app/memos3/todo.txt
-rw-rw-r--  1 hikaru  staff   13 12 21 20:48 todo.txt

config/filesystems.phpで指定した通り、ディレクトリもファイルもグループユーザにも書き込み権限が付与されました。

クエリの累計時間にタイムアウトを設定する（２）

Thu, 27 Jul 2023 11:10:26 +0900

前回の記事にてタイムアウトとなった場合に２種類の例外がスローされる事を説明しました。クエリ実行中にタイムオーバーとなった場合は、QueryException。クエリ実行外でタイムオーバーとなり、その後クエリを実行してエラーとなる場合は、自作したTimeoutExceptionです。今回はこれらのエラーをどうキャッチしてハンドリングするのか解説します。

検証用のページ

説明の為にテスト用のコントローラを用意しました。

app/Http/Controllers/TimeoutTestController.php

<?php

namespace App\Http\Controllers;

use App\Services\DbQueryTimeout;
use Illuminate\Support\Facades\DB;

class TimeoutTestController extends Controller
{
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            return 'error';
        }

        return 'success';
    }
}

ルーティングは以下の通りです。

routes/web.php

<?php

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\TimeoutTestController;

Route::get('/timeout_test', [TimeoutTestController::class, 'index']);

indexアクションでは重いクエリが２つ実行されます。それらが正常に処理できた場合はsuccess、何かしらのエラーが発生した場合はerrorを返します。尚、GETパラメタでtimeoutの指定がある場合は、DbQueryTimeoutを使用して制限時間が設定されます。ビルドインサーバーを起動して挙動を確認してみましょう。

php artisan serv

まず、パラメタ無しで /timeout_test へアクセスしてみてください。約8秒後にsuccessと表示されるはずです。次に、timeoutパラメタを指定して制限時間を設定してみましょう。/timeout_test?timeout=5 として制限時間を5秒にしてアクセスしてみて下さい。すると、約５秒後に処理が中断されerrorと表示されるはずです。

Tips: 重いクエリをシミュレートする方法

重いクエリ = 時間が掛かるクエリ、という事でDB側でsleep()を実行してシミュレートできます。mysqlではsleep()は正常にスリープできた場合は0、途中で中断された場合は1が返却されます。しかし、実際の環境ではmax_execution_timeで指定した時間をオーバーして処理が中断された場合は１ではなくエラーが発生します。sleep()においてもタイムオーバーした場合にエラーを返させるには、unionで追加の処理を実行すればOKです。追加の処理はなんでも良いので今回は適当にselect 1としました。実際にmysql clientにて以下を実行して試してみると理解しやすいと思います。

# 制限時間を5秒に設定
mysql> set max_execution_time = 5000;
Query OK, 0 rows affected (0.01 sec)

# 制限時間内に終わるsleepなら0が返却される
mysql> select sleep(4);
+----------+
| sleep(4) |
+----------+
|        0 |
+----------+
1 row in set (4.05 sec)

# 制限時間内に終わらずsleepが中断されたら1が返却される
mysql> select sleep(5);
+----------+
| sleep(5) |
+----------+
|        1 |
+----------+
1 row in set (5.06 sec)

# unionで追加の処理を含めるとエラーが返却される
mysql> select sleep(6) union select 1;
ERROR 3024 (HY000): Query execution was interrupted, maximum statement execution time exceeded

エラーのハンドリング

冒頭で述べた通り制限時間をオーバーした場合は２種類のタイムアウトエラーが発生します。しかし、アプリにおいては当然それ以外のエラーも発生し得るので、タイムアウトエラーとそうでないエラーの場合で判別してエラーを出し分ける必要があります。それぞれどの様に判別すれば良いでしょうか。

TimeoutExceptionをキャッチ

先に簡単な方から、TimeoutExceptionを判別する場合です。こちらはシンプルにスローされたExceptionのインスタンスをチェックすれば判別できます。TimeoutTestController.php のindexアクションを以下の様に書き換えてみましょう。

app/Http/Controllers/TimeoutTestController.php

...
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // クエリ以外の処理で3秒掛かった
            sleep(3);

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            // TimeoutExceptionの場合のエラー文言
            if ($e instanceof TimeoutException) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }

TimeoutExceptionは、クエリ実行外でタイムオーバーし、次のクエリが実行されるタイミングでスローされます。そちらを再現する為に、クエリ１とクエリ２の間にPHP側のスリープを3秒挟みました。これにより制限時間が5秒の場合はTimeoutExceptionがスローされるはずです。再度、ビルドインサーバにて/timeout_test?timeout=5へアクセスしてみて下さい。今度はtimeout errorと表示されたはずです。

クエリ実行中にタイムアウトした場合のエラー

クエリ実行中にタイムアウトした場合はQueryExceptionがスローされます。QueryExceptionはタイムアウト以外でもスローされる例外ですので、前項のTimeoutExceptionの様にインスタンスだけではタイムアウトエラーを判別できません。判別には一歩踏み込んで、$e->errorInfoのチェックが必要です。errorInfoはQueryExceptionの親クラスであるPDOExceptionにセットされていた値で、PHPマニュアルによると、データベースハンドラにおける直近の操作に関連する拡張エラー情報が配列で格納されています。タイムアウトエラーとしてQueryExceptionがスローされた際の$e->errorInfoは以下の様になります。

[
  0 => "HY000"
  1 => 3024
  2 => "Query execution was interrupted, maximum statement execution time exceeded"
]

0はSQLSTATEエラーコード、1はドライバ固有のエラーコード、2はそのエラーメッセージです。判別には1のドライバ固有のエラーコードを使用します。こちらの記事によると、max_execution_timeの設定をオーバーした場合のエラーコードは MySQL 8.0.19 以前は3024か1028で、以降は3024に統一されたとの事です。私の環境はまだMySQL5.7なので、1028のエラーコードも補足する必要があります。これらを考慮して、TimeoutTestControllerの例外処理部分を次の様に修正しました。

app/Http/Controllers/TimeoutTestController.php

...
        } catch (\Exception $e) {
            $timeoutError = false;

            switch (get_class($e)) {
                case TimeoutException::class:
                    $timeoutError = true;
                    break;

                case QueryException::class:
                    if (in_array($e->errorInfo[1], [3024, 1028])) {
                        $timeoutError = true;
                    }
                    break;
            }

            if ($timeoutError) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }
}

インスタンスのチェックはswitch文でget_class($e)でクラス名を取得して分岐する様に変更しました。QueryExceptionの場合はerrorInfoでエラーコードもチェックします。クエリ実行中にタイムオーバーとなるように/timeout_test?timeout=7へアクセスしてみて下さい。再度、timeout errorが表示されるはずです。

リファクタリング

これまで説明の為にコントローラ側にタイムアウトエラーのエラー処理のコードを記述してきましたが、DbQueryTimeoutと一緒に色々な箇所で使い回すのでまとめておいた方が良さそうです。という事で、DbQueryTimeout::isTimeoutError()にコードを移しました。

app/Services/DbQueryTimeout.php

...
    // タイムアウトエラー発生？
    public static function isTimeoutError(\Exception $e): bool
    {
        $timeoutError = false;

        switch (get_class($e)) {
            case TimeoutException::class:
                $timeoutError = true;
                break;

            case \Illuminate\Database\QueryException::class:
                if (in_array($e->errorInfo[1], [3024, 1028])) {
                    $timeoutError = true;
                }
                break;
        }

        return $timeoutError;
    }
...

isTimeoutError()はシンプルにタイムアウトエラーか否かを判別するメソッドです。このメソッドを使う事でTimeoutTestController側は次の様にシンプルになりました。

app/Http/Controllers/TimeoutTestController.php

<?php

namespace App\Http\Controllers;

use App\Services\DbQueryTimeout;
use Illuminate\Support\Facades\DB;

class TimeoutTestController extends Controller
{
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // クエリ以外の処理で3秒掛かった
            sleep(3);

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            if (DbQueryTimeout::isTimeoutError($e)) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }
}

クエリの累計時間にタイムアウトを設定する（１）

Thu, 27 Jul 2023 11:06:11 +0900

先日、管理サイトにてアラートが発生しました。調査すると、ある検索画面で利用者が重いクエリを連続で発行した事が原因でした。待ち時間が長かった為、不安になり検索ボタンを連打してしまったようです。サーバに負荷を掛ける操作については注意喚起するとして、待ち時間に制限が無いのはよくありません。そこで、検索処理に制限時間を設ける事にしました。今回はそちらの実装にあたって色々学んだことがあるので紹介します。

クエリの実行時間を制限する

今回実装した内容を簡単に説明すると、検索処理に対して実行可能時間を設定し、時間切れとなった場合にエラーを返すというものです、要はタイムアウトの設定です。検索処理においてボトルネックとなっていたのはDBへのクエリ部分で、それ以外の処理時間は無視して良いレベルでした。従って、クエリの実行時間に制限を設ける事にしました。

クエリにタイムアウトを設定する方法については過去の記事の「クエリーの実行所有時間の制限」の項目で紹介されており、今回もこちらを使います。簡単におさらいすると、DB::statement()を使用して、MySQLのmax_execution_timeを設定する方法です。例えば、以下は5秒に制限する場合のコードです。

DB::statement('SET SESSION MAX_EXECUTION_TIME = 5000');

こちらを実行すると、以降クエリで5秒以上掛かった場合にQueryExceptionがスローされます。

クエリの累計時間を制限する

ボトルネックとなるクエリが１つの場合は前項の方法で制限時間を設ければOKですが、今回の実装先には重いクエリが複数実行されており、それらの累計時間を制限する必要がありました。例えば、以下のように制限時間を５秒に設定した場合、クエリ１とクエリ２で合わせて５秒を超えたらタイムアウトエラーとします。

クエリの累計時間に制限を設けるには、クエリを実行する毎に都度残り時間を計算し、それを前項で紹介した方法で設定していけば良さそうです。つまり、以下の様に

クエリ１の時点では残り時間を５秒として制限時間を設定しますが、クエリ２の時点ではクエリ１で３秒掛かったので、残りの実行可能時間２秒を制限時間として再設定します。

DbQueryTimeout.php

ロジックについて理解が深まったところで、実際のコードを紹介します。クエリの制限時間を管理するクラスとして app/Services 配下に DbQueryTimeout.php を追加しました。

app/Services/DbQueryTimeout.php

<?php

namespace App\Services;

use App\Exceptions\TimeoutException;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Str;

class DbQueryTimeout
{
    const TIMEOUT_QUERY = 'SET SESSION MAX_EXECUTION_TIME';

    public static $maxExecutionTime;  // 最大実行可能時間（ミリ秒）

    public static $processStartTime;  // プロセス開始時刻（マイクロ秒）

    // タイムアウト設定初期化
    public static function set(int $seconds): void
    {
        self::$maxExecutionTime = $seconds * 1000;
        self::$processStartTime = microtime(true);

        DB::beforeExecuting(function ($query) {
            // タイムアウト設定のクエリなら何もしない
            if (Str::startsWith($query, self::TIMEOUT_QUERY)) {
                return;
            }

            // 残りの実行可能時間を計算
            $timeRemaining = self::timeRemaining();

            // 実行可能時間が残っていないなら例外スロー
            if ($timeRemaining <= 0) {
                throw new TimeoutException;
            }

            self::setTimeout($timeRemaining);
        });
    }

    // タイムアウト設定
    public static function setTimeout(int $time): void
    {
        DB::statement(self::TIMEOUT_QUERY.' = '.$time.';');
    }

    // 残りの実行可能時間をミリ秒で返す
    public static function timeRemaining(): int
    {
        return self::$maxExecutionTime - self::elapsedTime();
    }

    // 経過時間をミリ秒で返す
    public static function elapsedTime(): int
    {
        return (int) ((microtime(true) - self::$processStartTime) * 1000);
    }
}

後で説明しますが、このクラス内で使用されている TimeoutException は自作の例外クラスになります。app/Exceptions 配下に TimeoutException.php を追加してください。

app/Exceptions/TimeoutException.php

<?php

namespace App\Exceptions;

use Exception;

class TimeoutException extends Exception
{
}

DbQueryTimeout の使い方はとてもシンプルで、実行時間を制限したい箇所の最初にset()を実行するだけです。set()の引数には制限時間を秒で指定します。例えば、制限時間を５秒としたいなら以下の様に。

DbQueryTimeout::set(5);

すると、set()が実行された時点からカウントダウンが始まり、タイムオーバーとなった場合は以下の２パターンでエラーが発生します。

クエリ実行中
クエリ実行外で、それ以後にクエリを実行しようとした

前者の場合はQueryExceptionがスローされ、後者の場合はTimeoutExceptionがスローされます。

参考までに実装例を掲載します。以下は注文データを検索するページです。

app/Http/Controllers/InvoiceController.php

<?php

namespace App\Http\Controllers;

use App\Models\Invoice;
use App\Models\InvoiceShip;
use Illuminate\Http\Request;
use App\Services\DbQueryTimeout;
use Illuminate\Contracts\View\View;

class InvoiceSearchController extends Controller
{

    /**
     * 検索画面
     */
    public function index(Request $request): View
    {
        $input = $request->all();

        // 制限時間を5秒に設定
        DbQueryTimeout::set(5);

        // 注文データ
        $invoices = Invoice::query()
            ->whereBetween('invoice_date', [$input['date_start'], $input['date_end']])
            ->where('invoice_status', '=', $input['invoice_status'])
            ->orderBy('invoice_date', 'desc')
            ->paginate(config('local.items_per_page'))
            ->withQueryString();

        // 注文配送データ
        $invoice_ships = InvoiceShip::query()
            ->whereIn('invoice_id', $invoices->pluck('invoice_id'))
            ->where('invoice_ship_status', '=', $input['invoice_ship_status'])
            ->get();

        return view('admin.invoice_index')
            ->with(compact('input', 'invoices', 'invoice_ships'));
    }

}

上記のコントローラのindexアクションでは以下の３つのクエリが実行されています。

１ページに表示する注文データ
注文データの件数
注文データに紐づく注文配送データ

これら３つのクエリの累計実行時間が５秒を超える場合はエラーが発生します。エラーが発生した場合の処理については次の投稿で紹介します。

コードのポイント

コア部分であるset()で行われている処理について補足です。set()ではクエリ毎に実行されるbefore処理を登録しています。before処理では以下の処理が実行されます。

実行されるクエリが制限時間の設定クエリなら何もせず、そのまま実行
それ以外のクエリなら残りの実行可能時間を計算
残り時間なし（既にタイムオーバー）ならTimeoutExceptionをスロー
残り時間があるならそれを制限時間として設定

before処理の登録にDB::beforeExecuting()を使用している点がポイントです。こちらはドキュメントには載っていませんが、イベントリスナーの様にEloquentやクエリビルダにてクエリが実行される毎に直前に呼び出すコールバックを登録できます。余談ですが、after処理の登録にはDB::listen()というメソッドがあります。（こちらはドキュメントにも載っている。）

DB::beforeExecuting()のクロージャの引数$queryはSQLが文字列で渡されます。1. 実行されるクエリが制限時間の設定クエリなら何もせず、そのまま実行ではそちらが、SET SESSION MAX_EXECUTION_TIMEから始まるクエリかチェックして、そうならbefore処理を終了しそのままクエリの実行に移ります。そうしなければ、この制限時間を設定するクエリに対しても更にbefore処理をして、、、と無限ループとなってしまうからです。

長くなってしまったので、一旦ここで切ります。次回はエラー処理について解説します。

【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でリファクタリングを自動化　その３

php8.0 のキャッチアップ - コンストラクタにおける簡略記法

Sun, 23 Apr 2023 00:36:42 +0900

前回のmatch式の紹介に続き、PHP8.0で導入されたsyntaxの紹介です。今回は Constructor Property Promotion について。

Constructor Property Promotion

Classにおいてコンストラクタの引数に指定した値をそのままプロパティに割り当てる事がよくあります。例えば、以下のように。

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;
    }
}

上記ではインスタンスプロパティを宣言し、コンストラクタ内の処理で値をセットしています。引数に指定した変数を何度も書かなければならないので冗長ですね。

PHP8.0からは次のように、引数にアクセス修飾子(public, protected, private)を付与することでプロパティの宣言と値のセットを同時に行うことができます。

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

簡潔になりスッキリしました。

プロパティへの値の割当はコンストラクタの処理が走る前に行われるので、コンストラクタ内で参照する事もできます。

class Person
{
    public $initial;

    public function __construct(public string $name)
    {
        // イニシャルを取得
        $this->initial = strtoupper(substr($this->name, 0, 1));
    }
}

// インスタンス生成時にイニシャルが割り当てられている
$person = new Person('Steve');
echo $person->initial;

>>> 'S'

導入する事でシンプルに行数が減るので良いのですが、既存のプロジェクトのクラスを全て書き換えるのは骨が折れそうです。

何か一括で書き換える方法は無いものかと調べた処、 Rectorというツールでできることが分かりました。次回の記事でその手順を紹介させていただきます。

php8.0 のキャッチアップ - match式

Fri, 24 Feb 2023 07:02:58 +0900

巷ではLaravel 10がリリースされ賑わっていますが、最近私が担当した案件はL9へのUpgradeです。いつもの様にLaravel Shiftが出してくれるPull Requestを眺めていると、見慣れない記法が出てきました。調べてみるとPHP8.0から導入されてた記法でした。

PHP8.0がリリースされて間も無くキャッチアップしたはずなのですが、全く記憶にありません。ということで、再度PHP8.0から導入された機能を復習しました。いくつか取り入れたい記法を見つけたのでご紹介します。今回はmatch式です。

match式

公式マニュアルより抜粋。

$return_value = match (制約式) {
    単一の条件式 => 返却式,
    条件式1, 条件式2 => 返却式,
};

match式はswitch文と似ています。条件とそれにmatchした場合に返却する値を指定します。

switch文と異なり条件にmatchしているか比較する際に"=="ではなく"==="が用いられます。

つまり、

// switch文
$num = '0';

switch ($num) {
    case 0:
        echo "integer zero";
        break;
    case '0':
        echo "string zero";
}

>> integer zero

// match式
$matched = match ($num) {
    0 => "integer zero",
    '0' => "string zero",
};

echo $matched;

>> string zero

因みにmatchは式なので末尾のセミコロンを忘れないように注意です！

複数の条件で同じ値を返す場合やいずれの条件にも当てはまらなかった場合（デフォルト）の書き方はswitch文と似ているので理解しやすいです。

$matched = match ($trafficSignal) {
    'blue', 'green' => 'go',    // blue, green のいずれかなら
    'yellow' => 'caution',
    'red' => 'stop',
    default => 'nothing to do'    // いずれの条件にもmatchしないなら
};

Laravel9から学ぶ活用方法

Laravel9からはPHP8.0以上が要件となった事で、ソースコード内でも色々な箇所で活用されている様です。どの様な使い方をしているのでしょうか？

例えば、Handler.php にて例外がスローされた際のレスポンスをレンダリングしている箇所では

vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php

    public function render($request, Throwable $e)
    {
        〜〜省略〜〜

        return match (true) {
            $e instanceof HttpResponseException => $e->getResponse(),
            $e instanceof AuthenticationException => $this->unauthenticated($request, $e),
            $e instanceof ValidationException => $this->convertValidationExceptionToResponse($e, $request),
            default => $this->renderExceptionResponse($request, $e),
        };
    }

前の段落で扱ったサンプルコードではいずれも制約式に変数を渡していましたが、こちらはtrueを指定しています。そして、上から順番にtrueを返す条件式が無いかチェックしていきます。

もし、$eがHttpResponseExceptionのインスタンスなら、$e->getResponse()を実行して結果を返却。それ以外でもし、$eがAuthenticationExceptionのインスタンスなら、$this->unauthenticated($request, $e)を実行して結果を返却。それ以外でもし、、、（以下省略）

これはつまり、従来は if … elseif … で書いていたパターンですね。

実際、Laravel 8まではif文で書かれていた様です。

vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php

    public function render($request, Throwable $e)
    {
        〜〜省略〜〜

        if ($e instanceof HttpResponseException) {
            return $e->getResponse();
        } elseif ($e instanceof AuthenticationException) {
            return $this->unauthenticated($request, $e);
        } elseif ($e instanceof ValidationException) {
            return $this->convertValidationExceptionToResponse($e, $request);
        }

        return $this->shouldReturnJson($request, $e)
                    ? $this->prepareJsonResponse($request, $e)
                    : $this->prepareResponse($request, $e);
    }

if … elseif … よりもmatch式を使った書き方の方が行数も少ないし、随分シンプルな印象を受けます。今後の開発時に活用していきたいと思いました。

フォルダーやサブフォルダ内のすべてのブレードファイル名の取得

Tue, 31 May 2022 06:28:03 +0900

あるプロジェクトで使用されているブレードファイル内のHTML文の置換が必要となりました。aritisanコマンドを作成して、resources/viewsのファイル１つずつオープンして上書きが必要です。さて、問題はサブフォルダーやサブサブフォルダーがあるフォルダーからどうやってファイル名を取得するか。

resources/viewsのフォルダー

まずは、treeコマンドで目的のフォルダー内を見てみます。

resources/views
├── auth
│   ├── confirm-password.blade.php
│   ├── forgot-password.blade.php
│   ├── login.blade.php
│   ├── passwords
│   │   ├── confirm.blade.php
│   │   ├── email.blade.php
│   │   └── reset.blade.php
│   ├── register.blade.php
│   ├── reset-password.blade.php
│   ├── verify.blade.php
│   └── verify-email.blade.php
├── dashboard.blade.php
├── home.blade.php
├── layouts
│   ├── app.blade.php
│   ├── guest.blade.php
│   └── navigation.blade.php
├── test.blade.php
├── user
│   └── search.blade.php
├── vendor
│   └── pagination
│       ├── bootstrap-4.blade.php
│       ├── default.blade.php
│       ├── semantic-ui.blade.php
│       ├── simple-bootstrap-4.blade.php
│       ├── simple-default.blade.php
│       ├── simple-tailwind.blade.php
│       └── tailwind.blade.php
└── welcome.blade.php

結構ネストされていますね。

ここのblade.phpファイルをすべて取得するのが今回のゴールです。

Webmozart Glob

調査すると、もうすでに素晴らしいパッケージがこのためにありました。

$ composer require webmozart/glob

とパッケージをインストールして、tinkerで実行します。

>>> Glob::glob(base_path('resources/views/**/*.blade.php'));
=> [
     "/var/www/repos/l8x/resources/views/auth/confirm-password.blade.php",
     "/var/www/repos/l8x/resources/views/auth/forgot-password.blade.php",
     "/var/www/repos/l8x/resources/views/auth/login.blade.php",
     "/var/www/repos/l8x/resources/views/auth/passwords/confirm.blade.php",
     "/var/www/repos/l8x/resources/views/auth/passwords/email.blade.php",
     "/var/www/repos/l8x/resources/views/auth/passwords/reset.blade.php",
     "/var/www/repos/l8x/resources/views/auth/register.blade.php",
     "/var/www/repos/l8x/resources/views/auth/reset-password.blade.php",
     "/var/www/repos/l8x/resources/views/auth/verify-email.blade.php",
     "/var/www/repos/l8x/resources/views/auth/verify.blade.php",
     "/var/www/repos/l8x/resources/views/dashboard.blade.php",
     "/var/www/repos/l8x/resources/views/home.blade.php",
     "/var/www/repos/l8x/resources/views/layouts/app.blade.php",
     "/var/www/repos/l8x/resources/views/layouts/guest.blade.php",
     "/var/www/repos/l8x/resources/views/layouts/navigation.blade.php",
     "/var/www/repos/l8x/resources/views/test.blade.php",
     "/var/www/repos/l8x/resources/views/user/search.blade.php",
     "/var/www/repos/l8x/resources/views/vendor/pagination/bootstrap-4.blade.php",
     "/var/www/repos/l8x/resources/views/vendor/pagination/default.blade.php",
     "/var/www/repos/l8x/resources/views/vendor/pagination/semantic-ui.blade.php",
     "/var/www/repos/l8x/resources/views/vendor/pagination/simple-bootstrap-4.blade.php",
     "/var/www/repos/l8x/resources/views/vendor/pagination/simple-default.blade.php",
     "/var/www/repos/l8x/resources/views/vendor/pagination/simple-tailwind.blade.php",
     "/var/www/repos/l8x/resources/views/vendor/pagination/tailwind.blade.php",
     "/var/www/repos/l8x/resources/views/welcome.blade.php",
   ]

素晴らしい！

フィルターをかけている部分の /**/ は、resources/views/以下のフォルダーとサブフォルダー（階層OK）にマッチします。そして、 *.blade.php は、拡張子が.blade.phpのファイルとマッチします。

phpのglob関数との違い

フォルダー内のファイル名を取得する関数はすでにphpの標準関数としてglob()がありますが、先のパッケージのglobと違って１レベルのフォルダーしか対応しません。

つまり、

>>> glob('resources/views/*.blade.php')
=> [
     "resources/views/dashboard.blade.php",
     "resources/views/home.blade.php",
     "resources/views/test.blade.php",
     "resources/views/welcome.blade.php",
   ]
>>> glob('resources/views/*/*.blade.php')
=> [
     "resources/views/auth/confirm-password.blade.php",
     "resources/views/auth/forgot-password.blade.php",
     "resources/views/auth/login.blade.php",
     "resources/views/auth/register.blade.php",
     "resources/views/auth/reset-password.blade.php",
     "resources/views/auth/verify-email.blade.php",
     "resources/views/auth/verify.blade.php",
     "resources/views/layouts/app.blade.php",
     "resources/views/layouts/guest.blade.php",
     "resources/views/layouts/navigation.blade.php",
     "resources/views/user/search.blade.php",
   ]
>>> glob('resources/views/*/*/*.blade.php')
=> [
     "resources/views/auth/passwords/confirm.blade.php",
     "resources/views/auth/passwords/email.blade.php",
     "resources/views/auth/passwords/reset.blade.php",
     "resources/views/vendor/pagination/bootstrap-4.blade.php",
     "resources/views/vendor/pagination/default.blade.php",
     "resources/views/vendor/pagination/semantic-ui.blade.php",
     "resources/views/vendor/pagination/simple-bootstrap-4.blade.php",
     "resources/views/vendor/pagination/simple-default.blade.php",
     "resources/views/vendor/pagination/simple-tailwind.blade.php",
     "resources/views/vendor/pagination/tailwind.blade.php",
   ]

ということは、同じレベルに存在するサブフォルダーごとに再帰処理が必要となり、不可能でないものの少々ややこしいプログラムとなりますね。

phpdotenv

Sun, 21 Jun 2020 01:14:36 +0900

Laravelのプロジェクトでは、環境変数の設定は.envのファイルで行います。インストールするプロジェクトの環境（開発、ステージング、プロダクション）ごとで内容を変更できるし、.gitignoreに入れておけばバージョン管理のレポジトリでプライベートなデータ（パスワードやapiのトークンなど）を共有する必要もなく安全です。この機能、私の昔のphpのプロジェクト、つまりLaravel生誕以前の時代でのプロジェクトで現在もお客さんに使用されているプロジェクトでも取り入れたいです。

まず、この機能を提供するのは、phpdotenvというパッケージです。

https://github.com/vlucas/phpdotenv

Laravelのプロジェクトでは、以下のコマンドを実行すると、

$ composer show | grep dotenv
vlucas/phpdotenv                      v3.6.4   Loads environment variables from `.env` to `getenv()`, `$_ENV` and `$_SERVER` automagically.

とパッケージが使用されていることが確認されます。

さて、Laravelでないphpのプロジェクトでこのパッケージを使うには、以下のように、プロジェクトのディレクトリを作成してから、パッケージをインストールします。

$ mkdir dotenv
$ composer require vlucas/phpdotenv

チェックのためにテストのプログラムを作成します。

test.php

<?php
require_once 'vendor/autoload.php';
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();                                                                                                                                                                                                   

echo $_ENV['BASE_DIR']."\n";

.envのファイルも作成します。

.env

BASE_DIR=/var/www/example

この時点で、このプロジェクトのディレクトリ構造は、以下のようになります。

.
├── composer.json
├── composer.lock
├── .env
├── test.php
└── vendor
    ├── autoload.php
    ├── composer
    ├── graham-campbell
    ├── phpoption
    ├── symfony
    └── vlucas

テストを実行してみます。

$ php test.php
/var/www/example

.envから値を取得できましたね。以下のような設定も可能です。

.env

BASE_DIR=/var/www/example
IMAGE_DIR=${BASE_DIR}/images

すでに設定した環境変数を.envの中で変数として使用できます。つまり、Laravelでも同様なことができるのですね、

連想配列のマージ

Sat, 08 Sep 2018 06:15:58 +0900

今回はLaravelを離れてPHPのベーシックの話となります。連想配列（associative array）のマージに関してです。なかな知っているようで使用を間違うことがあります。

そういうきは、私が大好きなツール、tinkerを使ってちょいちょいと実行して確認してみるのが一番。

array_merge

まずは、array_mergeを使用して２つの配列、$productと$moreをマージ。

>>> $product = ['product_id' => 1, 'name' => '商品名']
=> [
     "product_id" => 1,
     "name" => "商品名",
   ]
>>> $more = ['price' => 200]
=> [
     "price" => 200,
   ]
>>> array_merge($product, $more)
=> [
     "product_id" => 1,
     "name" => "商品名",
     "price" => 200,
   ]

両方の配列の項目が１つに収まります。

さて、両方の配列に同じ項目があるときはどうでしょう？

>>> $product = ['product_id' => 1, 'name' => '商品名']
=> [
     "product_id" => 1,
     "name" => "商品名",
   ]
>>> $more = ['price' => 200, 'name' => '上書き商品名']
=> [
     "price" => 200,
     "name" => "上書き商品名",
   ]
>>> array_merge($product, $more)
=> [
     "product_id" => 1,
     "name" => "上書き商品名",
     "price" => 200,
   ]

後者の配列に前者と同じ項目があるなら、後者の配列の値が前者を上書きとなります。

+

連想配列をマージできるのは、array_mergeだけではありません。足し算の+のオペレータも同様なことができます。

>>> $product = ['product_id' => 1, 'name' => '商品名']
=> [
     "product_id" => 1,
     "name" => "商品名",
   ]
>>> $more = ['price' => 200, 'name' => '上書き商品名']
=> [
     "price" => 200,
     "name" => "上書き商品名",
   ]
>>> $product + $more
=> [
     "product_id" => 1,
     "name" => "商品名",
     "price" => 200,
   ]

しかし今度は、後者の配列に前者と同じ項目があるなら、上書きは起こりません。

キーが数字のとき

上の例は、連想配列のキーが文字列でしたが、数字のときにはどうなるでしょう？　例えば、キーにDBのレコードのID（数字）を入れて配列を作成するケースは良くあります。

>>> $products = [11 => '商品A', 12 =>'商品B']
=> [
     11 => "商品A",
     12 => "商品B",
   ]
>>> $more_products = [13 => '商品C', 14 => '商品D']
=> [
     13 => "商品C",
     14 => "商品D",
   ]
>>> array_merge($products, $more_products)
=> [
     [
       "商品A",
     ],
     [
       "商品B",
     ],
     [
       "商品C",
     ],
     [
       "商品D",
     ],
   ]
>>> $products + $more_products
=> [
     11 => [
       "商品A",
     ],
     12 => [
       "商品B",
     ],
     13 => [
       "商品C",
     ],
     14 => [
       "商品D",
     ],
   ]

サプライズ！上の例のように両方の配列のキーがどれも数字なら、array_mergeでは、割り当てたキーが皆消えてしまいます。実際には消えるのではなく、キーが0,1,2,3と順番に与えられて通常の配列になります。しかし、+で足し算をするなら、キーは結果においてキープされます。しかし、両者の配列に同じキーがあるなら、さきほどのように後者は前者を上書きはしません。

>>> $products = [11 => '商品A', 12 =>'商品B']
=> [
     11 => "商品A",
     12 => "商品B",
   ]
>>> $more_products = [12 => '商品C', 13 => '商品D']
=> [
     12 => "商品C",
     13 => "商品D",
   ]
>>> $products + $more_products
=> [
     11 => "商品A",
     12 => "商品B",
     13 => "商品D",
   ]

php5.6からphp7.0へ

Thu, 12 Oct 2017 12:55:16 +0900

最近になってようやくphp5.6の環境からphp7.0へと移行をしました。すでにphp7.2RCも登場している昨今、今さらなんて声聞こえますね。

カスタマイスのプログラムを書いてその管理を長い間していると、プログラムは大きくなるし複雑になるし、簡単にphpの更新ができない、いや馴染んだ古巣から新しい世界へ行くのが恐ろしい！

私の言い訳はともかく、世の中の状況はいかにと調べたところ、こんな統計が出てきました。（参照元）

去年から今年へと、php7の使用率がphp5.6を抜いています。

phpのサポートはどうなのでしょう？phpのサイトによると、

（参照元）

緑は「サポート中」、オレンジは「セキュリティ修正のみ」、赤は「終了」です。

5.6のサポートはセキュリティ修正のみが2018年いっぱい（まだ人気が高い証拠？）とまだ使用OKのようですが、８月にリリースされたLaravelの最新版5.5が長期サポート（LTS）のバージョンでは、バグ修正が２年間、セキュリティ修正が３年とサポートがあり、そしてなんと、

PHP 7.0.0以降が必須

となりました。

私のお客さんのプログラムは、最高でLaravel 5.4どまりですぐに更新する必要ないと言えば必要ないですが、php7.0が発表（上のグラフによるとほぼ２年前！）されてからとても気になるパフォーマンスの改善が「どうしても更新しなければならない」と駆り立てます。

これまた古い資料で申し訳ないですが、

（参照元）

phpで書かれているが非常にスローなWordpressがなんと２倍に近い速さとなるではないですか。

実際、このブログをホストしているサーバーもphp7にしたところサクサク動くようになりました。お客さんのサイトでもapacheのabテストをphp7更新前後でLaravelのプログラムの実行を計測したところ、こちらも1/2の実行時間になりました。バージョンを更新しただけでこの改善は凄い！

さて、php5.6からphp7.0にアップしたときの苦労と言えば、laravelのプログラムに関する限りほとんどゼロに近い変更でした。私の場合は、php7をサポートしていないpearのライブラリを使用した部分の変換が唯一の問題でした。

そして最後に、php7にアップデートしたお陰で、前から注目していて、とても開発に役に立つ、特に大きくて複雑なプログラムには多分必須のツールが使えるようになります。それは次回に紹介しましょう。

PHP on ララジャパン

混乱してはいけないLaravelの動的プロパティ - PHP8.2で廃止となった編

動的プロパティが廃止とはどういうこと？

マジックメソッドを使う

stdClassを使う

Attributeを使う

参照

混乱してはいけないLaravelの動的プロパティ - 裏側編

マジックメソッド

プロパティがなかったらメソッドコール

Laravelでのマジックメソッド

参照

Laravel 11.xのインストール

サポート

新規プロジェクト作成

ファイル構成の変更

withMiddleware()

withExceptions()

withCommands()

ServiceProviderの統合

シンプルになったControllerの基底クラス

once()

Laravel的パーミッションの設定（visibility）

デフォルトの権限

visibilityの設定

filesystems.phpで詳細設定

クエリの累計時間にタイムアウトを設定する（２）

検証用のページ

Tips: 重いクエリをシミュレートする方法

エラーのハンドリング

TimeoutExceptionをキャッチ

クエリ実行中にタイムアウトした場合のエラー

リファクタリング

クエリの累計時間にタイムアウトを設定する（１）

クエリの実行時間を制限する

クエリの累計時間を制限する

DbQueryTimeout.php

コードのポイント

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

PHPBrew

OSのサポート

install

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

バリアント

まとめ

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

Set Lists

Level Sets

一部のruleを無視する

まとめ

参照

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

Rectorとは？

インストール

設定ファイルを追加

実践

まとめ

参照

php8.0 のキャッチアップ - コンストラクタにおける簡略記法

Constructor Property Promotion

php8.0 のキャッチアップ - match式

match式

Laravel9から学ぶ活用方法

フォルダーやサブフォルダ内のすべてのブレードファイル名の取得

resources/viewsのフォルダー

Webmozart Glob

phpのglob関数との違い

phpdotenv

連想配列のマージ

array_merge

+

キーが数字のとき

php5.6からphp7.0へ

PHP 7.0.0以降が必須

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

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