PHPのフレームワークであるLaravelの環境設定について記載します 利用環境 OS:Mac(M1) 始める前に まず、Laravelは通常のアプリケーションのようにダウンロードボタンからダウンロードするのではなく、ターミナルからコマンドを打って実行します。そのコマンドを打つために必要になるのが、composerというプログラムを利用します。そのため、まずはcomposerのインストールから始めます。 homebrewの導入 導入 homebrewの導入 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" エラーが出なければOK 確認 homebrewの確認 brew -v バージョンが正しく表示されればOK composerの導入 導入 composerの導入 brew install composer エラーが出なければOK 確認 composerの確認 composer -V バージョンが正しく表示されればOK ※「V」は大文字じゃないとダメ Laravelの導入 導入 Laravelの導入 composer global require "laravel/installer=~1.1" 環境変数PATHの設定 このままでは入ってはいてもコマンドが有効になっていないため、下記を実行して有効にする echo "export PATH=~/.composer/vendor/bin:$PATH" >> ~/.bash_profile source ~/.bash_profile Laravelを使ってみる プロジェクトの作成 プロジェクトを作成したいディレクトリまで移動してから下記を実行 composer create-project laravel/laravel プロジェクト名 --prefer-dist アプリケーションの実行 設定したプロジェクト名のディレクトリに移動してから下記を実行 php artisan serve 表示されたURLにリクエストして、Laravelのページが表示されればOK

PHPのフレームワークであるLaravelの環境設定について記載します 利用環境 MacOS Big Sur MacBookAir(13-inch, Mid2013) 始める前に まず、Laravelは通常のアプリケーションのようにダウンロードボタンからダウンロードするのではなく、ターミナルからコマンドを打って実行します。そのコマンドを打つために必要になるのが、composerというプログラムを利用します。そのため、まずはcomposerのインストールから始めます。 homebrewの導入 導入 homebrewの導入 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" エラーが出なければOK 確認 homebrewの確認 brew -v バージョンが正しく表示されればOK composerの導入 導入 composerの導入 brew install composer エラーが出なければOK 確認 composerの確認 composer -V バージョンが正しく表示されればOK ※「V」は大文字じゃないとダメ Laravelの導入 導入 Laravelの導入 composer global require "laravel/installer=~1.1" 環境変数PATHの設定 このままでは入ってはいてもコマンドが有効になっていないため、下記を実行して有効にする echo "export PATH=~/.composer/vendor/bin:$PATH" >> ~/.bash_profile source ~/.bash_profile Laravelを使ってみる プロジェクトの作成 プロジェクトを作成したいディレクトリまで移動してから下記を実行 composer create-project laravel/laravel プロジェクト名 --prefer-dist アプリケーションの実行 設定したプロジェクト名のディレクトリに移動してから下記を実行 php artisan serve 表示されたURLにリクエストして、Laravelのページが表示されればOK

コントローラを作成-- $ php artisan make:controller コントローラ名 モデルを作成 ※補足ですがモデル名は単数形にするのが慣例らしいです $ php artisan make:model モデル名 末尾に-mを付けるとマイグレーションも一緒に作成してくれる php artisan make:model モデル名 -m マイグレーションを作成 $ php artisan make:migration create_テーブル名_table --create=テーブル名 シーダーを作成 $ php artisan make:seeder シーダー名 Authのあれこれを自動生成する $ php artisan make:auth

Xserverで同一ドメイン内で複数のLaravelプロジェクトをデプロイするときのメモ 前提 バージョン：Laravel6 ドメイン名：hoge.com プロジェクト名：funya composer導入済み ①hoge.com直下にプロジェクトを作成 下記コマンドでプロジェクトを作成する。 $ php artisan create-project --prefer-dist laravel/laravel funya "6.*" または、作成済のプロジェクトをアップロードする。 ②プロジェクト内のpublicフォルダを移動 funya内のpublicフォルダをhoge.com内のpublic_html内に移動する。 その際にpublicフォルダをfunyaにリネームする ③index.phpを編集 funya（元public）フォルダ内のindex.phpを下記のように変更する。 //24行と38行にあるこれらを、、、 require __DIR__.'/../vendor/autoload.php'; $app = require_once __DIR__.'/../bootstrap/app.php'; //プロジェクトfunyaにパスが通るように修正する require __DIR__.'/../../funya/vendor/autoload.php'; $app = require_once __DIR__.'/../../funya/bootstrap/app.php'; 結果 hoge.com/funya でプロジェクトにアクセス可能になる。 同じ処理をすれば複数のプロジェクトを同一ドメイン内におさめることができる。

結論 use Illuminate\Support\Facades\Log; $user = User::find(1); Log::debug(print_r($user, true)); 参考

ようやく完成しました！Backlogを強力にブーストするツール。その名もBacklog Boostar Tools。 当ツールには、三つの機能がございます。それぞれの機能の概要は下記の通りです。 期間集計ツール backlogプロジェクト内を期間指定して工数集計ができるツールです。 SESや月額時完成保守契約などで、月ごとの工数実績を、プロジェクトごとに出したい、というようなケースがあるかと思います。そういったケースで、便利にお使いいただけるツールかと思います。CSVダウンロード機能も追加しました。 一斉送信ツール バックログで保守運用を管理している企業などでは、夏季休業、年末年始休業などのお知らせなどのクライアントへの各種連絡もバックログの課題でやっているケースもあるかと思います。 そうした場合、プロジェクト毎にいちいち同じ課題を作成するのは大変です。 このツールを使えば、一回の投稿でまとめて送ることができます。 日報作成ツール バックログ上で全ての業務上のやりとりが完結している企業で働いている人の場合、このツールを使い、毎日の日報作りを効率良く進めていただくことができます。 このツールでは、特定のユーザーが対応した課題のキーとタイトルを、プロジェクト毎に箇条書きで表示してくれます。 メンバー登録について メンバー登録をすると、各種設定を保存・呼び出しをすることができます。 バックログのAPIキーなどはDBに保存せず、10分間有効なクッキーとしてセッション中は各ツールを跨いで保存されます。一斉送信ツールの送信先や期間集計ツールの対象PJキーなどは、DBに保存・呼び出しができるため便利かと思います。 URL ツールのURLはこちらです。是非とも日頃の業務にご活用ください。 https://backlog.boostar.tools/

はじめに 前回のサービスコンテナ編の続きとして、最後にサービスプロバイダのご紹介をします。 シリーズ Laravelの構成概念 第1回 ライフサイクル編 Laravelの構成概念 第2回 サービスコンテナ編 Laravelの構成概念 第3回 サービスプロバイダ編 環境 PHP 8.0.3 Laravel 8.38.0 参考 Laravel 8.x ライフサイクル Laravel 8.x サービスコンテナ Laravel 8.x サービスプロバイダ Laravel 8.x ファサード (今回はあまり触れません) Laravel API 8.x Laravel フレームワーク Laravel コアフレームワーク Laravelの構成概念については公式ドキュメントにより詳しい内容がまとまっているので詳細を知りたい方は上記の公式ドキュメントをご覧ください。 用語 Laravel サービスコンテナ クラスの依存関係を管理し、依存注入(DI)を実行するための機能です。 サービスコンテナにクラスを登録する(結合) サービスコンテナに登録されたクラスのインスタンスを取り出す(依存解決) サービスコンテナはサービス(クラス)を入れておく箱のイメージです。 Laravel サービスプロバイダ Laravelアプリケーション全体の起動処理における初期起動処理を行っています。 サービスプロバイダからサービスコンテナへDIの設定(コンテナ結合)を行います。 サービスプロバイダーでは、コンテナ結合以外にもイベントリスナ、フィルター、ルーティングの設定なども行います。 (今回は触れません) Laravel 標準のサービスプロバイダ config/app.php の providers に登録されているサービスプロバイダーはLaravelアプリケーションにリクエストの際に自動的に読み込まれます。 新しく自分で作ったサービスプロバイダはこのリストに追加していきます。 config/app.php /* |-------------------------------------------------------------------------- | Autoloaded Service Providers |-------------------------------------------------------------------------- | | The service providers listed here will be automatically loaded on the | request to your application. Feel free to add your own services to | this array to grant expanded functionality to your applications. | */ 'providers' => [ /* * Laravel Framework Service Providers... */ Illuminate\Auth\AuthServiceProvider::class, Illuminate\Broadcasting\BroadcastServiceProvider::class, Illuminate\Bus\BusServiceProvider::class, Illuminate\Cache\CacheServiceProvider::class, Illuminate\Foundation\Providers\ConsoleSupportServiceProvider::class, Illuminate\Cookie\CookieServiceProvider::class, Illuminate\Database\DatabaseServiceProvider::class, Illuminate\Encryption\EncryptionServiceProvider::class, Illuminate\Filesystem\FilesystemServiceProvider::class, Illuminate\Foundation\Providers\FoundationServiceProvider::class, Illuminate\Hashing\HashServiceProvider::class, Illuminate\Mail\MailServiceProvider::class, Illuminate\Notifications\NotificationServiceProvider::class, Illuminate\Pagination\PaginationServiceProvider::class, Illuminate\Pipeline\PipelineServiceProvider::class, Illuminate\Queue\QueueServiceProvider::class, Illuminate\Redis\RedisServiceProvider::class, Illuminate\Auth\Passwords\PasswordResetServiceProvider::class, Illuminate\Session\SessionServiceProvider::class, Illuminate\Translation\TranslationServiceProvider::class, Illuminate\Validation\ValidationServiceProvider::class, Illuminate\View\ViewServiceProvider::class, /* * Package Service Providers... */ /* * Application Service Providers... */ App\Providers\AppServiceProvider::class, App\Providers\AuthServiceProvider::class, // App\Providers\BroadcastServiceProvider::class, App\Providers\EventServiceProvider::class, App\Providers\RouteServiceProvider::class, ], 基本のサービスプロバイダ サービスプロバイダの雛形を作成するコマンドが用意されています。 $ php artisan make:provider ClockServiceProvider config/app.php 'providers' => [ // ... App\Providers\ClockServiceProvider::class, ], app/Providers/ClockServiceProvider.php <?php declare(strict_types=1); namespace App\Providers; use App\Service\Clock; use App\Service\ClockInterface; use Illuminate\Support\ServiceProvider; final class ClockServiceProvider extends ServiceProvider { public function register(): void { $this->app->singleton(ClockInterface::class, Clock::class); } } シングルトンの結合を使って、ClockInterfaceにClockクラスをバインドします。 シングルトンの結合は1回のみ依存解決されます。 今回はClock用のサービスプロバイダーを作りましたが、コンテナ結合したいだけなら全部 AppServiceProvider にまとめてしまって良いと思います。 また、別のライブラリの設定用途等の場合はサービスプロバイダは分けた方が良いです。 サンプル: Clock関連のファイル 動作確認のため、サンプルファイルを用意しました。 app/Service/ClockInterface.php <?php declare(strict_types=1); namespace App\Service; use DateTimeImmutable; interface ClockInterface { /** * @return DateTimeImmutable */ public function now(): DateTimeImmutable; } PSR-20 Clock を参考に ClockInterface を定義します。システムの現在時刻を定義するインターフェースです。 DateTimeImmutable はクラスの挙動は DateTime とほぼ同じ振る舞いをします。ただし、自分自身は変更せずに新しいオブジェクトを返すという点だけが異なります。 app/Service/Clock.php <?php declare(strict_types=1); namespace App\Service; use DateTimeImmutable; final class Clock implements ClockInterface { /** * @return DateTimeImmutable */ public function now(): DateTimeImmutable { return new DateTimeImmutable(); } } ClockInterface を実装した Clock クラスです。 app/Http/Controllers/ClockController.php <?php declare(strict_types=1); namespace App\Http\Controllers; use App\Service\ClockInterface; use Illuminate\Http\Request; final class ClockController extends Controller { /** * @param ClockInterface $clock */ public function __construct(private ClockInterface $clock) { } /** * @return string */ public function __invoke(): string { return $this->clock->now()->format('Y-m-d H:i:s'); } } コントローラでコンストラクタインジェクション(依存性の注入)します。 具象(Clock)ではなく抽象(ClockInterface)に依存してることに注目してください。 実行時にはサービスプロバイダでバインドした Clock のインスタンスが $clock 入ります。 補足ですが、このコンストラクタの書き方はPHP8の新しいか書き方です。(PHP 8: Constructor property promotion) routes/api.php <?php declare(strict_types=1); use App\Http\Controllers\ClockController; use Illuminate\Support\Facades\Route; Route::get('now', ClockController::class); コントローラを作ったので、それに対応するルーティングを定義します。 $ curl http://localhost/api/now 2021-04-27 09:12:49 APIを叩いて現在の日付が返ってきたのでokです。 テストコードの例も書いてみます。 tests/Feature/ClockControllerTest.php <?php declare(strict_types=1); namespace Tests\Feature; use App\Service\ClockInterface; use DateTimeImmutable; use Tests\TestCase; final class ClockControllerTest extends TestCase { public function testInvoke(): void { $this->mock(ClockInterface::class, function ($mock): void { $mock->shouldReceive('now') ->andReturn(new DateTimeImmutable('2021-01-01 23:59:59')) ->once(); }); $response = $this->get('/api/now'); $response->assertStatus(200); $response->assertSee('2021-01-01 23:59:59'); } } コントローラで呼び出されている $this->clock->now() の部分ですが、現在時刻を取得するので当たり前ですが実行するたびに値が変わってしまいます。 動的な値をテストするのはとても大変なので固定の日付を返すようにモックと差し替えてます。 LaravelではMockeryが組み込まれており、インスタンスの差し替えが簡単に行えます。(プロダクションコードを書き換えることなくできる) $ php artisan test PASS Tests\Feature\ClockControllerTest ✓ invoke Tests: 1 passed Time: 0.75s テストが成功しているのでokです！ 補足: 基本のサービスプロバイダ(バインド) app/Providers/ClockServiceProvider.php <?php declare(strict_types=1); namespace App\Providers; use App\Service\Clock; use App\Service\ClockInterface; use Illuminate\Support\ServiceProvider; final class ClockServiceProvider extends ServiceProvider { public function register(): void { $this->app->bind(ClockInterface::class, Clock::class); } } シンプルな結合を使ってもokですが、この場合は呼び出すたびにClockインスタンスが生成されます。 app/Providers/ClockServiceProvider.php <?php declare(strict_types=1); namespace App\Providers; use App\Service\Clock; use App\Service\ClockInterface; use Illuminate\Support\ServiceProvider; final class ClockServiceProvider extends ServiceProvider { // シングルトンの結合 public array $singletons = [ ClockInterface::class => Clock::class, ]; // シンプルな結合 public array $bindings = [ ClockInterface::class => Clock::class, ]; } 別の書き方として、 $singletons や $bindings プロパティに連想配列を定義するだけで行えます。 補足: singleton と bind の違い $ php artisan tinker >>> app(App\Service\ClockInterface::class); => App\Service\Clock {#3345} app(App\Service\ClockInterface::class); を実行すると依存解決されて、App\Service\Clock のインスタンスが取り出されます。 spl_object_id メソッドでインスタンスIDを取得できるので、singletonとbindの違いを確認してみます。 singleton $ php artisan tinker >>> spl_object_id(app(App\Service\ClockInterface::class)); => 3345 >>> spl_object_id(app(App\Service\ClockInterface::class)); => 3345 >>> spl_object_id(app(App\Service\ClockInterface::class)); => 3345 singletonは同じインスタンスが取り出される。 bind $ php artisan tinker >>> spl_object_id(app(App\Service\ClockInterface::class)); => 3345 >>> spl_object_id(app(App\Service\ClockInterface::class)); => 3338 >>> spl_object_id(app(App\Service\ClockInterface::class)); => 3345 bindは毎回異なるインスタンスが取り出される。 補足: 遅延プロバイダ サービスプロバイダーが、コンテナ結合の登録だけであれば遅延プロバイダを利用できます。 遅延プロバイダをにすることでその結合が実際に必要になるまでコンテナへの登録を遅らせることができます。 リクエストがあるたびにファイルシステムからロードされなくなるので、アプリケーションのパフォーマンス向上が見込めます。 遅延プロバイダにするには DeferrableProvider を実装します。 app/Providers/ClockServiceProvider.php <?php declare(strict_types=1); namespace App\Providers; use App\Service\Clock; use App\Service\ClockInterface; use Illuminate\Contracts\Support\DeferrableProvider; use Illuminate\Support\ServiceProvider; final class ClockServiceProvider extends ServiceProvider implements DeferrableProvider { public array $singletons = [ ClockInterface::class => Clock::class, ]; /** * @return string[] */ public function provides(): array { return array_keys($this->singletons); } } さいごに サービスプロバイダについては基本の方法だけご紹介しました。 他にもいろんな初期設定に使われますが、必要になってからで良いと思います。 第1回 ライフサイクル編の投稿してから2ヶ月経ちましたがようやく書き上げることができました? なかなか続きものの記事って書くの飽きてモチベーションなくなるんですよね... (回を重ねるごとにLGTM数が減りますからね...?) 参考 Laravel 8.x サービスプロバイダ Laravel8.x モック Mockery1.0 Mockery https://github.com/mockery/mockery

現在のDocker環境は、docker-compose.yml達とLaravelを同梱している。 その為、Gitにプッシュしようと思ったら、丸ごと行ってしまう。 Laravelだけ、リポジトリ管理する事にした。 マシンスペック Mac mini 2018 macOS Catalina（10.15.x） Intel Core-i7 3.2GHz 6コア メモリ 32GB SSD 512GB Docker環境 Nginx 最新版 PHP（PHP-FPM）7.2.x MySQL 5.7.x Composer 1.x Laravel 5.6.x やること Laravelだけ、リポジトリ管理 前提 【コピペ】AWS Cloud9+Docker ComposeでLaravel環境を構築その弐で環境構築済み Laravelだけ、Gitリポジトリ管理する 現在の構成 ディレクトリ構成は、こんな感じ。 [docker] ← クローンして来た |-docker-compose.yml |-.git |-... |-src |-laravel ← コイツだけリポジトリ管理したい！ |-app |-... .gitがdockerディレクトリ直下にあるので、プッシュすると丸ごと（dockerディレクトリごと）行ってしまう。 $ pwd /home/ec2-user/environment/docker $ ls -al ・・・ drwxrwxr-x 8 ec2-user ec2-user 198 Apr 20 10:34 .git ・・・ docker/src/laravelだけプッシュしたい。 リポジトリの向き先を変える 早い話、.gitがdockerではなく、docker/src/laravelにあれば良い。 やる事 Git初期設定 リポジトリを用意 docker/.gitを削除 docker/src/laravelをバックアップ（以下、旧Laravel） docker/srcにリポジトリをクローン（以下、新Laravel） 旧Laravelを新Laravelにコピー 旧Laravelを削除 新Laravelをプッシュ Git初期設定 未設定なら、やっておく。 $ git config --global user.name "GitHubユーザー名" $ git config --global user.email GitHubメールアドレス リポジトリを用意 空っぽなリポジトリだと、クローンした時にYou appear to have cloned an empty repository.って警告が表示されるので、おっ！？ってなる。 READMEだけ追加しておけば気にならなくて良い。 docker/.gitを削除 $ pwd /home/ec2-user/environment/docker $ rm -fdR .git docker/src/laravelをバックアップ（以下、旧Laravel） $ pwd /home/ec2-user/environment/docker $ cd src $ ls laravel $ mv laravel laravel_bak $ ls laravel_bak docker/srcにリポジトリをクローン（以下、新Laravel） $ git clone <上記でコピーしたリポジトリURL> laravel 例）git clone https://github.com/bobtabo/cloud9-laravel.git laravel Cloning into 'laravel'... remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done. $ ls laravel laravel_bak 旧Laravelを新Laravelにコピー $ ls -l drwxrwxr-x 3 ec2-user ec2-user 35 Apr 21 17:30 laravel drwxrwxr-x 13 ec2-user ec2-user 4096 Apr 19 17:40 laravel_bak $ cp -pR laravel_bak/. laravel $ ls -l drwxrwxr-x 14 ec2-user ec2-user 4096 Apr 19 17:40 laravel drwxrwxr-x 13 ec2-user ec2-user 4096 Apr 19 17:40 laravel_bak 旧Laravelを削除 $ ls laravel laravel_bak $ rm -fdR laravel_bak $ ls laravel 新Laravelをプッシュ ブラウザをリロードすれば、プッシュされている。 Cloud9を開き直す時 セッション切れなどでCloud9を開き直したら、ディレクトリ選択し直す。