20200810のlaravelに関する記事は7件です。

投稿日：2020-08-10T18:19:37+09:00

Laravelのインストール、初期設定、GitHubの使用

Laravelのインストール

Laravelのインストールには専用インストーラを使用する方法とComposerを利用する方法の2つがありますが、今回はComposerでのインストールを行います。
DBはMySQLを使います。
PHPとphpmyadminが使える環境を前提に進めます。

Composerのインストール

ComposerはPHPのパッケージ管理ツールです。
下記のサイトからインストールできます。
Composer

Composerのインストール確認

下記のコマンドを実行してバージョンが表示されればインストールできています。
terminal
 composer --version
 //composer -vでも可
Composerのパッケージインストール時間の短縮

packagist.jpの使用

海外に向いているリポジトリを、日本の有志の方が運用をおこなっているリポジトリ( https://packagist.jp/ )に向ける事でインストールにかかる時間が短縮できます。

リポジトリの追加
terminal
composer config -g repos.packagist composer https://packagist.jp
composer update
リポジトリの削除
terminal
composer config -g --unset repos.packagist
Prestissimoの使用

Prestissimoを導入してダウンロードを並列処理する
Prestissimo
terminal
composer global require hirak/prestissimo
Composerを使ったLaravelのインストール
terminal
  //最新版をインストールする場合
  composer create-project laravel/laravel [プロジェクト名] --prefer-dist

  //バージョンを指定してインストールする場合(x.0の部分がバージョン指定)
  composer create-project laravel/laravel [プロジェクト名] --prefer-dist "x.0.*"
※ --prefer-distはファイル圧縮版を使用するというオプションです。

Laravelの動作確認(簡易サーバー)

プロジェクトのルートに移動して下記コマンドを実行します。
terminal
 php artisan serve
http://localhost:8000/ もしくは　http://127.0.0.1:8000 にアクセスして、Laravelのデフォルトの画面が表示されればOKです。

初期設定

タイムゾーン、言語を日本にする
config/app.php
'timezone' => 'UTC',
//↓
'timezone' => 'Asia/Tokyo',

'locale' => 'en',
//↓
'locale' => 'ja',
DBの文字コードをutf8にする
config/database.php
'mysql' => [
  'charset' => 'utf8mb4',
  //↓
  'charset' => 'utf8',

  'collation' => 'utf8mb4_unicode_ci',
  //↓
  'collation' => 'utf8_unicode_ci',            
]
デバッグバーの使用

インストール

簡易サーバーを立ち上げると下部にデバッグ情報が表示されるようになります。
terminal
composer require barryvdh/laravel-debugbar
非表示

本番環境など表示したくない環境では下記のように値を変更します。
.env
APP_DEBUG=true
//↓
APP_DEBUG=false
DB(MySQL)の設定

phpMyAdminを使ってDB(DB名)とユーザー(ユーザー名、パスワード)を作成して、下記を編集します。
.env
 DB_CONNECTION=mysql
 DB_HOST=127.0.0.1
 DB_PORT=3306
 DB_DATABASE=DB名
 DB_USERNAME=ユーザー名
 DB_PASSWORD=パスワード
Laravel-ui、認証

必要なければ飛ばしても大丈夫です。
terminal
//バージョン指定しない場合
composer require laravel/ui --dev

//バージョン指定する場合
composer require laravel/ui:^1.0 --dev


//スカフォールド生成
php artisan ui bootstrap
php artisan ui vue
php artisan ui react

//スカフォールド生成+ユーザー認証　(認証が必要なときはこちら)
php artisan ui bootstrap --auth
php artisan ui vue --auth
php artisan ui react --auth
npmでのパッケージのインストール

Please run "npm install && npm run dev" to compile your fresh scaffolding.と表示されるので従います。

npmがインストールされていない場合、Node.jsをインストールします。
(Node.jsがインストールされていればnpmも使えるようになります。)
Node.js

Node.js、npmのインストール確認

バージョンが表示されればインストールできています。
terminal
node -v
npm –v
npmによるパッケージインストール

package.jsonの内容に従ってパッケージがインストールされます。
terminal
npm ci
CSSとJavaScriptのビルド
terminal
//一回だけビルド
npm run dev

//ファイルの変更を感知してビルド
npm run watch
ビルド対象のファイル、ビルドして生成されるファイルはwebpack.mix.jsで確認、変更できます。

種類ビルドの対象ファイル

JavaScript resources/js/app/js

SCSS resources/sass/app.scss

種類ビルドで生成されるファイルが格納されるフォルダ

JavaScript public/js

CSS public/css

migration

3つのテーブルが作成されます。
(上で認証機能を追加している場合はusersテーブルを加えた4つのテーブルが作成されます。)
terminal
php artisan migrate
作成されるテーブル

failed_jobs

migrations

password_resets

(users)

Laravelの動作確認(簡易サーバー)

プロジェクトのルートに移動して下記コマンドを実行します。
terminal
 php artisan serve
http://localhost:8000/ もしくは　http://127.0.0.1:8000 にアクセスして、Laravelのデフォルトの画面の右上にLOGINとREGISTERが追加されていればOKです。

エラーメッセージの日本語化

resources/lang/に下記のjaフォルダをenフォルダと同じ階層に配置します。
https://github.com/minoryorg/laravel-resources-lang-ja

※jaフォルダ内のファイルの編集でさらにメッセージのカスタマイズができます。
resources\lang\ja\validation.php
'attributes' => [],
//↓
'attributes' => ['email'=>'メールアドレス',
'name'=>'名前'
],
GitHubの使用

GitHubへpushする

GitHubでリポジトリ作成

GitHubのマイページにあるRepositoriesタブを開き、Newボタンを押します。
リポジトリ名を入力して、空っぽの新規レポジトリを作成しておきます。

ローカルでのGitのリポジトリ作成

プロジェクトルートに移動してGitのリポジトリを作成します。
terminal
git init
.gitignore

Laravelでは、gitを使う前提で.gitignoreがディレクトリ直下に用意されています。

無視ファイル/フォルダ(一部抜粋) 内容

.env 接続情報などが保存されているので、誤ってGitHubに上がらないように設定されている

/vender composerでインストールしたファイル (laravel自体もここに入っている)

/node_modules npmでインストールしたファイルが入っている

push
terminal
git add .
git commit -m "メッセージ"
git remote add origin https://github.com/ユーザー名/リポジトリ名.git
git push -u origin master
GitHubからcloneする

今度はGitHubからファイルを取ってきて使えるようにしていきます。
terminal
git clone https://github.com/ユーザー名/リポジトリ名.git
cloneしただけでは、Laravelの動作に必要なファイルが足りないので、.gitignoreで無視していたファイルを作成します。

.env

DBの接続情報

.env.exampleをコピーして.envにリネームして、接続情報などを記入します。
DBがなければ作成が必要になります。

デバッグバーの使用

使用する場合のみ変更します。
APP_DEBUG=false
//↓
APP_DEBUG=true
アプリケーションキーの作成
terminal
php artisan key:generate
.envのAPP_KEYに値が書き込まれます。

/vender配下のファイル (Composerでのパッケージインストール)

cloneした環境にComposerがインストールがされていない場合はインストールします。
下記コマンドでcomposer.jsonの内容に従ってパッケージがインストールされます。
terminal
composer install
/node_modules配下のファイル (npmでのパッケージインストール)

cloneした環境にnpmがインストールがされていない場合はインストールします。
下記コマンドでpackage.jsonの内容に従ってパッケージがインストールされます。
terminal
npm ci
migration

テーブルを作成します。
terminal
php artisan migrate
Laravelの動作確認(簡易サーバー)

プロジェクトのルートに移動して下記コマンドを実行します。
terminal
 php artisan serve
設定変更が反映されない場合

キャッシュやコンフィグのクリアを試してみてください。
terminal
php artisan cache:clear
php artisan config:clear

種類	ビルドの対象ファイル
JavaScript	resources/js/app/js
SCSS	resources/sass/app.scss

種類	ビルドで生成されるファイルが格納されるフォルダ
JavaScript	public/js
CSS	public/css

無視ファイル/フォルダ(一部抜粋)	内容
.env	接続情報などが保存されているので、誤ってGitHubに上がらないように設定されている
/vender	composerでインストールしたファイル (laravel自体もここに入っている)
/node_modules	npmでインストールしたファイルが入っている

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-10T17:10:32+09:00

laravel-database-autodoc パッケージを作成した

数カ月前から仕事でLaravelを扱うようになって3ヶ月。初めてphpのパッケージを作って公開したのでメモがてらに投稿する。

何をつくったか?

https://packagist.org/packages/yhirano55/laravel-database-autodoc

なぜつくったか?

データベースのスキーマを確認するのが面倒だったので、機械的にすべてのテーブル定義をマークダウンファイルに出力するartisanコマンド。

php artisan migrate を実行したら、CommandFinishedイベントを拾って、ドキュメント生成のコマンドが実行される。

dev dependencyにインストールするだけで、コマンドの使い方などを覚える必要もなく、ドキュメントを生成/更新してくれる代物です。

?こんなマークダウンが自動生成される?

どのようにつくったか?

手順は以下:

Packagistにアカウント登録・GitHubアカウントと連携・2FAを設定

composer init

てきとうなlaravel appに、ローカル環境にあるパッケージをインストール

コマンドやイベントリスナーを実装して、サービスプロバイダーを作成

アプリケーション側から動作することを確認

GitHubにリポジトリを作って、packagistでsubmitしたら公開された

Packagistアカウントを準備

Packagist は、RubyでいうところのRubyGems、JavaScriptでいうところのnpmで、要はPHP向けのレジストリです。やることはごく簡単で以下の通り:

アカウント登録

GitHubとアカウント連携

2FAを設定

パッケージを作成
$ mkdir mylib && cd mylib
$ composer init
composer.json を作った後、以下を設定した:

依存関係（今回はlaravel用のライブラリなのでlaravelを設定。セマンティックバージョニングは5.7以上にする）

オートロード（autoload => psr-4にロードするディレクトリを指定）

適当なlaravel appにインストール

ローカルパッケージとしてインストールする。以下の記事が参考になった:

https://qiita.com/suin/items/d24c2c0d8c221ccbc2f3

pathの指定が相対パスだったが、絶対パスにしないとうまくインストールされなかった。

キャッシュのせいなのか、 composer install だけではうまくインストールされず、 composer update を実行する必要があった。

動作確認はtinkerで、 Foo\Bar\LibraryClass をnewして、hello worldする程度でよい。

コマンドやイベントリスナーを実装して、サービスプロバイダーを作成

コマンドのコードはこちら

Laravel/frameworkのコンソールの実装を参考に雰囲気で書いた。

コード見ればわかるが、information_schema.tables の内容を素朴に書き出している。

MySQL以外で動作確認していないので、SQLiteやPostgresで動作するかは試していない（OSSなので、もし必要ならば必要だと思った方が実装すればよさそう）

イベントリスナーのコードはこちら

migrateの実行をフックしたかったのだが、どのようにやるべきか調べて、コマンド実行前と実行後にイベントがディスパッチされるので、それを拾って、Artisan::call() で実行すればよいのだなと、これもLaravel/frameworkを読んで知った。

サービスプロバイダーは、 composer.json の extra => laravel => providers にプロバイダークラスを設定すると、アプリケーション側から自動検出されるようなのでこれを使った。

アプリケーション側から動作することを確認

これはそのまんま。

GitHubにリポジトリを作って、packagistでsubmitしたら公開された

GitHubにpublicリポジトリを作って、そこにpush。その後、packagistからリポジトリのURLをSubmitすると公開された。

公開後、クロールしているのだなと興味深かった。

感想

所要時間は2時間程度。

ローカルパッケージが反映されず苦戦した。

アプリがコンテナだと当然ローカルパッケージは読み込めないので注意するといい。

今回はファイルを生成するだけのコマンドなのでテストは書いていない。

Laravel/frameworkにパッチを書きたいので、後日テストの所作も調べたい（普通にphpunitだろうけど）

普段はRubyやJavaScriptを書くことが多いけれど、phpやlaravelもなかなか面白い。

作ったパッケージはテーブル定義を確認するときブラウザからも見れるので、それなりに便利に利用できています。
$ composer require --dev yhirano55/laravel-database-autodoc
でインストールできるので、もしよかったらメンテしているLaravelアプリケーションに導入してみてください。

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-10T17:00:17+09:00

Docker × Laravel メールの送信処理をローカルで確認する

ウェブサーバー、アプリケーションサーバー、データベースサーバーが用意されていれば最低限Laravelを動作させることはできますが、実際に開発を進めてくるとメールを送信する処理を書くことが多くあります。

ローカルでのメール確認のためにメールサーバーを用意して、たくさんのメールアカウントを作って、メールを送信して、各メールアカウントでログインして確認...するのはとても非効率です。

そこでメール送信テストツールのMailHogというツールが公式のDockerイメージが提供されています。
こちらを利用すると実際にメールを送信することなく、メール内容をWeb UIで確認できます。

MailHog

開発者向けのメールテストツール

https://github.com/mailhog/MailHog

https://hub.docker.com/r/mailhog/mailhog

前提

最強のLaravel開発環境をDockerを使って構築する【新編集版】

当記事は上記の記事の補足になる記事です。

Laravel環境構築
$ git clone git@github.com:ucan-lab/docker-laravel.git
$ cd docker-laravel/infrastructure
$ make create-project
まずはサクッと環境構築します。

環境

PHP 7.4.6

Laravel 7.21.0

手順

infrastructure/docker-compose.yml を編集する
$ infrastructure
$ docker-compose down
※docker-compose.yml や Dockerfile を変更する場合は予めコンテナを破棄しておくと良いです。
docker-compose.yml
services:
  mail:
    image: mailhog/mailhog
    ports:
      - 8025:8025
mail サービスの設定を services 配下に追記します。
特にカスタマイズは必要ないので、公式のMailHogイメージをそのまま利用します。
$ docker-compose up -d
コンテナを作成して起動します。
$ docker-compose ps
        Name                       Command              State                 Ports              
-------------------------------------------------------------------------------------------------
docker-laravel_app_1    docker-php-entrypoint php-fpm   Up      9000/tcp                         
docker-laravel_db_1     docker-entrypoint.sh mysqld     Up      0.0.0.0:3306->3306/tcp, 33060/tcp
docker-laravel_mail_1   MailHog                         Up      1025/tcp, 0.0.0.0:8025->8025/tcp 
docker-laravel_web_1    nginx -g daemon off;            Up      0.0.0.0:80->80/tcp 
mail のコンテナが起動していればokです。

backend/.env
.env
MAIL_HOST=mail
MAIL_PORT=1025
MAIL_FROM_ADDRESS=info@example.com
環境変数にMailHogの設定を追記します。
ホスト名には mail サービス名を設定、MailHogのSMTPは1025ポートがデフォルトで待ち受けています。
それと送信元アドレスの設定が必要です。

メール送信テスト
$ docker-compose exec app php artisan tinker
Mail::raw('test mail',function($message){$message->to('test@example.com')->subject('test');});
http://127.0.0.1:8025

参考

Laravelとdockerの開発環境でMailHogを使ってメール送信する

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-10T11:16:01+09:00

Laravel開発で使用されるデザインパターン

私は普段、Laravelを使用したWebアプリケーション開発をしています。エンジニア歴はもうすぐ1年くらいです。

最近、「どんなデザインパターンを使ったことがある？」と質問されたのですが、恥ずかしながら何も答えられませんでした。デザインパターンについては、優れた設計の見本集のようなものだ、という程度の理解でした。開発において気をつけていることは何点かありますが、それがデザインパターンなのか、どのパターンに当たるのか、といったことを整理したいと思いました。

サービスコンテナ => Dependency Injectionパターン

Eloquent => Active Recordパターン

Manager => Builderパターン

Middleware => Middlewareパターン

Facade => Proxyパターン

Command => Commandパターン？

結論から書くと、Laravelの機能とデザインパターンの対応は上記のようになっているのではないか、と考えています。

間違っている点や不足している箇所がありましたら、教えていただけますと大変ありがたいです。

Laravelの特徴

Laravelが採用しているデザインパターンについて調べるまえに、そもそもPHPフレームワークにおいてLaravelとはどんな位置づけなのかを整理しておきたいと思いました。Laravel以外のフレームワークを触ったことがなかったからです。

Laravelの特徴を検索すると、次のような情報がヒットしました。

PHPフレームワークの中で最も注目を集めている

フレームワーク独自の概念などがなく習得しやすい

非常に柔軟で多機能であるためWebアプリケーション全般に向いている

MVCモデルを採用している

パッケージ管理ツールとしてComposerを使用している

日本語の情報が豊富

もう少し詳しく知りたかったので、次にCakePHPと比較している記事を探しました。CakePHPもLaravelと同じく、PHPのWebアプリケーションフレームワークです。

LaravelとCakePHPの比較を調べると、Laravelの特徴は次のように書いてありました。

ディレクトリ構成などが自由で制約が少ない

Bladeというテンプレートエンジンが柔軟で使いやすい

ファイルアップロード処理のインタフェースが用意されている

バリデーションをコントローラに記述することができる

ディレクトリ構成が自由

CakePHPでは既存のディレクトリ構成を変更することが難しいようですが、Laravelなら自由に変更することができるようです。独自のライブラリクラスを追加する場合も、簡単にそれが実現できるとありました。

Laravelは自由度が高いため、厳密にコーディング規約を定めておかなければ大規模な開発では収集がつかなくなる、とも書いてありました。「Laravelは自由度が大きいため大規模な案件に向く」という意見と「Laravelは厳密に規約を定めないと収集がつかなくなるので小規模案件に向く」という意見があるようでした。

Bladeテンプレートが優秀

BladeはLaravelのテンプレートエンジンです。

テンプレートエンジンとは、データとテンプレートを組み合わせて文字列を作る仕組みのことだそうです。Viewのことだと解釈してもよさそうです。

LaravelのBladeは、Viewに直接PHPを記述することができる点が特徴らしいです。

BladeはシンプルながらパワフルなLaravelのテンプレートエンジンです。他の人気のあるPHPテンプレートエンジンとは異なり、ビューの中にPHPを直接記述することを許しています。全BladeビューはPHPへコンパイルされ、変更があるまでキャッシュされます。つまりアプリケーションのオーバーヘッドは基本的に０です。Bladeビューには.blade.phpファイル拡張子を付け、通常はresources/viewsディレクトリの中に設置します。

https://readouble.com/laravel/5.8/ja/blade.html

私はViewにPHPを記述できるのが当たり前だと思っていたので、少し驚きました。

Bladeでは、分岐や繰り返しのための制御構文も充実しているため、複雑なViewも簡単に実現できます。@ifといった記述で制御するのですが、これをディレクティブというようです。

また、Blade内で{{ }}に囲まれたデータの出力は、自動的にhtmlspecialchars()が適用されてエスケープされるのですが、他のテンプレートエンジンでは自分でエスケープ処理が必要だったりするようです。

Bladeは、エスケープしたくない場合も次のように書くことで実現できます。
Hello, {!! $name !!}.
バリデーション処理の柔軟性

バリデーションが実行されるレイヤが、Laravelではコントローラ、CakePHPではモデルと異なるようです。

私は普段、Requestクラスにバリデーションルールを定義することが多いです。同じモデルを操作する場合でも、アクションによって許容する入力値を変えたい場合もありますので、CakePHPを触ったことはないので断言できませんが、コントローラ側でバリデーションルールを定義できたほうが便利なんじゃないか、と思っています。

アップロード処理のインタフェース

CakePHPを使う場合は、ファイルアップロードの処理を自分で実装したり、外部のプラグインを使う必要があるらしいです。手間もかかる上に、外部のプラグインを使う場合は設定値などを変更できないケースもあり、柔軟性がないとも書いてありました。

Laravelではファイルストレージ用のインタフェースが最初から用意されているため、数行のコードでファイルアップロード処理が実装できます。保存先をローカルストレージからクラウドストレージに切り替えることも簡単でした。

Laravelが採用するデザインパターン

Dependency Injectionパターン（DIパターン）

Dependency Injection（以下DI）もデザインパターンの一種らしいです。

Laravelにはサービスコンテナと呼ばれる機能が備わっていて、DIが簡単に実現できるようになっています。DIは日本語で依存性の注入と訳されます。クラスが動作するために必要となる別のクラスを、実行時に外から渡してやることで、クラス同士を疎結合にすること、と自分は理解しています。

DIパターンを利用することで、次のようなメリットがあると思います。

特定のクラスに依存させないことで、下位モジュールがまだできていなくても、実装を進められる

依存するクラスを外部から渡すことができるので、テスト用のクラスに置き換えも容易になる

Active Recordパターン

私は初めて知ったのですが、Active Recordパターンというデザインパターンがあるそうです。

Patterns of Enterprise Application Architectureという書籍で紹介されているそうです。

データベーステーブルまたはビューの行をラップし、データベースアクセスをカプセル化してデータにドメインロジックを追加するオブジェクト

Patterns of Enterprise Application Architecture

LaravelにはEloquentというORM（Object-relational mapping）がありますが、これがActive Recordの特徴を備えている、という意味の説明を見ました。

ORMはデータベーステーブルのレコードをオブジェクトのように扱うための仕組みだと理解していますが、EloquentではQuery Builderを使ってレコードの集合（コレクション）を操作することができます。この点がActive Recordパターンの特徴と一致しているのだと思いました。

Builderパターン

BuilderパターンはGoFデザインパターンのひとつで、オブジェクト生成の過程を抽象化することが目的です。Directorと呼ばれるクラスで作成過程を定義して、Builderと呼ばれるクラスで表現形式を決定する、と説明されていました。Template Methodパターンでオブジェクトを生成する、という意味だと解釈しました。

LaravelにはQuery Builderというものがありますが、これは他のフレームワークにも登場する一般的な機能のようです。Query Builderは、SQLクエリをORMで実行するためのインタフェース、とあったので、Builderパターンと名前が似ていますが、別物のようです。

一方、Laravelに用意されているIlluminate\Support\Managerクラスは、Builderパターンを実現するための抽象クラスだ、という説明を読みました。

Laravel Managerの例としてAuthorizeManagerを作る

こちらの記事によると、Laravel5.6以降はなぜかLaravel本体ではManagerクラスが使われなくなってきているようですが、Laravelの機能を拡張したい場合は便利みたいです。

Middlewareパターン

LaravelではMiddlewareクラスでアプリケーションに送信されたHTTPリクエストをフィルタリングすることができます。認証や認可に関するチェックをしたり、入力値を整形したりするときに私は使用しています。

Middlewareパターンというデザインパターンにあたるらしいです。

Proxyパターン

LaravelにはFacadeという仕組みがあり、これはサービスクラスに登録したクラスに対する静的なインタフェースを提供する窓口です。

Facadeはサービスコンテナ下で動作するクラスに対してstatic proxyとして動作する、と説明されていたので、デザインパターンにおけるProxyパターンに該当するのではないかと考えています。

Proxyパターンでは、Proxy（代理人）と呼ばれるクラスを通じて目的の処理を呼び出します。このとき、Proxyと実際に処理が定義されているクラスは同じインタフェースを提供するため、呼び出し元はどちらを利用しているか意識せずに処理を実行でき、このことを透過的と表現するようです。

Facadeパターン

GoFデザインパターンのひとつにFacadeパターンというものがありますが、こちらは複数のクラスが関わる複雑な手順をひとつの抽象的なメソッドにまとめ、外部に対してわかりやすいインタフェースを提供することを目的とするらしいので、LaravelのFacadeとは意味が違うようです。

FacadeパターンにおけるFacadeはむしろ、Serviceクラスに近いような印象を受けました。

私が所属しているプロジェクトでは、RepositoryクラスのいくつかのメソッドをServiceクラスのひとつのメソッドとしてまとめ、抽象的なインタフェースを実装することがルールになっています。これにより、Serviceクラスを利用する側は内部の複雑な手順を知る必要がなくなり、同時にControllerとRepositoryが疎結合になるので、Repositoryの修正がしやすくなるなどのメリットがあると思っています。

Commandパターン

Laravelにはコマンドというクラスがあり、ここで定義した処理はコマンドラインから実行することが可能です。

デザインパターンにもCommandデザインパターンというものがあり、こちらはオブジェクトに対する命令をクラスとして定義することで、複雑な操作の組み合わせを簡単に実行できるようにしたり、実行の履歴を残したりすることを目的としているようです。

LaravelのCommandとデザインパターンのCommandは、一連の操作をクラスとして定義するという点では似ていますが、LaravelのCommandはコマンドラインインタフェースを提供することが目的のようなので、少し違うような感じもしています。

Laravelが採用していないデザインパターン

Repositoryパターン

Repositoryパターンは、Laravelは採用していないデザインパターンですが、なぜかLaravelについて検索するとRepositoryパターンに関する記事がたくさんヒットします。それだけRepositoryパターンが便利ということでしょうか。

RepositoryパターンはGoFデザインパターンにはありませんでした。ドメイン駆動設計の中に出てくる考え方のようです。Repositoryパターンの目的は、ビジネスロジックとデータ操作のロジックを分離して、データ操作を抽象化したレイヤに任せることだそうです。

Repositoryを利用する側は、オブジェクトの永続化層が何であるかを意識しなくても良いという利点があり、データベースの移行などの変更にも対応しやすくなります。また、ビジネスロジックとデータ操作を分けてテストすることができるようになります。

まとめ

Laravelと関連するデザインパターンについてまとめましたが、正しいことが書けているか自信がないため、間違いや不足がある箇所がありましたらご指摘いただけるとありがたいです。

Laravelに関連すると思われるデザインパターンは次の通りです。

サービスコンテナ => Dependency Injectionパターン

Eloquent => Active Recordパターン

Manager => Builderパターン

Middleware => Middlewareパターン

Facade => Proxyパターン

Command => Commandパターン？

デザインパターンといえばGoFデザインパターンしか思い浮かびませんでしたが、検索するとそれ以外のデザインパターンがたくさんあることを知れたのが良かったと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-10T10:46:31+09:00

Laravenの認証タイムアウト時のリダイレクト先（複数のログインページ対応版)

ログインが切れてリダイレクトされるページの設定

基本的にはマニュアルにある、Laravel 6.x 認証 > 未認証ユーザーのリダイレクトのセクションに記載されている通り。
https://readouble.com/laravel/6.x/ja/authentication.html

このサンプルでは、認証が1つのケースではこれだけで十分ですが、複数のログインを使う時は、
これだと、どのユーザーでも同じログインURLに戻されてしまいます。

URIで振り分ける

ログインページの条件によって、リダイレクト先を変更したいと思います。
やり方は、URIを使って、どのページを表示しようとしていたのか、把握して条件分岐します。
route('xxxx')は、routes/web.php で各自設定したものを使います。
app/Http/Middleware/Authenticate.phpAuthenticate.php
<?php

namespace App\Http\Middleware;

use Illuminate\Auth\Middleware\Authenticate as Middleware;

class Authenticate extends Middleware
{
    /**
     * Get the path the user should be redirected to when they are not authenticated.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return string|null
     */
    protected function redirectTo($request)
    {
        if (! $request->expectsJson()) {
            $URI = explode("/", $request->getRequestUri());
            switch ($URI[1]){
                //管理画面が https/xxx.xxx/admin/xxxxxのケース
                case 'admin':
                return route('admin_login');

                //管理画面が https/xxx.xxx/shop_admin/xxxxxのケース
                case 'shop_admin':
                return route('shop_admin_login');

                //ユーザーマイページが https/xxx.xxx/mypage/xxxxxのケース
                case 'mypage':
                return route('login');
            }
        }
    }
}
このように、どこのページを開こうとしてセッションタイムアウトになったかで、ログインページの表示を振り分けることができます。
またログインページが複数ある場合は、設定しておくと便利かと思います。

ご参考ください。

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-10T05:07:02+09:00

Docker × Laravel Vueをインストールしてログイン機能まで実装する

DockerでLaravel環境を構築する記事を書きましたが、
Vue以外にもReactを選択したり、フロント側はそもそもリポジトリを分けて開発する場合もあり前回の記事では紹介しきれていませんでした。

今回はLaravel環境を構築したあと、Vueのインストールまで試してみます。

Laravel UI とは

Laravelバージョン 5.8 までは、php artisan make:auth というコマンドが用意されていましたが、 Laravel 6.0 以降は Laravel UI パッケージに切り離されました。

https://github.com/laravel/ui

https://readouble.com/laravel/7.x/ja/frontend.html

Laravel7はlaravel/uiは2.x系

https://readouble.com/laravel/6.x/ja/frontend.html

Laravel6はlaravel/uiは1.x系

前提

最強のLaravel開発環境をDockerを使って構築する【新編集版】

当記事は上記の記事の補足になる記事です。

Laravel環境構築
$ git clone git@github.com:ucan-lab/docker-laravel.git
$ cd docker-laravel/infrastructure
$ make create-project
http://127.0.0.1

とりあえず、Laravelの環境を構築します。

環境

PHP: 7.4.6

Laravel: 7.24.0

Laravel UI: 2.1.0

Node: 14.2.0

npm: 6.14.4

yarn: 1.22.4

Vue: 2.6.11

補足: npm, yarn どちらを使うのか？

正直どちらでも構わないと思います。
ただ、どちらを使うかプロジェクトで統一されている必要はあるかと思います。

今回はnpm, yarnコマンドを併記する形で進めたいと思います。

Vue プリセットのインストール

公式の手順に沿って、実行します。
私のDocker環境の場合は下記の流れになります。
$ cd infrastructure
$ docker-compose exec app bash
$ composer require laravel/ui
$ php artisan ui vue --auth
$ exit
app コンテナを抜けて web コンテナに入ります。
$ docker-compose exec web ash
$ npm install # yarn
$ npm run dev # yarn dev
http://127.0.0.1

補足: スクリーンショット

ホーム画面

右上にLOGIN, REGISTERのメニューが追加されています。

登録画面

ログイン画面

ログイン後のホーム画面(ダッシュボード)

リセットパスワード画面

パスワードリセットのメールはMailHogで確認しています。

Docker × Laravel メールの送信処理をローカルで確認する

補足: webコンテナのNode.js

webコンテナ内にNode(npm, yarn)が入ってますが、コンテナ内でビルドするのは非常に時間がかかってしまうので実際の開発ではMacローカルにNodeを入れて実行させるのが良いです。

Homebrew 経由の anyenv 経由の nodenv 経由で Node.js をインストールする

補足: Nodeバージョン固定化

特定のバージョンのNode.jsでしか動かして欲しくない場合、package.jsonのenginesフィールドにNode.jsのバージョンを明記しておくとyarn installやnpm installした時に警告を表示してくれます。
package.json
{
    "private": true,
    "scripts": {
        "dev": "npm run development",
        "development": "cross-env NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js",
        "watch": "npm run development -- --watch",
        "watch-poll": "npm run watch -- --watch-poll",
        "hot": "cross-env NODE_ENV=development node_modules/webpack-dev-server/bin/webpack-dev-server.js --inline --hot --disable-host-check --config=node_modules/laravel-mix/setup/webpack.config.js",
        "prod": "npm run production",
        "production": "cross-env NODE_ENV=production node_modules/webpack/bin/webpack.js --no-progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js"
    },
    "devDependencies": {
        "axios": "^0.19",
        "bootstrap": "^4.0.0",
        "cross-env": "^7.0",
        "jquery": "^3.2",
        "laravel-mix": "^5.0.1",
        "lodash": "^4.17.13",
        "popper.js": "^1.12",
        "resolve-url-loader": "^2.3.1",
        "sass": "^1.20.1",
        "sass-loader": "^8.0.0",
        "vue": "^2.5.17",
        "vue-template-compiler": "^2.6.10"
    },
    "engines": {
        "node": "14.2.0"
    }
}
補足: Nodeバージョン自動切り替え設定ファイル

.node-version を package.json と同じディレクトリに配置しておくと、nodenvが自動的にNodeのバージョンを切り替えてくれて便利です。
.node-version
14.2.0
参考

最強のLaravel開発環境をDockerを使って構築する【新編集版】

Homebrew 経由の anyenv 経由の nodenv 経由で Node.js をインストールする

Laravel6 ログイン機能を実装する

package.jsonに"engines"を設定すると「このバージョンのNode.jsでしか動かない」を表明できる

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-10T02:20:19+09:00

Laravel npm run devでエラーが発生した話

目的

npmを用いて必要パッケージを取得後に$ npm run devを実行したらエラーが発生した話をまとめる

実施環境

ハードウェア環境

項目情報

OS macOS Catalina(10.15.5)

ハードウェア MacBook Pro (13-inch, 2020, Four Thunderbolt 3 ports)

プロセッサ 2 GHz クアッドコアIntel Core i5

メモリ 32 GB 3733 MHz LPDDR4

グラフィックス Intel Iris Plus Graphics 1536 MB

ソフトウェア環境

項目情報備考

PHP バージョン 7.4.3 Homwbrewを用いて導入

Laravel バージョン 7.0.8 commposerを用いてこちらの方法で導入→Mac Laravelの環境構築を行う

MySQLバージョン 8.0.19 for osx10.13 on x86_64 Homwbrewを用いてこちらの方法で導入→Mac HomebrewでMySQLをインストールする

Node.jsバージョン 14.6.0 こちらの方法で導入した→AWS EC2 AmazonLinux2 Node.jsをインストールしてnpmコマンドを使用できる様にする

npmバージョン 6.14.6 こちらの方法で導入した→AWS EC2 AmazonLinux2 Node.jsをインストールしてnpmコマンドを使用できる様にする

エラーの原因

$ npm installを実行し忘れていた。

問題までの経緯
下記で紹介されている内容を実施したくてLaravelアプリを新規作成した。

https://blog.capilano-fw.com/?p=3998
アプリ名ディレクトリに移動後、下記コマンドを実行してパッケージインストールを行った。
$ npm install simple-peer --save-dev
$ npm install pusher-js --save-dev
アプリ名ディレクトリで下記コマンドを実行してのbootstrap.jsを開く。
$ vi resources/js/bootstrap.js
下記の内容を追記する。
resources/js/bootstrap.js
window.Peer = require('simple-peer');
window.Pusher = require('pusher-js');
アプリ名ディレクトリで下記コマンドを実行してapp.jsを開く。
$ resources/js/app.js
下記の記載をコメントアウトした。
修正前
resources/js/app.js
const app = new Vue({
  el: '#app'
});
修正後
resources/js/app.js
//const app = new Vue({
//  el: '#app'
//});
アプリ名ディレクトリで下記コマンドを実行してビルドを試みた。
$ npm run dev
問題
下記のエラーが発生した。
> @ dev /var/www/html/pusher_video
> npm run development

> @ development /var/www/html/pusher_video
> cross-env NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js

sh: cross-env: command not found
npm ERR! code ELIFECYCLE
npm ERR! syscall spawn
npm ERR! file sh
npm ERR! errno ENOENT
npm ERR! @ development: `cross-env NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js`
npm ERR! spawn ENOENT
npm ERR! 
npm ERR! Failed at the @ development script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/ec2-user/.npm/_logs/2020-08-04T03_20_02_697Z-debug.log
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @ dev: `npm run development`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the @ dev script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/ec2-user/.npm/_logs/2020-08-04T03_20_02_713Z-debug.log
問題解決までの経緯

$ npm installを実行していなかったことに気が付き実行した。

再度$ npm run devを実行したところエラーは発生せず問題は解決した。

項目	情報
OS	macOS Catalina(10.15.5)
ハードウェア	MacBook Pro (13-inch, 2020, Four Thunderbolt 3 ports)
プロセッサ	2 GHz クアッドコアIntel Core i5
メモリ	32 GB 3733 MHz LPDDR4
グラフィックス	Intel Iris Plus Graphics 1536 MB

項目	情報	備考
PHP バージョン	7.4.3	Homwbrewを用いて導入
Laravel バージョン	7.0.8	commposerを用いてこちらの方法で導入→Mac Laravelの環境構築を行う
MySQLバージョン	8.0.19 for osx10.13 on x86_64	Homwbrewを用いてこちらの方法で導入→Mac HomebrewでMySQLをインストールする
Node.jsバージョン	14.6.0	こちらの方法で導入した→AWS EC2 AmazonLinux2 Node.jsをインストールしてnpmコマンドを使用できる様にする
npmバージョン	6.14.6	こちらの方法で導入した→AWS EC2 AmazonLinux2 Node.jsをインストールしてnpmコマンドを使用できる様にする

　 Tweet
Qiitaで続きを読む