20210110のlaravelに関する記事は21件です。

EC2でartisanが作動しない時にやること

背景

Mac環境でLaravelプロジェクトをAWSのEC2にデプロイしようとしたところ、php artisan key:generatePHP Fatal errarで返ってきてしまいました。
しかし何日かの奮闘の末、解決することが出来たので、同じ悩みを持つ方の手助けに少しでもなればと思いその解決方法を共有させていただきます。

結論:バージョンとcomposer.json

このエラーは
1. composer.jsonの中身がおかしかったこと
2. ローカルのものとEC2上のものでバージョンが違っていたこと
の2点が原因でした。したがってまずcomposer.jsonの中身を書き換えるところから説明していきます。

composer.jsonの中身を書き換える

重要なcomposerのファイルは2種類あります。ここまで来た方なら2つとも既に存在しているファイルです。
composer.json
- composer installを実行する際にはこのjsonファイルの定義を元にパッケージのダウンロードを行う
- composer updateでjsonの定義を元に各バージョンのライブラリををアップデートする。
composer.lock
- composer installでlockに書き出されて各バージョンのライブラリをダウンロードする。

引用 https://qiita.com/a-nishimura/items/8c71085183e0b8a53f6a

したがってcomposer installにおいて、composer.jsonの定義がとても重要になります。しかし私の場合、このjsonファイルが2行しか書かれていませんでした。
確認及び書き換えはvim compose.jsonで行うことが出来ます。内容を確認した後、jsonファイルを以下の内容に書き換えましょう。

{
  "name": "laravel/laravel",
"type": "project",
"description": "The Laravel Framework.",
"keywords": [
    "framework",
    "laravel"
],
"license": "MIT",
"require": {
    "php": "^7.2.5|^8.0",
    "fideloper/proxy": "^4.4",
    "laravel/framework": "^6.20",
    "laravel/tinker": "^2.5"
},
"require-dev": {
    "barryvdh/laravel-debugbar": "^3.3",
    "facade/ignition": "^1.16.4",
    "fakerphp/faker": "^1.9.1",
    "laravel/ui": "^1.2",
    "mockery/mockery": "^1.0",
    "nunomaduro/collision": "^3.0",
    "phpunit/phpunit": "^8.5.8|^9.3.3"
},
"config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "sort-packages": true
},
"extra": {
    "laravel": {
        "dont-discover": []
    }
},
"autoload": {
    "psr-4": {
        "App\\": "app/"
    },
    "classmap": [
        "database/seeds",
        "database/factories"
    ]
},
"autoload-dev": {
    "psr-4": {
        "Tests\\": "tests/"
    }
},
"minimum-stability": "dev",
"prefer-stable": true,
"scripts": {
    "post-autoload-dump": [
        "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
        "@php artisan package:discover --ansi"
    ],
    "post-root-package-install": [
        "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
    ],
    "post-create-project-cmd": [
        "@php artisan key:generate --ansi"
    ]
}

この段階ではまだcomposerのインストールは行いません。
次にバージョン合わせです。

バージョンを合わせる

私の場合、ローカルがPHP7.3、EC2がPHP7.2でした。ということはEC2上でPHPのバージョンを7.2から7.3へと上げなければなりません。以下にそのやり方を記述していきます。
まずPHPのバージョンを確認していきましょう。
php -v
次にバージョンを7.2から7.3へ上げていきます。

sudo amazon-linux-extras disable php7.2
sudo amazon-linux-extras disable lamp-mariadb10.2-php7.2
sudo amazon-linux-extras enable php7.3
sudo yum install php-cli php-pdo php-fpm php-json php-mysqlnd
sudo yum install php-mbstring
sudo yum install php-dom

参考:https://forums.aws.amazon.com/thread.jspa?messageID=908568

composerをインストールする

これで最後です。
composer install

最後に

ここまでお疲れ様でした。最後に、私がこの方法に行き着くまでに試したコマンドを以下に載せようと思います。あとdisableにしているlamp-maraiadb10.2のことを忘れないでくださいね。
composer update
composer update —no-scripts
composer dump-autoload

これらが上手くいかなかったのは、前述の通り大元のcomposer.jsonを書き替えてなかったからだと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2にLaravelプロジェクトをデプロイする際、artisanが実行できない時にやること

背景

Mac環境でLaravelプロジェクトをAWSのEC2にデプロイしようとしたところ、php artisan key:generatePHP Fatal errarで返ってきてしまいました。
しかし何日かの奮闘の末、解決することが出来たので、同じ悩みを持つ方の手助けに少しでもなればと思いその解決方法を共有させていただきます。

結論:バージョンとcomposer.json

このエラーは
1. composer.jsonの中身がおかしかったこと
2. ローカルのものとEC2上のものでバージョンが違っていたこと
の2点が原因でした。したがってまずcomposer.jsonの中身を書き換えるところから説明していきます。

composer.jsonの中身を書き換える

重要なcomposerのファイルは2種類あります。ここまで来た方なら2つとも既に存在しているファイルです。
composer.json
- composer installを実行する際にはこのjsonファイルの定義を元にパッケージのダウンロードを行う
- composer updateでjsonの定義を元に各バージョンのライブラリををアップデートする。
composer.lock
- composer installでlockに書き出されて各バージョンのライブラリをダウンロードする。

引用 https://qiita.com/a-nishimura/items/8c71085183e0b8a53f6a

したがってcomposer installにおいて、composer.jsonの定義がとても重要になります。しかし私の場合、このjsonファイルが2行しか書かれていませんでした。
確認及び書き換えはvim compose.jsonで行うことが出来ます。内容を確認した後、jsonファイルを以下の内容に書き換えましょう。

{
  "name": "laravel/laravel",
"type": "project",
"description": "The Laravel Framework.",
"keywords": [
    "framework",
    "laravel"
],
"license": "MIT",
"require": {
    "php": "^7.2.5|^8.0",
    "fideloper/proxy": "^4.4",
    "laravel/framework": "^6.20",
    "laravel/tinker": "^2.5"
},
"require-dev": {
    "barryvdh/laravel-debugbar": "^3.3",
    "facade/ignition": "^1.16.4",
    "fakerphp/faker": "^1.9.1",
    "laravel/ui": "^1.2",
    "mockery/mockery": "^1.0",
    "nunomaduro/collision": "^3.0",
    "phpunit/phpunit": "^8.5.8|^9.3.3"
},
"config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "sort-packages": true
},
"extra": {
    "laravel": {
        "dont-discover": []
    }
},
"autoload": {
    "psr-4": {
        "App\\": "app/"
    },
    "classmap": [
        "database/seeds",
        "database/factories"
    ]
},
"autoload-dev": {
    "psr-4": {
        "Tests\\": "tests/"
    }
},
"minimum-stability": "dev",
"prefer-stable": true,
"scripts": {
    "post-autoload-dump": [
        "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
        "@php artisan package:discover --ansi"
    ],
    "post-root-package-install": [
        "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
    ],
    "post-create-project-cmd": [
        "@php artisan key:generate --ansi"
    ]
}

この段階ではまだcomposerのインストールは行いません。
次にバージョン合わせです。

バージョンを合わせる

私の場合、ローカルがPHP7.3、EC2がPHP7.2でした。ということはEC2上でPHPのバージョンを7.2から7.3へと上げなければなりません。以下にそのやり方を記述していきます。
まずPHPのバージョンを確認していきましょう。
php -v
次にバージョンを7.2から7.3へ上げていきます。

sudo amazon-linux-extras disable php7.2
sudo amazon-linux-extras disable lamp-mariadb10.2-php7.2
sudo amazon-linux-extras enable php7.3
sudo yum install php-cli php-pdo php-fpm php-json php-mysqlnd
sudo yum install php-mbstring
sudo yum install php-dom

参考:https://forums.aws.amazon.com/thread.jspa?messageID=908568

composerをインストールする

これで最後です。
composer install

最後に

ここまでお疲れ様でした。最後に、私がこの方法に行き着くまでに試したコマンドを以下に載せようと思います。あとdisableにしているlamp-maraiadb10.2のことを忘れないでくださいね。
composer update
composer update —no-scripts
composer dump-autoload

これらが上手くいかなかったのは、前述の通り大元のcomposer.jsonを書き替えてなかったからだと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2にLaravelプロジェクトをデプロイしていく中で、artisanが実行できなくなった時にやること

背景

Mac環境でLaravelプロジェクトをAWSのEC2にデプロイしようとしたところ、php artisan key:generatePHP Fatal errarで返ってきてしまいました。
しかし何日かの奮闘の末、解決することが出来たので、同じ悩みを持つ方の手助けに少しでもなればと思いその解決方法を共有させていただきます。

結論:バージョンとcomposer.json

このエラーは
1. composer.jsonの中身がおかしかったこと
2. ローカルのものとEC2上のものでバージョンが違っていたこと
の2点が原因でした。したがってまずcomposer.jsonの中身を書き換えるところから説明していきます。

composer.jsonの中身を書き換える

重要なcomposerのファイルは2種類あります。ここまで来た方なら2つとも既に存在しているファイルです。
composer.json
- composer installを実行する際にはこのjsonファイルの定義を元にパッケージのダウンロードを行う
- composer updateでjsonの定義を元に各バージョンのライブラリををアップデートする。
composer.lock
- composer installでlockに書き出されて各バージョンのライブラリをダウンロードする。

引用 https://qiita.com/a-nishimura/items/8c71085183e0b8a53f6a

したがってcomposer installにおいて、composer.jsonの定義がとても重要になります。しかし私の場合、このjsonファイルが2行しか書かれていませんでした。
確認及び書き換えはvim compose.jsonで行うことが出来ます。内容を確認した後、jsonファイルを以下の内容に書き換えましょう。

{
  "name": "laravel/laravel",
"type": "project",
"description": "The Laravel Framework.",
"keywords": [
    "framework",
    "laravel"
],
"license": "MIT",
"require": {
    "php": "^7.2.5|^8.0",
    "fideloper/proxy": "^4.4",
    "laravel/framework": "^6.20",
    "laravel/tinker": "^2.5"
},
"require-dev": {
    "barryvdh/laravel-debugbar": "^3.3",
    "facade/ignition": "^1.16.4",
    "fakerphp/faker": "^1.9.1",
    "laravel/ui": "^1.2",
    "mockery/mockery": "^1.0",
    "nunomaduro/collision": "^3.0",
    "phpunit/phpunit": "^8.5.8|^9.3.3"
},
"config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "sort-packages": true
},
"extra": {
    "laravel": {
        "dont-discover": []
    }
},
"autoload": {
    "psr-4": {
        "App\\": "app/"
    },
    "classmap": [
        "database/seeds",
        "database/factories"
    ]
},
"autoload-dev": {
    "psr-4": {
        "Tests\\": "tests/"
    }
},
"minimum-stability": "dev",
"prefer-stable": true,
"scripts": {
    "post-autoload-dump": [
        "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
        "@php artisan package:discover --ansi"
    ],
    "post-root-package-install": [
        "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
    ],
    "post-create-project-cmd": [
        "@php artisan key:generate --ansi"
    ]
}

この段階ではまだcomposerのインストールは行いません。
次にバージョン合わせです。

バージョンを合わせる

私の場合、ローカルがPHP7.3、EC2がPHP7.2でした。ということはEC2上でPHPのバージョンを7.2から7.3へと上げなければなりません。以下にそのやり方を記述していきます。
まずPHPのバージョンを確認していきましょう。
php -v
次にバージョンを7.2から7.3へ上げていきます。

sudo amazon-linux-extras disable php7.2
sudo amazon-linux-extras disable lamp-mariadb10.2-php7.2
sudo amazon-linux-extras enable php7.3
sudo yum install php-cli php-pdo php-fpm php-json php-mysqlnd
sudo yum install php-mbstring
sudo yum install php-dom

参考:https://forums.aws.amazon.com/thread.jspa?messageID=908568

composerをインストールする

これで最後です。
composer install

最後に

ここまでお疲れ様でした。最後に、私がこの方法に行き着くまでに試したコマンドを以下に載せようと思います。あとdisableにしているlamp-maraiadb10.2のことを忘れないでくださいね。
composer update
composer update —no-scripts
composer dump-autoload

これらが上手くいかなかったのは、前述の通り大元のcomposer.jsonを書き替えてなかったからだと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【CentOS 8/Apache 2.4】Laravel 5.5でメール送信をキューイングを用いて速くする【非同期化】

1. 概要

本記事ではCentOSApacheLaravel環境下でのMailファサードによるメール送信において、キューイングを用いることで非同期化させ、処理速度を向上させる方法について紹介します。

まず、キューとは「先入れ先出しの規則でデータを取り扱うデータ構造」を指します。

キューとは、最も基本的なデータ構造の一つで、要素を入ってきた順に一列に並べ、先に入れた要素から順に取り出すという規則で出し入れを行うもの。順番を待つ人の行列と同じ仕組みであるため「待ち行列」とも訳される。

引用元:IT用語辞典 e-Words「キュー(待ち行列)とは

このキューを用いてデータの管理を行うことをキューイングといい、これにより処理を非同期化させることができ、同期的に処理する場合に比べて処理速度が向上します。
キューイングのイメージ.png
上図の左側のように、同期処理では一つの処理が完了するまで次の処理は実行されません。この為、メール送信ような重い処理を挟んだ場合にリソースのムダ及び不要な待ち時間が発生してしまいます。

そこで、上図の右側のように、重い処理を一旦キューに送って後続処理を優先させ、バックグラウンドでキューの処理を行うことで上記の問題を解決できます。

Laravelプロジェクトでのメール送信はMailファサードを用いるのが一般的ですが、Mailファサードには同期的にメール送信するsendメソッドの他に、キューイングするqueueメソッドがデフォルトで用意されています。

しかし、こちらのメソッドはメール送信ジョブをエンキューするのみで、ジョブをバックグラウンドで永続的に処理させるにはプロセスモニタをOSに別途インストールする必要があります。

公式マニュアル(Laravel 5.5)では、プロセスモニタとしてSupervisorが紹介されていますが、載っているコマンドがUbuntuへのインストールの場合のものであるため、本記事ではCentOSへのインストール方法を紹介します。

2. メール送信を非同期化させる手順

2-1. 前提条件

  • CentOS 8
  • Apache 2.4
  • PHP 7.4
  • Laravel 5.5
  • プロジェクトのルートディレクトリ名はlaravelとします
  • プロジェクトのルートディレクトリの絶対パスは/var/www/html/laravelとします

本記事では上記環境であるとの前提で解説します。

参考にされる場合は適宜読み替えて下さい?‍♂️

2-2. キュードライバーの設定

まず、キューイングを行う際のドライバーを指定します。Laravel指定できるキュードライバーには次の6種類があります。

  • sync
    • 同期処理、ローカル用途、デフォルトではこれが指定されている
  • database
    • データベースにキュー用のテーブルを作成してそれを利用する
  • redis
    • Redisを利用する
  • sqs
    • Amazon SQSを利用する
  • beanstalkd
    • Beanstalkdを利用する
  • null
    • キューされたジョブを破棄する

本記事ではライブラリを別途インストールする必要がなく、既存のDBにテーブルを追加するだけで利用できるdatabaseを用います。

.envファイルにてキュードライバーを指定します。

.env
QUEUE_DRIVER=database

念のため1config/queue.phpでも、キュードライバーの指定を変更します。

config/queue.php
    /*
    |--------------------------------------------------------------------------
    | Default Queue Driver
    |--------------------------------------------------------------------------
    |
    | Laravel's queue API supports an assortment of back-ends via a single
    | API, giving you convenient access to each back-end using the same
    | syntax for each one. Here you may set the default queue driver.
    |
    | Supported: "sync", "database", "beanstalkd", "sqs", "redis", "null"
    |
    */

    // envメソッドの第二引数をデフォルトの`sync`から指定したいドライバーに変更
    'default' => env('QUEUE_DRIVER', 'database'),

2-3. キューとなるテーブルの作成

次に、キューとなるテーブルを生成するマイグレーションファイルを作成します。

ターミナル
php artisan queue:table

また、失敗した処理を保存するテーブルを作成するマイグレーションファイルを同時に作成しても良いです。こちらは必須ではありません。

ターミナル
php artisan queue:failed-table

マイグレーションを実行しテーブルを作成します。

ターミナル
php artisan migrate

2-4. メール送信でキューイングを使用する

Mailファサードqueueメソッドを用いるだけです。これだけでメール送信のジョブが上述のマイグレーションで作成されたjobsテーブルに投入されます。

mailableクラス
Mail::to($request->user())
    ->queue(new OrderShipped($order));

❗️queueメソッドの注意点❗️

queueメソッドを用いる場合、Mailableインスタンス(ここではOrderShippedクラスのインスタンス)の引数としてPHPで定義済みのクラスを含むオブジェクト型の多くは渡すことができない2点に注意が必要です。

例えば、ユーザーがフォームに入力した情報をメール内で使用するために、Requestクラスのインスタンスをオブジェクト型として格納した$requestを引数に渡す場合を考えます。

この場合、sendメソッドでは問題なく送信できますが、queueメソッドでは例外Serialization of 'Closure' is not allowedが発生します。

mailableクラス
// 問題なし
Mail::to($request->user())
    ->send(new OrderShipped($request, $order));

// エラー発生
Mail::to($request->user())
    ->queue(new OrderShipped($request, $order));

この問題は、引数をオブジェクト型以外の型として渡すことで回避できます。
メールテンプレートでどの様にユーザーのリクエストボディにアクセスするかによりますが、具体的には次の様な方策が考えられます。

mailableクラス
// 数値型や文字型のプロパティとして渡す
Mail::to($request->user())
    ->queue(new OrderShipped($request->name, $order));

// 配列として渡す
Mail::to($request->user())
    ->queue(new OrderShipped($request->input(), $order));

配列として渡す場合、inputメソッドの他

  • allメソッド
  • exceptメソッド
  • onlyメソッド

も使用することができます。詳しくは下記記事が参考になります。
Qiita「Requestの各メソッド(query(), get(), all()...)の使い分け」 by @piotzkhider さん

また、メールテンプレートで$request->nameのようにアロー演算子を用いてプロパティにアクセスしている場合、こちらも$request['name']のように配列の値を参照するように変更しましょう。

❓オブジェクト型が渡せない理由❓

キューイングの際のシリアル化ができない場合があるためです。

先述したように、Requestインスタンスを渡してqueueメソッドを使用すると、例外Serialization of 'Closure' is not allowedが発生します。直訳すると「『クロージャ』のシリアル化は許可されていません」となります。

シリアル化とは「値の型や構造を保った状態でデータの受け渡しや保存ができる状態にすること」を意味し、今回の場合はjobsテーブルに保存する際に、型や構造の情報が失われないように値のシリアル化が行われているはずです。

参考:侍エンジニア塾ブログ「PHPのシリアライズを知ろう!便利な使い方徹底解説

シリアル化にはPHPの変数操作関数であるserializeが用いられていると推測され、マニュアルには次の様に記載されています。

serialize() は、resource および一部の object 以外のすべての型を処理します。
(中略)
注意:
PHPの組み込みオブジェクトの多くはシリアル化できないことに注意しましょう。

引用元:PHPマニュアル「PHP: serialize - Manual

組み込みオブジェクトとは、PHPに標準で組み込まれているオブジェクトであり、その中にClosureクラスがあります。

参考:PHPマニュアル「PHP: 定義済のクラス - Manual

つまり、エラーメッセージ「Serialization of 'Closure' is not allowed」が示している通り、定義済みのクラスであるClosureRequestオブジェクトに含まれているためにシリアル化が出来ずに例外が発生したと考えられます。

2-5. Supervisorのインストール

CentOS 8へのインストール方法としては次のWebページが参考になります。

参考:CloudWater「Installing Supervisor on CentOS 8

インストールする前にシステムパッケージを最新の状態にアップデート。

ターミナル
sudo dnf update -y

次いで、CentOS標準のリポジトリでは提供されていないパッケージを、yumコマンドでインストール可能にするEPELリポジトリをインストールし、アップデート。

参考:Webセキュリティの小部屋「CentOS に EPEL リポジトリを追加する

ターミナル
sudo dnf install epel-release
sudo yum update

Supervisorをインストールする。

ターミナル
sudo yum -y install supervisor

2-6. ログファイルの作成

キューワーカーをバッググラウンドで実行させた場合のログを記録するファイルを追加します。

ログファイルの配置場所は自由に決められますが、今回はプロジェクトのルートディレクトリ内のlaravel/storage/logs内に配置し、ファイル名はsupervisor.logとします。

下記コマンド実行後に:wqで空ファイルとして保存します。

ターミナル
vi /var/www/html/laravel/storage/logs/supervisor.log

本記事では、バックグラウンドプログラムはapacheが実行するので、ファイルの所有者とパーミッションを変更します。パーミッションは所有者以外が書き込みできないように744とします。

ターミナル
sudo chown apache:apache /var/www/html/laravel/storage/logs/supervisor.log
sudo chmod 744 /var/www/html/laravel/storage/logs/supervisor.log

参考:「パーミッション早見表

2-7. 設定ファイルの編集

Supervisorのインストールにより、設定ファイル/etc/supervisord.confが追加されているはずです。このファイルで追加の設定ファイルを読み込む記述を追記します。

ターミナル
sudo vi /etc/supervisord.conf
/etc/supervisord.conf
# (中略)

[include]
files = supervisord.d/*.ini
# 下記行を追加 
files = supervisord.d/*.conf

さらに、/etc/supervisord.confと同時に/etc/supervisord.dディレクトリも追加されているはずなので、そのディレクトリ内に読み込ませる設定ファイル/etc/supervisord.d/laravel-worker.confを作成します。

ターミナル
sudo vi /etc/supervisord.d/laravel-worker.conf
/etc/supervisord.d/laravel-worker.conf
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/laravel/artisan queue:work --sleep=3 --tries=10
autostart=true
autorestart=true
redirect_stderr=true
numprocs=8
user=apache
stdout_logfile=/var/www/html/laravel/storage/logs/supervisor.log

キューワーカーの実行コマンドはphp artisan queue:workですが、apacheが実行できるように絶対パスで記述します。

今回はオプションとして最大試行回数とスリープ時間を--sleep=3--tries=10として指定しましたが、他にも様々なオプションがあります。

参考:ReadDouble「Laravel 5.5 キュー

また、stdout_logfileには先程作成したログファイルの絶対パスを指定します。

コピペする際には、commandstdout_logfileのパスをそれぞれご自身のプロジェクトでのパスに置き換えて下さい。

他の項目についての詳細については下記をご参照下さい。

参考:Supervisor 4.2.1 documentation「Configuration File

2-8. デーモン化と起動

設定が完了したので、アプリ起動時にプロセスが自動実行されるようにします。

ターミナル
sudo systemctl start supervisord
sudo systemctl enable supervisord

動作確認などで既にスタートしていた場合や、上記のconfファイルを編集した場合は再起動させましょう。

ターミナル
sudo systemctl restart supervisord

プロセスがちゃんと動いているかどうか確認したい場合は以下のコマンドを実行します。

ターミナル
sudo systemctl status supervisord

下記のようにActive: active (running)…と表示され、/etc/supervisord.d/laravel-worker.confcommand項目で設定したコマンドがnumprocs項目で設定した回数分表示されていれば問題ありません(下記では301829301836のプロセス)。

ターミナル
● supervisord.service - Process Monitoring and Control Daemon
   Loaded: loaded (/usr/lib/systemd/system/supervisord.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2021-01-10 xx:xx:xx JST; xs ago
  Process: 301824 ExecStart=/usr/bin/supervisord -c /etc/supervisord.conf (code=exited, status=0/SUCCESS)
 Main PID: 301828 (supervisord)
    Tasks: 9 (limit: 5049)
   Memory: 144.6M
   CGroup: /system.slice/supervisord.service
           ├─301828 /usr/bin/python3.6 /usr/bin/supervisord -c /etc/supervisord.conf
           ├─301829 php /var/www/html/laravel/artisan queue:work --sleep=3 --tries=10
           ├─301830 php /var/www/html/laravel/artisan queue:work --sleep=3 --tries=10
           ├─301831 php /var/www/html/laravel/artisan queue:work --sleep=3 --tries=10
           ├─301832 php /var/www/html/laravel/artisan queue:work --sleep=3 --tries=10
           ├─301833 php /var/www/html/laravel/artisan queue:work --sleep=3 --tries=10
           ├─301834 php /var/www/html/laravel/artisan queue:work --sleep=3 --tries=10
           ├─301835 php /var/www/html/laravel/artisan queue:work --sleep=3 --tries=10
           └─301836 php /var/www/html/laravel/artisan queue:work --sleep=3 --tries=10

 1月 10 xx:xx:xx 160-251-23-222 systemd[1]: Starting Process Monitoring and Control Daemon...
 1月 10 xx:xx:xx 160-251-23-222 systemd[1]: Started Process Monitoring and Control Daemon.

これでキューワーカーをバックグラウンドで実行させることができました?

不備や改善点がございましたら、コメント下さるとありがたいです?‍♂️

3. 参考記事一覧


  1. envメソッドの第二引数はデフォルト値の指定で、第一引数がセットされていない/読み込めない場合に用いられます。指定しなくても通常は問題ありませんが、ここでは予想外の不具合に備えて変更しています。 

  2. 一部渡すことのできる例外はあるようです。しかし、ほとんどのオブジェクト型でエラーが出ると考えられますので、オブジェクト型以外の型を渡しておく方が無難です。 

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Laravel vue.js axios 500 (Internal Server Error) の解決方法

はじめに

この記事では

Laravel vue.js axiosを使って開発しているときに

500 (Internal Server Error)

のエラーに遭遇してどこで処理が止まっているのかを調べるデバック方法をまとめました。

デバック方法

① command + option + I キーで もしくは 右クリックで「検証」ツールを開く

② consoleタブを押し,500 (Internal Server Error) が出ていることを確認する
スクリーンショット 2021-01-10 17.23.10.png

③ Networkタブを押し, 「all」の項目を押すと現在そのページで使われているファイルを確認することができます
スクリーンショット 2021-01-10 17.23.53.png

④ファイル名を選択すると 「message」のところにエラーメッセージが出力されています。
スクリーンショット 2021-01-10 17.24.25.png

今回はidが渡っていなかったので修正したら処理が通るようになりました。

【補足】
【Vue.js】Vuejsをchromeブラウザでデバッグする方法

chromeでVue.js Devtoolsをインストールします。

スクリーンショット 2021-01-10 18.27.41.png

データの受け渡し、処理の流れを確認することができます。

おわりに

エラーが出て分からなくなることがありますが、
どこまで処理が走っているのか
どこで処理が止まっているのか
デバックをすることで、処理の流れを把握することができます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

500 (Internal Server Error) の解決方法 Laravel vue.js axios

はじめに

この記事では

Laravel vue.js axiosを使って開発しているときに

500 (Internal Server Error)

のエラーに遭遇してどこで処理が止まっているのかを調べるデバック方法をまとめました。

デバック方法

① command + option + I キーで もしくは 右クリックで「検証」ツールを開く

② consoleタブを押し,500 (Internal Server Error) が出ていることを確認する
スクリーンショット 2021-01-10 17.23.10.png

③ Networkタブを押し, 「all」の項目を押すと現在そのページで使われているファイルを確認することができます
スクリーンショット 2021-01-10 17.23.53.png

④ ファイル名を選択すると 「message」のところにエラーメッセージが出力されています。
スクリーンショット 2021-01-10 17.24.25.png

今回はidが渡っていなかったので修正したら処理が通るようになりました。

【補足】
【Vue.js】Vuejsをchromeブラウザでデバッグする方法

chromeでVue.js Devtoolsをインストールします。

スクリーンショット 2021-01-10 18.27.41.png

データの受け渡し、処理の流れを確認することができます。

おわりに

エラーが出て分からなくなることがありますが、
どこまで処理が走っているのか
どこで処理が止まっているのか
デバックをすることで、処理の流れを把握することができます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Laravel vue.js axios 500 (Internal Server Error) の解決方法

はじめに

この記事では

Laravel vue.js axiosを使って開発しているときに

500 (Internal Server Error)

のエラーに遭遇してどこで処理が止まっているのかを調べるデバック方法をまとめました。

デバック方法

① command + option + I キーで もしくは 右クリックで「検証」ツールを開く

② consoleタブを押し,500 (Internal Server Error) が出ていることを確認する
スクリーンショット 2021-01-10 17.23.10.png

③ Networkタブを押し, 「all」の項目を押すと現在そのページで使われているファイルを確認することができます
スクリーンショット 2021-01-10 17.23.53.png

④ ファイル名を選択すると 「message」のところにエラーメッセージが出力されています。
スクリーンショット 2021-01-10 17.24.25.png

今回はidが渡っていなかったので修正したら処理が通るようになりました。

【補足】
【Vue.js】Vuejsをchromeブラウザでデバッグする方法

chromeでVue.js Devtoolsをインストールします。

スクリーンショット 2021-01-10 18.27.41.png

データの受け渡し、処理の流れを確認することができます。

おわりに

エラーが出て分からなくなることがありますが、
どこまで処理が走っているのか
どこで処理が止まっているのか
デバックをすることで、処理の流れを把握することができます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Vessel で Laravel のステップ実行が止まらなくなったら Xdebug のバージョンを確認しよう

概要

Vessel の PHP 環境にインストールされる Xdebug のメジャーバージョンアップによって、リモートでバッグ時のステップ実行が止まらなくなった。
ステップ実行をするためには、Vessel の設定を Xdebug 3 に対応した内容に変更する必要がある。

Vessel とは

Vessel は Docker を使った Laravel のアプリケーション開発環境

Vessel - Docker dev environments for Laravel
https://vessel.shippingdocker.com/

Xdebug とは

PHPのデバッグ用拡張モジュール

Xdebug - Debugger and Profiler Tool for PHP
https://xdebug.org/

ステップ実行が止まらなくなった原因

  • Vessel は環境を作る際に PECL で最新版の Xdebug をインストールしている。
  • 2020年11月25日に Xdebug 3 がリリースされた。
  • Xdebug 3 から php.ini で指定するリモートデバッグの設定が変更されたが、Vessel は Xdebug 2 の設定になっている。
  • Xdebug 3 リリース以降にビルドした Vessel の開発環境は、設定を変更しないと Xdebug でリモートデバッグができなくなった。

Xdebug 3 で何が変わったのか

Upgrading from Xdebug 2 to 3
https://xdebug.org/docs/upgrade_guide

以下、ポイントだけまとめると、

1. ステップ実行を有効にする設定が変わった

Xdebug 2 : xdebug.remote_enable = 1
Xdebug 3 : xdebug.mode=debug

2. Xdebugから接続するアドレスの設定項目が変わった

Xdebug 2 : xdebug.remote_host = ホスト名/IPアドレス
Xdebug 3 : xdebug.client_host = ホスト名/IPアドレス

3. Xdebugから接続するポートの設定項目とポート番号が変わった

Xdebug 2 : xdebug.remote_port = 9000
Xdebug 3 : xdebug.client_port = 9003

Xdebug 3 の設定コンセプト

機能ごとに設定で有効化していた Xdebug 2 に対して、Xdebug 3 では「モード」を指定することで目的の状態に設定するという考え方だそう。このモードを設定するのが xdebug.mode ということ。

あと、remote_* という設定項目が client_* になった。
Xdebug 2 の時は、手元の開発環境は Xdebug から見た「リモート」という意味だったのに対して、
Xdebug 3 は Xdebug が「サーバ」で動作していて開発しているローカル環境が「クライアント」という意味なのだろう。
直感的で分かりやすくなったと思うが、互換性が...

Vessel の設定を Xdebug 3 に対応させる手順

Vessel の開発環境を作成

まずは通常通りの手順で Vessel の開発環境を作成する。

↓公式サイトの手順はこちら

Getting Started
https://vessel.shippingdocker.com/docs/get-started/

開発環境が作成できたらアプケーションが正しく動作することを確認しておく。

Xdebug の設定を変更する

設定を変更するファイル

docker/app/xdebug.ini

% tree
.
├── LICENSE
├── README.md
├── app
├── artisan
├── bootstrap
├── composer.json
├── composer.lock
├── config
├── database
├── docker
│   ├── app
│   │   ├── Dockerfile
│   │   ├── default
│   │   ├── h5bp
│   │   ├── start-container
│   │   ├── supervisord.conf
│   │   ├── vessel.ini
│   │   └── xdebug.ini          ← このファイルを編集する
│   ├── mysql
│   │   ├── conf.d
│   │   └── logs
│   └── node
│       └── Dockerfile
├── docker-compose.yml
├── package.json
├── phpunit.xml
├── public
├── resources
├── routes
├── server.php
├── storage
├── tests
├── vendor
├── vessel
└── webpack.mix.js

Xdebug 3 の設定内容

zend_extension=xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_port=9000
xdebug.remote_autostart=1
xdebug.remote_connect_back=0
xdebug.idekey=docker
xdebug.remote_host=192.168.1.2
xdebug.max_nesting_level = 500
; ↑ XDebug 2 の設定

; XDebug 3 の設定 ※ここを追加する
xdebug.mode = debug
xdebug.client_host = host.docker.internal ← コンテナから見たホストのIPアドレス
; xdebug.client_port = 9000 ← XDebug 2 と同じポート 9000 に接続する場合はここで指定

host.docker.internal はコンテナから見たホストのIPアドレスを自動解決する設定
https://docs.docker.jp/docker-for-mac/networking.html

変更した設定を反映する

xdebug.ini の設定を反映させるためにはコンテナをビルドして再起動する。

./vessel stop
./vessel build
./vessel start

IDE で必要な設定を行う

Xdebug 3 が接続してくるポートが 9000 から 9003 に変更になったので、IDE 側で待ち受けるポート番号も 9003 に変えておく。

または、xdebug.ini で Xdebug 3 の接続ポートを 9000 に変えてもよい。

PhpStorp

Configure Xdebug - PhpStorm
https://www.jetbrains.com/help/phpstorm/configuring-xdebug.html

Visual Studio

デバッグ構成ファイルの設定例
https://github.com/aibax/vessel-xdebug3-sample/blob/main/.vscode/launch.json

参考

この件についてサンプルコードを書きました
https://github.com/aibax/vessel-xdebug3-sample

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Laravel 認証機能を作成

使用環境

・Laravel7
・MAMP
・Mac OS Catalina

認証機能の作成手順(ターミナル操作)

composer require laravel/ui 2.0

※LaravelのバージョンによってLaravel/uiのバージョンも変化する。Laravel7系であれば、2.0になる。

php artisan ui vue --auth

この二つのコマンドを打つと、laravelプロジェクト内の、
app/Http/Controllersの配下にAuthというフォルダが作成される。

そして、Laravelのメインページにも、認証の機能が追加されていることが分かる。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

VPC内にElasticsearchを配置する際の注意点

VPC内のプライベートサブネットにElasticsearchを置いたはいいけど、LambdaからAPI叩けないしKibanaにもアクセスできなくて困ったときのメモです。

解決策

  • BastionServerとして同VPC内にEC2(パブリックサブネット)を置く
    • EC2にSSH接続してダイナミックフォワードを行う(ダイナミックフォワードあまりわかっていない...)
  • Lambdaを同じVPC内に置く
    • 仕様によってプライベートかパブリックかを選択する
  • それぞれのリソースに適切なセキュリティグループ(後述)を設定する

セキュリティグループ設定

EC2

  • アクセス元IPアドレス(ローカルマシン)から22ポートへのトラフィック許可

  • アクセス元IPアドレス(ローカルマシン)から8157ポートへのトラフィック許可

Lambda

  • 今回は特に設定は不要(仕様による)

Elasticsearch

  • Lambdaにアタッチしたセキュリティグループから443ポートへのトラフィック許可

  • EC2のプライベートIPアドレスから443ポートへのトラフィック許可

ハマりポイント

ElasticsearchのアクセスコントロールでEC2のプライベートIPを許可しようとしたが以下のエラーが出ました。

UpdateElasticsearchDomainConfig: {"message":"You can’t attach an IP-based policy to a domain that has a VPC endpoint. Instead, use a security group to control IP-based access."}

解決策が見つからず2時間くらいはまりましたが、ちゃんと公式に書いてありました。

VPCs ではセキュリティグループを通じてドメインへのアクセスを管理できます。多くのユースケースでは、このセキュリティ機能の組み合わせで十分となり、ドメインにオープンなアクセスポリシーを安心して適用できます。

Amazon Elasticsearch Service ドメインの VPC サポート - Amazon Elasticsearch Service

どうやらセキュリティグループでの制限で十分のようです。

つまりVPC内にElasticsearchを置くケースだとオープンアクセスを選択しておいて、アタッチしているセキュリティグループのみでアクセスの制限を行う形になります。

 

参考

https://github.com/awsdocs/amazon-elasticsearch-service-developer-guide/commit/a033da866dff1251a42aa1637b89e7ebcc5fc779#diff-861cbf8ba5a0dc5589e8ef3d5cf74a1e:embed:cite

https://aws.amazon.com/jp/premiumsupport/knowledge-center/kibana-outside-vpc-ssh-elasticsearch/:embed:cite

https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-kibana.html#es-kibana-access:embed:cite

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

PHP/Laravel アプリ開発時に知っていると便利かもしれないTips

はじめに

Laravelアプリ開発時に知っていると便利かもしれないTipsをまとめてみます。
初投稿のため不慣れな点が多々あります。ご容赦の程よろしくお願いいたします。
また、PHPは門外漢のため、慣例を無視したものや不自然な記述等あるかもしれません。
その点もご留意ください。

Laravelのバージョンは6.2にて確認を行っています。
バージョンの差異によって動作に差異がある場合があります。

指摘や情報展開等、ご自由にコメントいただけると幸いです。

Laravelのcsrfトークンを用いて多重submitを抑止する

LaravelのsessionオブジェクトはStartSession.phpにて以下の仕様となっている。

  • requestを受け取ったのち、処理の最初の方でsessionストレージから情報を取得し、
    Store.phpインスタンスとして状態を保持する。
  • responseの直前でStore.phpインスタンスの状態をsessionストレージに保存する。

sessionの状態が保存される前に受け取った複数のリクエスト間にて、session情報は最新の状態で同期されない。そのため、submitボタンの連打等によって多重送信を受け取った際、最初のリクエストにてsessionオブジェクトのcsrfトークンの値を変更したとしても、2つ目以降のリクエストが取得したsessionオブジェクトには反映されておらず、そのままの状態では多重送信の抑止が行えない。
csrfトークンを用いて多重サブミットを抑止したい場合、抑止したい処理にて明示的に最新のsession情報を取得し、クライアントのパラメータの値と比較した後、問題がなければ新たなトークンを生成してsessionを保存するといった処理を行う必要がある。

Trait等に以下のような関数を定義する。

Trait.php
private function multiSubmitCheck(Request $request)
{
    // Sessionオブジェクト(Store.php)
    $session = $request->session();
    // Sessionオブジェクトを最新化
    $session->start();
    // csrfトークンと画面パラメータのcsrfトークンの値が異なる場合エラー
    if ($session->token() != $request->input('_token')) {
        return false;
    }
    // csrfトークンの再生成 
    // Store #regenerate によるセッションID再生成でもトークンの再生成が行われる
    $session->regenerateToken();
    // Sessionを保存
    $session->save();

    return true;
}

そして多重サブミットを防ぎたい処理にて上記関数を呼び出し、
戻り値にfalseを返すようであればabortヘルパでエラーを返すなりしてやればよい。

Controller.php
public function update(Request $request)
{
    // 多重サブミットチェック
    if (!this->multiSubmitCheck($request)) abort(409);
    ...
}

加えて、一般的なクライアントサイドにおける多重submit抑止の処理も、不要リクエストの抑制、意図せぬエラー発生の防止等期待できるため、可能な限り行うべきだと思われる。

app.js
const triggers = $('a,button')
$('form').on('submit', function () {
    triggers.css('pointer-events', 'none')
})

デフォルトのペジネーション機能をpostによるsubmitに変更

bladeにてページネーション結果の表示を行う際、各ページのボタンはリンクとして生成され、ページボタンを押下するとgetによる画面遷移が行われる。様々な理由により、検索処理はpostによるリクエストに紐づけて作成しており、ページネーション機能もpostによるsubmitの方が都合がよいといった場面があると思われる。
Eloquent queryのpaginateメソッドは、requestのパラメータ内にpageというキーが含まれてさえいればgetだろうとpostだろうと問題なく動作するようなので、ページネーションボタン押下時の処理にカスタマイズを入れる。

まず、JavaScriptにてページボタン押下時の処理を定義する。

app.js
function pagination(page) {
    const form = $(event.target).closest('form')
    const action = `${form.attr('action')}?page=${page}`
    form.attr('action', action).submit()
}

後はページボタン押下時に上記関数を呼び出すだけ。
公式のドキュメントを参考にページネーションビューを出力し、
bootstrap-4.blade.phpファイルに対して以下のカスタマイズを行う。

bootstrap-4.blade.php
{{-- 11行目を以下に書き換え --}}
<a class="page-link" rel="prev" aria-lavel="@lang('pagination.previous')" onclick="pagination({{ $paginator->currentPage() - 1 }});">&lsaquo;</a>

{{-- 29行目を以下に書き換え --}}
<a class="page-link" onclick="pagination({{ $page }});">{{ $page }}</a>

{{-- 39行目を以下に書き換え --}}
<a class="page-link" rel="next" aria-lavel="@lang('pagination.next')" onclick="pagination({{ $paginator->currentPage() + 1 }});">&rsaquo;</a>

このカスタマイズはページボタンの直近の祖先(親)要素のformに対して、クエリストリングでpageパラメータを付与した後にsubmitしているだけとなる。状況に応じて適宜内容変更することで、様々なケースに対応できると思われる。

404発生時に認証ディレクティブが正常に動作しない問題への対策

404発生時、bladeにて@auth@guestといった認証ディレクティブが、
認証状態にかかわらず@guestの分岐となる場合がある。
レイアウトのbladeにてログイン状態に応じてログイン/ログアウトのボタンの出し分けを行っている場合等、少々不都合があるため対策を講じる必要がある。

内部実装を詳細に追ったわけではないので正確な情報は不明だが、認証ディレクティブを正常に動作させるためには、ルート定義ファイルにリクエストを経由させることが必要なようである。
そのため、未定義ルートでも一度web.phpにて拾ってやり、そのうえで404を返してやることで認証ディレクティブが正常に動作した。

web.php
// リクエストが他ルートに一致しない場合
Route::fallback(function () {
    abort(404);
});

情報求む

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

PHP/Laravelアプリ開発時に知っていると便利かもしれないTips

はじめに

Laravelアプリ開発時に知っていると便利かもしれないTipsをまとめてみます。
初投稿のため不慣れな点が多々あります。ご容赦の程よろしくお願いいたします。
また、PHPは門外漢のため、慣例を無視したものや不自然な記述等あるかもしれません。
その点もご留意ください。

Laravelのバージョンは6.2にて確認を行っています。
バージョンの差異によって動作に差異がある場合があります。

指摘や情報展開等、ご自由にコメントいただけると幸いです。

Laravelのcsrfトークンを用いて多重submitを抑止する

LaravelのsessionオブジェクトはStartSession.phpにて以下の仕様となっている。

  • requestを受け取ったのち、処理の最初の方でsessionストレージから情報を取得し、
    Store.phpインスタンスとして状態を保持する。
  • responseの直前でStore.phpインスタンスの状態をsessionストレージに保存する。

sessionの状態が保存される前に受け取った複数のリクエスト間にて、session情報は最新の状態で同期されない。
そのため、submitボタンの連打等によって多重送信を受け取った際、最初のリクエストにてsessionオブジェクトのcsrfトークンの値を変更したとしても、2つ目以降のリクエストが取得したsessionオブジェクトには反映されておらず、そのままの状態では多重送信の抑止が行えない。
csrfトークンを用いて多重サブミットを抑止したい場合、抑止したい処理にて明示的に最新のsession情報を取得し、クライアントのパラメータの値と比較した後、問題がなければ新たなトークンを生成してsessionを保存するといった処理を行う必要がある。

Trait等に以下のような関数を定義する。

Trait.php
private function multiSubmitCheck(Request $request)
{
    // Sessionオブジェクト(Store.php)
    $session = $request->session();
    // Sessionオブジェクトを最新化
    $session->start();
    // csrfトークンと画面パラメータのcsrfトークンの値が異なる場合エラー
    if ($session->token() != $request->input('_token')) {
        return false;
    }
    // csrfトークンの再生成 
    // Store #regenerate によるセッションID再生成でもトークンの再生成が行われる
    $session->regenerateToken();
    // Sessionを保存
    $session->save();

    return true;
}

そして多重サブミットを防ぎたい処理にて上記関数を呼び出し、
戻り値にfalseを返すようであればabortヘルパでエラーを返すなりしてやればよい。

Controller.php
public function update(Request $request)
{
    // 多重サブミットチェック
    if (!this->multiSubmitCheck($request)) abort(409);
    ...
}

加えて、一般的なクライアントサイドにおける多重submit抑止の処理も、不要リクエストの抑制、意図せぬエラー発生の防止等期待できるため、可能な限り行うべきだと思われる。

app.js
const triggers = $('a,button')
$('form').on('submit', function () {
    triggers.css('pointer-events', 'none')
})

デフォルトのペジネーション機能をpostによるsubmitに変更

bladeにてページネーション結果の表示を行う際、各ページのボタンはリンクとして生成され、ページボタンを押下するとgetによる画面遷移が行われる。様々な理由により、検索処理はpostによるリクエストに紐づけて作成しており、ページネーション機能もpostによるsubmitの方が都合がよいといった場面があると思われる。
Eloquent queryのpaginateメソッドは、requestのパラメータ内にpageというキーが含まれてさえいればgetだろうとpostだろうと問題なく動作するようなので、ページネーションボタン押下時の処理にカスタマイズを入れる。

まず、JavaScriptにてページボタン押下時の処理を定義する。

app.js
function pagination(page) {
    const form = $(event.target).closest('form')
    const action = `${form.attr('action')}?page=${page}`
    form.attr('action', action).submit()
}

後はページボタン押下時に上記関数を呼び出すだけ。
公式のドキュメントを参考にページネーションビューを出力し、
bootstrap-4.blade.phpファイルに対して以下のカスタマイズを行う。

bootstrap-4.blade.php
{{-- 11行目を以下に書き換え --}}
<a class="page-link" rel="prev" aria-lavel="@lang('pagination.previous')" onclick="pagination({{ $paginator->currentPage() - 1 }});">&lsaquo;</a>

{{-- 29行目を以下に書き換え --}}
<a class="page-link" onclick="pagination({{ $page }});">{{ $page }}</a>

{{-- 39行目を以下に書き換え --}}
<a class="page-link" rel="next" aria-lavel="@lang('pagination.next')" onclick="pagination({{ $paginator->currentPage() + 1 }});">&rsaquo;</a>

このカスタマイズはページボタンの直近の祖先(親)要素のformに対して、クエリストリングでpageパラメータを付与した後にsubmitしているだけとなる。状況に応じて適宜内容変更することで、様々なケースに対応できると思われる。

404発生時に認証ディレクティブが正常に動作しない問題への対策

404発生時、bladeにて@auth@guestといった認証ディレクティブが、認証状態にかかわらず@guestの分岐となる場合がある。レイアウトのbladeにてログイン状態に応じてログイン/ログアウトのボタンの出し分けを行っている場合等、少々不都合があるため対策を講じる必要がある。

内部実装を詳細に追ったわけではないので正確な情報は不明だが、認証ディレクティブを正常に動作させるためには、ルート定義ファイルにリクエストを経由させることが必要なようである。
そのため、未定義ルートでも一度web.phpにて拾ってやり、そのうえで404を返してやることで認証ディレクティブが正常に動作した。

web.php
// リクエストが他ルートに一致しない場合
Route::fallback(function () {
    abort(404);
});

情報求む

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Laravel】Homestead + Laravel MixでBrowserSyncする

公式ドキュメントの情報が薄くて役に立たないため、他の方の記事を参考にした。
しかしうまくいかなかったため、試行錯誤してうまくいった結果だけ残しておく。

環境

  • MacBook Pro
  • Vagrant 2.2.10
  • Laravel Homestead 9.5.1
  • Laravel Framework 6.20.7
  • npm 6.14.4

設定

watchOptionsとか要らない。

/webpack.mix.js
...
mix.browserSync({
    host: 'hoge.test', // proxy.targetと合わせる
    proxy: {
        target: 'http://hoge.test', // /etc/hostsで設定しているドメインのURL
    },
    files: [ // 変更検知してほしいファイルを列挙する
        './resources/**/*',
        './public/**/*',
    ]
});

起動

watchだと変更検知されないためwatch-pollする。

$ npm run watch-poll

...
[Browsersync] Proxying: http://hoge.test
[Browsersync] Access URLs:
 ----------------------------------
       Local: http://localhost:3000
    External: http://hoge.test:3000 # ブラウザでこれを開く
 ----------------------------------
          UI: http://localhost:3001
 UI External: http://localhost:3001
 ----------------------------------
[Browsersync] Watching files...

参考

https://www.browsersync.io/docs/options

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Laravel】Homestead + Laravel Mix + ReactでBrowsersyncする

公式ドキュメントの情報が薄くて役に立たないため、他の方の記事を参考にした。
しかしうまくいかなかったため、試行錯誤してうまくいった結果だけ残しておく。

環境

  • MacBook Pro
  • Vagrant 2.2.10
  • Laravel Homestead 9.5.1
  • Laravel Framework 6.20.7
  • Laravel Mix 5.0.9
  • React 16.14.0

設定

watchOptionsとか要らない。

/webpack.mix.js
...
mix.browserSync({
    host: 'hoge.test', // proxy.targetと合わせる
    proxy: {
        target: 'http://hoge.test', // /etc/hostsで設定しているドメインのURL
    },
    files: [ // 変更検知してほしいファイルを列挙する
        './resources/**/*',
        './public/**/*',
    ]
});

起動

watchだと変更検知されないためwatch-pollする。

$ npm run watch-poll

...
[Browsersync] Proxying: http://hoge.test
[Browsersync] Access URLs:
 ----------------------------------
       Local: http://localhost:3000
    External: http://hoge.test:3000 # ブラウザでこれを開く
 ----------------------------------
          UI: http://localhost:3001
 UI External: http://localhost:3001
 ----------------------------------
[Browsersync] Watching files...

画面右上にBrowsersync: connectedと出るため、ファイルを変更してホットリロードされればOK。

参考

https://www.browsersync.io/docs/options

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

オブジェクトとは

関連する変数(値)と関数(動作)をまとめて、そのまとまりに名前を付けたものです。これまで、変数と関数は別々に宣言され管理されてきましたが、関連する変数や関数は1つのオブジェクト内で宣言してまとめてしまうことで、管理しやすくするのがオブジェクト指向。

ブジェクト(object)は、日本語に訳すと、物体。

クラスに含める変数のことは プロパティ 、クラスに含める関数のことは メソッド とも言います。

オブジェクト指向プログラミングとは、積極的にオブジェクトという概念を導入したプログラミング手法ということ。オブジェクト指向プログラミングができるプログラミング言語をオブジェクト指向プログラミング言語。

多くのプログラミング言語がオブジェクト指向を採用。PHP をはじめ、 Java, Ruby, C++, C#, Swift といったプログラミング言語は全てオブジェクト指向プログラミング言語。更に言うと、クラスベースのオブジェクト指向プログラミング言語。

クラスベースのオブジェクト指向では、オブジェクトには クラス と インスタンス という2つの側面があります。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

論理演算子

&&  条件A && 条件B 条件Aと条件Bがどちらもtrueならばtrueを返す
||   条件A || 条件B 条件Aと条件Bのどちらかがtrueならばtrueを返す
!   !条件A 条件Aがfalseならtrueを返す

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

比較演算子

== 右辺と左辺が等しい場合にはtrueを返す。等しくない場合にはfalseを返す。

!= 右辺と左辺が等しくない場合にはtrueを返す。等しい場合にはfalseを返す。

< 右辺より左辺が小さい場合にはtrueを返す。右辺より左辺が大きいか等しい場合にはfalseを返す。

> 右辺より左辺が大きい場合にはtrueを返す。右辺より左辺が小さいか等しい場合にはfalseを返す。

<= 右辺より左辺が小さいか等しい場合にはtrueを返す。

>= 右辺より左辺が大きいか等しい場合にはtrueを返す。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

バリデーション

バリデーション 【 validation 】

バリデーションとは、検証、実証、認可、妥当性確認などの意味を持つ英単語。ITの分野では、対象がその仕様や文法などに照らして適切に記述・構築されているか否かを検証するという意味で用いられることが多い。

プログラムのバリデーションといった場合、記述に用いた言語の文法や、そのプログラムに要求される仕様(書の記述)に則って正しく記述されているかを検証することを表す。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Laravel Collective

Laravel のFormファサードを使うと、HTML のフォームタグがすっきり。

Composer で「Laravel Collective」パッケージをインストール。
$ composer require "laravelcollective/html":"6.*"

Formファサードの引数
第一引数:name属性の値
第二引数:value属性の値
第三引数:「class」「placeholder」など追加の属性

HTML
input type="text" class="form-control" id="lastName" placeholder="名字">

Formファサード
{{Form::text('lastName', null, ['class' => 'form-control', 'id' => 'lastName', 'placeholder' => '名字'])}}

HTML
form method="POST" action="http://localhost" accept-charset="UTF-8" enctype="multipart/form-data">

Formファサード
{{Form::open(['url' => '/', 'files' => true])}}

HTML
/form>
Formファサード
{{Form::close()}}

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CRUD

CRUDとは、データベース管理システム(DBRS)に必要とされる4つの主要な機能、「作成(Create)」「読み出し(Read)」「更新(Update)」「削除(Delete)」をそれぞれ頭文字で表したもののことである。

例えばSQLにおいては、「作成」に「INSERT」のコマンドが、「読み出し」に「SELECT」、「更新」に「UPDATE」、「削除」には「DELETE」のコマンドがそれぞれ対応している。CRUDのそれぞれの機能を網羅していることは、データベースシステムの完全性を備えるために必須の要素であるとされている。

フルスペル:Create, Read, Update, Delete
読み方:クラッド

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

マイグレーションとは

マイグレーション機能では、テーブルを新規に作成するためのマイグレーションファイルと呼ばれるファイルを作成して、マイグレーションを実行することで、マイグレーションファイルに書かれたテーブルの定義がMySQLなどのデータベースに間接的に反映される。

例えば、既存のテーブルに、後からカラムを追加したい場合には、カラムを追加するための別のマイグレーションファイルを新たに作成して実行することで、テーブルの定義を変更していく。

マイグレーション機能を使って、テーブル定義を修正すれば、履歴がマイグレーションファイルという形で残っていく。テーブル定義に変更や追加がある度に、新しくマイグレーションファイルを追加作成する。

マイグレーションファイルをある地点まで戻すことを ロールバックという。

$ php artisan make:migration create_???_table --create=???

$ php artisan migrate

$php artisan make:model Message

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む