こんにちは！
今回の内容は前回の続きになります。

まだ見てない方は是非こちらの方もご参照ください！
LaravelでMySQLにログインするまで

それでは本題に入っていきます。

開発環境

macOS Big Sur 11.0.1
composer 2.0.7
Laravel Framework 8.13.0
PHP 7.3.22
MySQL 8.0.22

データベースを作成する

前回の続きであるMySQLにログインした状態でターミナルから

mysql> show databases;

と入力すると、

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
4 rows in set (0.01 sec)

このように表示されます。

次にデータベースを作成するコマンド

mysql> CREATE DATABASE `laravel_test`;

と入力すると

Query OK, 1 row affected (0.01 sec)

ちゃんとデータベースが作成できたようです。

show databases(); で確認してみると、、、

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| laravel_test       |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.00 sec)

laravel_testが新たに追加されてデータベースが作成できていることがわかります。

データベースに接続する

ターミナルでphp artisan tinkerと入力すると、

Psy Shell v0.10.4 (PHP 7.3.22-(to be removed in future macOS) — cli) by Justin Hileman
>>>

と表示されました。
ここでデータベースに接続するコマンドDB::connection();を入力します。

>>> DB::connection();
=> Illuminate\Database\MySqlConnection {#3326}

これで前回、.envファイルやdatabase.phpファイルで入力したデータベースに接続できました！

---

この先はマイグレーションファイルを実行すればテーブルを作成することができます。

マイグレーションやテーブル作成がわからない方は続きも読んでみてください！

こんにちは、くりぱんです。

この記事で実現できること

• GithubからCloneする
• GithubからLaravelプロジェクトをCloneした後の、開発環境の構築

開発環境

• OS：MacOS
• フレームワーク：Laravel
• バージョン管理ツール：Git
• Github

説明

LaraveのプロジェクトをGithubからCloneしただけだと、vendarディレクトリや.envファイルがなく、php artisan serveしてもエラーが出て、実際に開発できる環境にはありません。
今回は、Laravelのプロジェクトに参画して、GithubからCloneしたけど、どうしたらいいの！っていう人向けに、どうやって開発環境を整えるのかを説明していこうと思います。

実装の流れ

1. GithubからClone
2. composer install
3. .envの作成
4. データベース設定

実装

GithubからClone

まずは、Laravelのプロジェクトをクローンしたい場所にターミナルでcdコマンドを実行して移動しておきましょう！
今回は、/Applications/MAMP/htdocs配下にクローンしていきます。
皆さんは自由な場所にクローンしてくださいね！

$ cd /Applications/MAMP/htdocs/

次に、Githubからのクローンです。ターミナルで下記のコマンドを実行しましょう。

$ git clone LaravelプロジェクトURL

これでLaravelプロジェクトが先程cdコマンドで移動したディレクトリにクローンされています。

composer update or composer install

クローンしてきたLaravelプロジェクトを見てみると、vendarディレクトリが無いことがわかります。
なので、作っちゃいましょ！
まずはcdコマンドでLaravelプロジェクトディレクトリまで移動しましょう。

$ cd Laravelプロジェクトディレクトリ

それが終わったら、vendarディレクトリを作っていきます。

$ composer install

これでphp artisan serveをすると、サーバーは起動します。

.envの作成

次に、.envを作成していきましょう。
これがないと、500エラーなどがでて全くサイトを確認できないですからね！
実は、すでに.envの元となるファイルは存在するので、それをコピーするだけなんです。
なので、以下のコマンドを実行してください！

$ cp .env.example .env

次に、.envの中のAPP_KEYを発行します。

$ php artisan key:generate

このAPP_KEYは、暗号化やパスワードリセット等のセキュリティーでとても大事な役割を担っています。

そして、下記のコマンドで念の為キャッシュをクリアしておきましょう！

$ php artisan config:clear

これで、.envの設定はOKです。
現場などで、他に.envの設定がある場合は設定しましょう！

データベース設定

データベースが必要な場合は、下記のコマンドたちも実行していきましょう！

$ php artisan migrate

seederファイルもある場合は、下記のコマンドを実行してください。

$ php artisan db:seed

ReflectionException : Class 〇〇 does not existやclass 〇〇 not foundなどのエラーが出た場合は、下記のコマンドでオートロードの定義をしましょう。

$ composer dump-autoload

それが終わったら、再マイグレーションとシーダーの実行をしましょう。

$ php artisan migrate:refresh --seed

ブラウザで確認して、問題なければOKです。

最後に

今回は、LaravelプロジェクトをGithubからcloneしたはいいけど、その後がわからない！サーバー立ち上がらないし、変なエラーでる！っていう時の備忘録でした。
当記事を、最後まで見ていただきありがとうございました。！

Twitterもやってます！
プログラミングや金融知識についてやエンジニアの現実についてつぶやいています！
よかったら見てみてくださいね！

https://twitter.com/sakuslife

PHPのバージョンが7.2だった

laravel new を実行するとPHP7.3以上じゃなければならないと表示された。

php -vでバージョンを確認すると7.2になっている。

そこで以下のコマンドでインストールできるPHPのバージョンを確認。

brew search php@7

で確認後インストール

brew install php@7.4

そしてパスを通してphp -vをすると...

変わってない

which phpでphpの場所を確認するとxamppの中になっている。
そしてxamppの中のphpのバージョンが7.2になっていたことがわかった。
つまりHombrewでusr/localに7.4はインストールしてあるが、xamppをインストールしたときのphpが優先的に使われている？

環境変数を書き換える、あるいはxamppのphpをアップデートするなどいくつかの方法を考えてみた。
が、後々apacheを使う際に影響が出そうだと考えたので今は別方法で解決を試みた

Composer経由でLaravelアプリケーション作成

以下のコマンドでアプリケーション作成。

composer create-project laravel/laravel プロジェクト名 --prefer-dist

現象

新規に別プロジェクトを作成しようとしたら、元からあったほうのプロジェクトが502 bad gatewayエラーになってしまった。

心当たり

$ vagrant up --provision
を実行してしまったのが原因？初期化してしまったかもしれない。

やったこと

・元々のプロジェクトまで移動してls　→　ソースファイルは無事
・Homestead.yamlファイルのsites:にphp: "7.2"を追加　→　効果なし
・nginx.confの中身を見る（下のコマンド実施）　→　問題なし

cd /etc/nginx
cat nginx.conf

原因

homestead.testの中身を確認したら原因が分かった
（homestead.test＝Homestead.yamlファイルのsites:のmap）

cd /etc/nginx/sites-available/
cat homestead.test

location ~ .php$ {…　で下記のようになっていた。ここが原因だった。

fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;

下記コマンドを実行してphpの稼働状況を確認すると、稼働しているのは7.1と7.2だったので7.3→7.2に修正したい。
稼働していないものを設定にしていたため、サービスが見つけられず502 bad gatewayエラーになっていた様子

service --status-all | grep php

ログの一部.

vagrant@homestead:/var/log/nginx$ service --status-all | grep php
 [ + ]  php7.1-fpm
 [ + ]  php7.2-fpm

解決

// 移動して
cd /etc/nginx/sites-available/
// 編集する
sudo vi homestead.test

fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;を
fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;に直す
（iで編集モード、:wqで保存して終了）

保存したら再起動

sudo service nginx restart

ページを更新すると正常に表示された！

検索条件が引き継がれない問題発生

検索機能を実装して、ページネーションで次のページに遷移したとき検索条件が引き継がれない
問題が発生して解決したので記事にしました。

検索をかけて、URLを確認すると,下記のように表示されています。

category_id=1&page=1
//検索フォームで検索した結果

そして、2ページ目に遷移すると、

page=2
//ページ遷移した結果

あ、category_id=1が消えていました。
現状、bladeのページネーションのコードを確認すると下記のように設定されています。

 
{{ $projects->links() }}

下記のように変更すると、ページ遷移してもcategory_id=1&page=2
のように引き継がれました。

 
{{ $projects->appends(request()->input())->links() }}

参考記事

https://blog.dododori.com/create/program/laravel-search-page/

今回はLaravelでMySQLにログインするまでを説明します！

開発環境

macOS Big Sur 11.0.1
composer 2.0.7
Laravel Framework 8.13.0
PHP 7.3.22
MySQL 8.0.22

.envの編集

.envファイルの編集をしていきます

.env(編集前)

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=root
DB_PASSWORD=

DB_DATABASE,DB_USERNAME,DB_PASSWORDをそれぞれ変更、修正します。(名前は適宜変更してください)

.env(編集後)

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel_test
DB_USERNAME=test_user
DB_PASSWORD=pass

今回はこのように設定しました。

config/database.phpの編集

.envファイルの編集に伴い、database.phpのファイルも修正します。

database.php(編集前)

'mysql' => [
    ~~~
    'database' => env('DB_DATABASE', 'forge'),
    'username' => env('DB_USERNAME', 'forge'),
    'password' => env('DB_PASSWORD', ''),
    ~~~
],

database.php(編集前)

'mysql' => [
    ~~~
    'database' => env('DB_DATABASE', 'laravel_test'),
    'username' => env('DB_USERNAME', 'test_user'),
    'password' => env('DB_PASSWORD', 'pass'),
    ~~~
],

それぞれ.envファイルに設定した値を入力してください。

MySQLにログインする

以上で準備が整ったので、データベースに接続します。
ターミナルを開いてプロジェクトルートディレクトリに移動して下記を入力してください。

mysql -uroot

すると、

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 9
Server version: 8.0.22 Homebrew

Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> 

と表示されました！

---

次はデータベースを作成し、接続するところまで説明するので是非、続きも読んでみてください。
Laravelでデータベース(MySQL)を作成し、接続をする。

はじめに

この記事はLaracastsという動画学習プラットフォームの講座シリーズ「Whip Monstrous Code Into Shape」の下記エピソードをまとめたものです。
「God Object Cleanup #1: Pass-Through」
「God Object Cleanup #2: Traits and Socks」
「God Object Cleanup #3: Value Objects」

この講座シリーズの内容がめちゃくちゃ素晴らしくて、動画だと見返すのが面倒なので文章にまとめようと思ったのがきっかけです。すべての権利はLaracastsおよび動画作者のJeffery Wayさんに帰属します。また、以降の記述はJeffery Wayさんの主張を自分なりに解釈したもので、私個人の考えではないということにご注意ください。

ゴッドオブジェクトとは

wikipediaによると

In object-oriented programming, a God object is an object that knows too much or does too much. The God object is an example of an anti-pattern.
訳：オブジェクト指向プログラミングにおけるゴッドオブジェクトとは、多くを知りすぎていたり、多くのことをやりすぎているオブジェクトのことで、アンチパターンの一例である。

例えば1つのクラス、よくあるのがUserクラスにビジネスロジックを全部書いちゃってメソッドやプロパティが膨大に膨れ上がっているようなやつですね。

前提例

Laracastsのように、登録したユーザーが動画を視聴できる有料システムを開発中だとします。

ケース1

「よし、ユーザーがお気に入りした動画数や、視聴完了済みの動画数、視聴途中の動画数を取得できるようにしよう」

User.php

<?php

namespace App;

use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
    .
    .
    .

    public function favoritesCount()
    {
        return 15;
    }

    public function completionsCount()
    {
        return 100;
    }

    public function experience()
    {
        return 123456;
    }
}

上記3つのメソッドで終わるなら問題ありませんが、そんなはずはなく…。ロジックをUser.phpに集約させようとすると、このクラスはすぐに膨れ上がってしまいます。

対処法1. Pass-Throughパターン

上記メソッドはすべて統計に関するものなので、新たにStatsクラスを作成し、それを返すメソッドを作ります。元々あったメソッドはStatsクラスにまとめて移しましょう。

User.php

<?php

namespace App;

use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
    .
    .
    .
    public function stats()
    {
        return new Stats($this);
    }
}

移動したメソッド名の...Countは冗長になるので消します。

Stats.php

<?php


namespace App;


class Stats
{

    /**
     * Stats constructor.
     */
    public function __construct(User $user)
    {
        $this->user = $user;
    }

    public function favorites()
    {
        return 15;
    }

    public function completions()
    {
        return 100;
    }

    public function experience()
    {
        return 123456;
    }
}

これで$user->stats($user)->favorites() // 15というようにアクセスできるようになりました。

ケース2

「ユーザーのビデオ視聴状態に関するロジックを追加したい！」

「リレーションを取得したり、参照して視聴状態を完了、未完了にしたりするメソッドを追加しよう。」

User.php

<?php

namespace App;

use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
    .
    .
    .

    public function completions()
    {
        // completionsリレーションを取得
    }

    public function complete()
    {
        // リレーションを参照して項目を完了とする
    }

    public function uncomplete()
    {
        // リレーションを参照して項目を未完了とする
    }

}

「あー、あとはビデオ視聴済みかどうかの判定と、動画視聴ページでスレッドを開始する処理、返信をする処理も追加しなきゃ」

User.php

    .
    .
    .
    public function completed(Video $video)
    {
        // ビデオ視聴済みか判定
    }

    public function startConversation(Conversation $conversation)
    {
        // 現在のユーザー向けに新しいスレッドを作成
    }

    public function replyTo(Conversation $conversation, Reply $reply)
    {
        // スレッド内で返信を追加
    }

早速クラスが大きくなる予感がしてきましたね。

対処法2. Traitを使う

同じようなロジックはtraitに移してみましょう。完了状態に関するロジックをまとめるため、Completable traitを作成します。

Completable.php

<?php


namespace App;


trait Completable
{
    public function completions()
    {
        // completionsリレーションを取得
    }

    public function complete()
    {
        // リレーションを参照して項目を完了とする
    }

    public function uncomplete()
    {
        // リレーションを参照して項目を未完了とする
    }

    public function completed(Video $video)
    {
        // ビデオ視聴済みか判定
    }

}

同じように、残り二つのメソッドはフォーラム関係のメソッドなのでParticipatesInForum traitを作成して移しましょう。

ParticipatesInForum.php

<?php


namespace App;


trait ParticipatesInForum
{
    public function startConversation(Conversation $conversation)
    {
        // 現在のユーザー向けに新しいスレッドを作成
    }

    public function replyTo(Conversation $conversation, Reply $reply)
    {
        // スレッド内で返信を追加
    }
}

User.phpで作成したtraitを使用しましょう。

User.php

<?php

namespace App;


use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
    use Completable;
    use ParticipatesInForum;
    .
    .
    .

}

Userクラスがすっきりしましたね！
動画内でJefferyさんは、もしほかの場所で使われないとしてもTraitsを使うのはありだと主張しています。Traitを使って似たようなロジックをまとめることは、物が散らかった部屋でジャンル分けした箱の中に物を振り分けて片付けるようなものだと考えています。

ケース3

「収益関連の処理を追加しよう！」

「収益を出すメソッドと、数値をドル表示に整形するメソッドを追加して、と」

Performance.php

<?php


namespace App;

use Illuminate\Database\Eloquent\Model;


class Performance extends Model
{
    .
    .
    .
    public function revenue()
    {
        return $this->revenue; // 8600
    }

    public function revenueInDollars()
    {
        return $this->revenue() / 100; //86
    }

    public function revenueAsCurrency()
    {
        return money_format('$%i', $this->revenueInDollars()); // $86.00
    }

}

早速revenueに関するロジックが増えてきました。

対処法3. 値オブジェクトを使う

上記のケースでは、全てのメソッドにはrevenueという接頭辞がついており、revenueという値を操作する処理であるということが共通しています。この場合、revenueに振る舞いを持たせることは有効に作用するので、値オブジェクトを使ってみましょう。

ただし、値オブジェクトは作成する意味があるときにだけ使いましょう。DDDでなんでもかんでもプリミティブを値オブジェクトにする人がいますが、それほどばかげたことはありません。

ただしRevenueVOとかRevenueValueObjectとか命名するのはやめましょう。Revenueとするのが本来あるべき姿です。

Revenueクラスを作成したら、先ほどのメソッド（revenue()以外）をこちらに移し、メソッド名も適したものに変更します。

Revenue.php

<?php


namespace App;


class Revenue
{
    private $revenue; // Immutableにする

    /**
     * Revenue constructor.
     */
    public function __construct($revenue)
    {
        $this->revenue = $revenue;
    }

    public function inDollars()
    {
        return $this->revenue() / 100; //86
    }

    public function asCurrency()
    {
        return money_format('$%i', $this->inDollars()); // $86.00
    }

}

さあ、値オブジェクトを作ったら、どうやってアクセスすれば良いでしょうか？

$performance->revenueこんな感じでアクセスしたいわけです。

今のままだと、上記のやり方では8600を取得するだけです。正解はこうです。

Performance.php

<?php


namespace App;

use Illuminate\Database\Eloquent\Model;


class Performance extends Model
{
    public function getRevenueAttribute($revenue)
    {
        return new Revenue($revenue);
    }

}

Eloquentのカスタムアクセサ―によって、revenueプロパティにアクセスしようとしたときに、getRevenueAttribute($revenue)メソッドが定義されている場合、同メソッドを呼び出してくれます。上記の場合、Revenueインスタンスを返してくれるというわけです。

これで、$performance->revenue->asCurrency //$86.00 こんな風にアクセスすることができるようになります。

また、もしecho $performance->revenue->asCurrency とやって出力しようとすると、型が異なるのでエラーになります。文字列として出力した場合は__toString()メソッドを定義してあげましょう。そうすると、文字列としてアクセスしようとした場合の処理を定義することができます。

Performance.php

   .
   .
   .
   public function __toString()
   {
       return (string) $this->asCurrency();
   }

おわりに

以上、いかがでしたでしょうか。
Jeffery Wayさんの「Whip Monstrous Code Into Shape」では、他にもMonstrousなコードを綺麗にするためのテクニックがたくさん紹介されています。時間ができたら都度参考になった他のエピソードもまとめようと思います。

間違っているところなどありましたら是非是非ご指摘お待ちしております！