- 投稿日:2021-01-10T21:40:57+09:00
EC2でartisanが作動しない時にやること
背景
Mac環境でLaravelプロジェクトをAWSのEC2にデプロイしようとしたところ、
php artisan key:generate
がPHP 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に書き出されて各バージョンのライブラリをダウンロードする。したがって
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を書き替えてなかったからだと思います。
- 投稿日:2021-01-10T21:40:57+09:00
EC2にLaravelプロジェクトをデプロイする際、artisanが実行できない時にやること
背景
Mac環境でLaravelプロジェクトをAWSのEC2にデプロイしようとしたところ、
php artisan key:generate
がPHP 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に書き出されて各バージョンのライブラリをダウンロードする。したがって
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を書き替えてなかったからだと思います。
- 投稿日:2021-01-10T21:40:57+09:00
EC2にLaravelプロジェクトをデプロイしていく中で、artisanが実行できなくなった時にやること
背景
Mac環境でLaravelプロジェクトをAWSのEC2にデプロイしようとしたところ、
php artisan key:generate
がPHP 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に書き出されて各バージョンのライブラリをダウンロードする。したがって
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を書き替えてなかったからだと思います。
- 投稿日:2021-01-10T18:46:35+09:00
【CentOS 8/Apache 2.4】Laravel 5.5でメール送信をキューイングを用いて速くする【非同期化】
1. 概要
本記事では
CentOS
・Apache
・Laravel
環境下でのMailファサード
によるメール送信において、キューイングを用いることで非同期化させ、処理速度を向上させる方法について紹介します。まず、キューとは「先入れ先出しの規則でデータを取り扱うデータ構造」を指します。
キューとは、最も基本的なデータ構造の一つで、要素を入ってきた順に一列に並べ、先に入れた要素から順に取り出すという規則で出し入れを行うもの。順番を待つ人の行列と同じ仕組みであるため「待ち行列」とも訳される。
引用元:IT用語辞典 e-Words「キュー(待ち行列)とは」
このキューを用いてデータの管理を行うことをキューイングといい、これにより処理を非同期化させることができ、同期的に処理する場合に比べて処理速度が向上します。
上図の左側のように、同期処理では一つの処理が完了するまで次の処理は実行されません。この為、メール送信ような重い処理を挟んだ場合にリソースのムダ及び不要な待ち時間が発生してしまいます。そこで、上図の右側のように、重い処理を一旦キューに送って後続処理を優先させ、バックグラウンドでキューの処理を行うことで上記の問題を解決できます。
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
ファイルにてキュードライバーを指定します。.envQUEUE_DRIVER=database念のため1
config/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
」が示している通り、定義済みのクラスであるClosure
がRequestオブジェクト
に含まれているためにシリアル化が出来ずに例外が発生したと考えられます。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
には先程作成したログファイルの絶対パスを指定します。コピペする際には、
command
やstdout_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.conf
のcommand
項目で設定したコマンドがnumprocs
項目で設定した回数分表示されていれば問題ありません(下記では301829
〜301836
のプロセス)。ターミナル● 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. 参考記事一覧
- IT用語辞典 e-Words「キュー(待ち行列)とは」
- Laravel Documentation「Queues」
- ReadDouble「キュー 5.5 Laravel」
- ReadDouble「メール 5.5 Laravel」
- Qiita「LaravelでMailableなオブジェクトをqueueで送信したら"Serialization of 'Closure' is not allowed"というエラーになった件の解決方法」 by @pinekta さん
- Qiita「Requestの各メソッド(query(), get(), all()...)の使い分け」 by @piotzkhider さん
- 侍エンジニア塾ブログ「PHPのシリアライズを知ろう!便利な使い方徹底解説」
- PHPマニュアル「PHP: serialize - Manual」
- PHPマニュアル「PHP: 定義済のクラス - Manual」
- CloudWater「Installing Supervisor on CentOS 8」
- Webセキュリティの小部屋「CentOS に EPEL リポジトリを追加する」
- 「パーミッション早見表」
- Supervisor 4.2.1 documentation「Configuration File」
- 366Service「Laravelキューを永久に実行するためにcentos 7にsupervisordをインストールして設定する」
- 思考の葉「Laravel Queueを利用して非同期によるメール送信」
- 投稿日:2021-01-10T18:39:17+09:00
Laravel vue.js axios 500 (Internal Server Error) の解決方法
はじめに
この記事では
Laravel vue.js axiosを使って開発しているときに
500 (Internal Server Error)
のエラーに遭遇してどこで処理が止まっているのかを調べるデバック方法をまとめました。
デバック方法
① command + option + I キーで もしくは 右クリックで「検証」ツールを開く
② consoleタブを押し,500 (Internal Server Error) が出ていることを確認する
③ Networkタブを押し, 「all」の項目を押すと現在そのページで使われているファイルを確認することができます
④ファイル名を選択すると 「message」のところにエラーメッセージが出力されています。
今回はidが渡っていなかったので修正したら処理が通るようになりました。
【補足】
【Vue.js】Vuejsをchromeブラウザでデバッグする方法chromeでVue.js Devtoolsをインストールします。
データの受け渡し、処理の流れを確認することができます。
おわりに
エラーが出て分からなくなることがありますが、
どこまで処理が走っているのか
どこで処理が止まっているのか
デバックをすることで、処理の流れを把握することができます。
- 投稿日:2021-01-10T18:39:17+09:00
500 (Internal Server Error) の解決方法 Laravel vue.js axios
はじめに
この記事では
Laravel vue.js axiosを使って開発しているときに
500 (Internal Server Error)
のエラーに遭遇してどこで処理が止まっているのかを調べるデバック方法をまとめました。
デバック方法
① command + option + I キーで もしくは 右クリックで「検証」ツールを開く
② consoleタブを押し,500 (Internal Server Error) が出ていることを確認する
③ Networkタブを押し, 「all」の項目を押すと現在そのページで使われているファイルを確認することができます
④ ファイル名を選択すると 「message」のところにエラーメッセージが出力されています。
今回はidが渡っていなかったので修正したら処理が通るようになりました。
【補足】
【Vue.js】Vuejsをchromeブラウザでデバッグする方法chromeでVue.js Devtoolsをインストールします。
データの受け渡し、処理の流れを確認することができます。
おわりに
エラーが出て分からなくなることがありますが、
どこまで処理が走っているのか
どこで処理が止まっているのか
デバックをすることで、処理の流れを把握することができます。
- 投稿日:2021-01-10T18:39:17+09:00
Laravel vue.js axios 500 (Internal Server Error) の解決方法
はじめに
この記事では
Laravel vue.js axiosを使って開発しているときに
500 (Internal Server Error)
のエラーに遭遇してどこで処理が止まっているのかを調べるデバック方法をまとめました。
デバック方法
① command + option + I キーで もしくは 右クリックで「検証」ツールを開く
② consoleタブを押し,500 (Internal Server Error) が出ていることを確認する
③ Networkタブを押し, 「all」の項目を押すと現在そのページで使われているファイルを確認することができます
④ ファイル名を選択すると 「message」のところにエラーメッセージが出力されています。
今回はidが渡っていなかったので修正したら処理が通るようになりました。
【補足】
【Vue.js】Vuejsをchromeブラウザでデバッグする方法chromeでVue.js Devtoolsをインストールします。
データの受け渡し、処理の流れを確認することができます。
おわりに
エラーが出て分からなくなることがありますが、
どこまで処理が走っているのか
どこで処理が止まっているのか
デバックをすることで、処理の流れを把握することができます。
- 投稿日:2021-01-10T16:21:21+09:00
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.jsXdebug 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 startIDE で必要な設定を行う
Xdebug 3 が接続してくるポートが
9000
から9003
に変更になったので、IDE 側で待ち受けるポート番号も9003
に変えておく。または、
xdebug.ini
で Xdebug 3 の接続ポートを9000
に変えてもよい。PhpStorp
Configure Xdebug - PhpStorm
https://www.jetbrains.com/help/phpstorm/configuring-xdebug.htmlVisual Studio
デバッグ構成ファイルの設定例
https://github.com/aibax/vessel-xdebug3-sample/blob/main/.vscode/launch.json参考
この件についてサンプルコードを書きました
https://github.com/aibax/vessel-xdebug3-sample
- 投稿日:2021-01-10T15:09:08+09:00
Laravel 認証機能を作成
- 投稿日:2021-01-10T12:11:19+09:00
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を置くケースだとオープンアクセスを選択しておいて、アタッチしているセキュリティグループのみでアクセスの制限を行う形になります。
参考
- 投稿日:2021-01-10T09:06:44+09:00
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.phpprivate 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.phppublic function update(Request $request) { // 多重サブミットチェック if (!this->multiSubmitCheck($request)) abort(409); ... }加えて、一般的なクライアントサイドにおける多重submit抑止の処理も、不要リクエストの抑制、意図せぬエラー発生の防止等期待できるため、可能な限り行うべきだと思われる。
app.jsconst 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.jsfunction 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 }});">‹</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 }});">›</a>このカスタマイズはページボタンの直近の祖先(親)要素のformに対して、クエリストリングでpageパラメータを付与した後にsubmitしているだけとなる。状況に応じて適宜内容変更することで、様々なケースに対応できると思われる。
404発生時に認証ディレクティブが正常に動作しない問題への対策
404発生時、bladeにて@authや@guestといった認証ディレクティブが、
認証状態にかかわらず@guestの分岐となる場合がある。
レイアウトのbladeにてログイン状態に応じてログイン/ログアウトのボタンの出し分けを行っている場合等、少々不都合があるため対策を講じる必要がある。内部実装を詳細に追ったわけではないので正確な情報は不明だが、認証ディレクティブを正常に動作させるためには、ルート定義ファイルにリクエストを経由させることが必要なようである。
そのため、未定義ルートでも一度web.php
にて拾ってやり、そのうえで404を返してやることで認証ディレクティブが正常に動作した。web.php// リクエストが他ルートに一致しない場合 Route::fallback(function () { abort(404); });情報求む
- 投稿日:2021-01-10T09:06:44+09:00
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.phpprivate 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.phppublic function update(Request $request) { // 多重サブミットチェック if (!this->multiSubmitCheck($request)) abort(409); ... }加えて、一般的なクライアントサイドにおける多重submit抑止の処理も、不要リクエストの抑制、意図せぬエラー発生の防止等期待できるため、可能な限り行うべきだと思われる。
app.jsconst 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.jsfunction 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 }});">‹</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 }});">›</a>このカスタマイズはページボタンの直近の祖先(親)要素のformに対して、クエリストリングでpageパラメータを付与した後にsubmitしているだけとなる。状況に応じて適宜内容変更することで、様々なケースに対応できると思われる。
404発生時に認証ディレクティブが正常に動作しない問題への対策
404発生時、bladeにて
@auth
や@guest
といった認証ディレクティブが、認証状態にかかわらず@guest
の分岐となる場合がある。レイアウトのbladeにてログイン状態に応じてログイン/ログアウトのボタンの出し分けを行っている場合等、少々不都合があるため対策を講じる必要がある。内部実装を詳細に追ったわけではないので正確な情報は不明だが、認証ディレクティブを正常に動作させるためには、ルート定義ファイルにリクエストを経由させることが必要なようである。
そのため、未定義ルートでも一度web.php
にて拾ってやり、そのうえで404を返してやることで認証ディレクティブが正常に動作した。web.php// リクエストが他ルートに一致しない場合 Route::fallback(function () { abort(404); });情報求む
- 投稿日:2021-01-10T08:07:29+09:00
【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...参考
- 投稿日:2021-01-10T08:07:29+09:00
【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。
参考
- 投稿日:2021-01-10T01:23:15+09:00
オブジェクトとは
関連する変数(値)と関数(動作)をまとめて、そのまとまりに名前を付けたものです。これまで、変数と関数は別々に宣言され管理されてきましたが、関連する変数や関数は1つのオブジェクト内で宣言してまとめてしまうことで、管理しやすくするのがオブジェクト指向。
ブジェクト(object)は、日本語に訳すと、物体。
クラスに含める変数のことは プロパティ 、クラスに含める関数のことは メソッド とも言います。
オブジェクト指向プログラミングとは、積極的にオブジェクトという概念を導入したプログラミング手法ということ。オブジェクト指向プログラミングができるプログラミング言語をオブジェクト指向プログラミング言語。
多くのプログラミング言語がオブジェクト指向を採用。PHP をはじめ、 Java, Ruby, C++, C#, Swift といったプログラミング言語は全てオブジェクト指向プログラミング言語。更に言うと、クラスベースのオブジェクト指向プログラミング言語。
クラスベースのオブジェクト指向では、オブジェクトには クラス と インスタンス という2つの側面があります。
- 投稿日:2021-01-10T01:18:01+09:00
論理演算子
&& 条件A && 条件B 条件Aと条件Bがどちらもtrueならばtrueを返す
|| 条件A || 条件B 条件Aと条件Bのどちらかがtrueならばtrueを返す
! !条件A 条件Aがfalseならtrueを返す
- 投稿日:2021-01-10T01:16:43+09:00
比較演算子
== 右辺と左辺が等しい場合にはtrueを返す。等しくない場合にはfalseを返す。
!= 右辺と左辺が等しくない場合にはtrueを返す。等しい場合にはfalseを返す。
< 右辺より左辺が小さい場合にはtrueを返す。右辺より左辺が大きいか等しい場合にはfalseを返す。
> 右辺より左辺が大きい場合にはtrueを返す。右辺より左辺が小さいか等しい場合にはfalseを返す。
<= 右辺より左辺が小さいか等しい場合にはtrueを返す。
>= 右辺より左辺が大きいか等しい場合にはtrueを返す。
- 投稿日:2021-01-10T01:04:39+09:00
バリデーション
バリデーション 【 validation 】
バリデーションとは、検証、実証、認可、妥当性確認などの意味を持つ英単語。ITの分野では、対象がその仕様や文法などに照らして適切に記述・構築されているか否かを検証するという意味で用いられることが多い。
プログラムのバリデーションといった場合、記述に用いた言語の文法や、そのプログラムに要求される仕様(書の記述)に則って正しく記述されているかを検証することを表す。
- 投稿日:2021-01-10T01:00:09+09:00
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()}}
- 投稿日:2021-01-10T00:42:31+09:00
CRUD
CRUDとは、データベース管理システム(DBRS)に必要とされる4つの主要な機能、「作成(Create)」「読み出し(Read)」「更新(Update)」「削除(Delete)」をそれぞれ頭文字で表したもののことである。
例えばSQLにおいては、「作成」に「INSERT」のコマンドが、「読み出し」に「SELECT」、「更新」に「UPDATE」、「削除」には「DELETE」のコマンドがそれぞれ対応している。CRUDのそれぞれの機能を網羅していることは、データベースシステムの完全性を備えるために必須の要素であるとされている。
フルスペル:Create, Read, Update, Delete
読み方:クラッド
- 投稿日:2021-01-10T00:38:13+09:00
マイグレーションとは
マイグレーション機能では、テーブルを新規に作成するためのマイグレーションファイルと呼ばれるファイルを作成して、マイグレーションを実行することで、マイグレーションファイルに書かれたテーブルの定義がMySQLなどのデータベースに間接的に反映される。
例えば、既存のテーブルに、後からカラムを追加したい場合には、カラムを追加するための別のマイグレーションファイルを新たに作成して実行することで、テーブルの定義を変更していく。
マイグレーション機能を使って、テーブル定義を修正すれば、履歴がマイグレーションファイルという形で残っていく。テーブル定義に変更や追加がある度に、新しくマイグレーションファイルを追加作成する。
マイグレーションファイルをある地点まで戻すことを ロールバックという。
$ php artisan make:migration create_???_table --create=???
$ php artisan migrate
$php artisan make:model Message