chocoの投稿 - Crieit

DockerでXdebugのインストールを失敗した場合

2020-03-04T22:44:48+09:00

DockerのコンテナにXdebugをインストールしようとして失敗した。
発生したエラーは以下の2点。

autoconfがインストールされていなかった
Cコンパイラがインストールされていなかった

実行環境

Docker 2.2.0.0
PHP 7.4
- php:7.4-fpm-alpine
Xdebug 2.9.2

その1 autoconfがインストールされていない

以下のようなエラーが表示された場合はautoconfがインストールされていない。

downloading xdebug-2.9.2.tgz ...
Starting to download xdebug-2.9.2.tgz (242,959 bytes)
..................................................done: 242,959 bytes
90 source files, building
running: phpize
Configuring for:
PHP Api Version:         20190902
Zend Module Api No:      20190902
Zend Extension Api No:   320190902
Cannot find autoconf. Please check your autoconf installation and the
$PHP_AUTOCONF environment variable. Then, rerun this script.

ERROR: `phpize' failed

この場合はapk add autoconfを実行してインストールすればよい。

その2 コンパイラがインストールされていない

以下のようなエラーが表示された場合はコンパイラのインストールがされていない。

downloading xdebug-2.9.2.tgz ...
Starting to download xdebug-2.9.2.tgz (242,959 bytes)
..................................................done: 242,959 bytes
90 source files, building
running: phpize
Configuring for:
PHP Api Version:         20190902
Zend Module Api No:      20190902
Zend Extension Api No:   320190902
building in /tmp/pear/temp/pear-build-defaultuserhmhpmF/xdebug-2.9.2
running: /tmp/pear/temp/xdebug/configure --with-php-config=/usr/local/bin/php-config
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for a sed that does not truncate output... /bin/sed
checking for pkg-config... no
checking for cc... no
checking for gcc... no
configure: error: in `/tmp/pear/temp/pear-build-defaultuserhmhpmF/xdebug-2.9.2':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details
ERROR: `/tmp/pear/temp/xdebug/configure --with-php-config=/usr/local/bin/php-config' failed

この場合はapk add gcc g++ makeを実行してインストールすればコンパイルが可能になる。

また、apk add build-baseの実行でも必要なパッケージのインストールが行える。
build-baseは以下7つのパッケージをインストールする。

binutils
file
fortify-headers
g++
gcc
libc-dev
make

参考

php-alpineコンテナにxdebugをインストールする時にハマったメモ - Qiita

FormRequestのバリデーション失敗時にjsonを返す

2020-03-02T17:00:28+09:00

以下どちらかの実装でjsonレスポンスにできる。

failedValidation()をオーバーライドする
ヘッダーにAcceptまたはX-Requested-Withを追加する

Laravelのバージョンは6.15.0です。

`failedValidation()`のオーバーライド

フォームリクエストクラスのfailedValidation()をオーバーライドすることでjsonレスポンスかつメッセージをカスタマイズすることも可能。以下はサインアップのエンドポイントを想定したリクエストの例。

 'required',
            'password' => 'required'
        ];
    }

    public function messages()
    {
        return [
            'user_id.required' => 'ユーザーIDは必須です。',
            'password.required' => 'パスワードは必須です。',
        ];
    }

    protected function failedValidation(Validator $validator)
    {
        throw new HttpResponseException(
            response()->json([
                'message' => $validator->errors()->toArray(),
            ], 403)
        );
    }
}

ヘッダーに`Accept`または`X-Requested-With`を追加する

エクセプションハンドラを変更していない場合、バリデーションエラー発生時はIlluminate/Foundation/Exceptions/Handler::render()でレスポンス生成が行われる。

    // Illuminate/Foundation/Exceptions/Handler.php
    public function render($request, Exception $e)
    {
        if (method_exists($e, 'render') && $response = $e->render($request)) {
            return Router::toResponse($request, $response);
        } elseif ($e instanceof Responsable) {
            return $e->toResponse($request);
        }

        $e = $this->prepareException($e);

        if ($e instanceof HttpResponseException) {
            return $e->getResponse();
        } elseif ($e instanceof AuthenticationException) {
            return $this->unauthenticated($request, $e);
        } elseif ($e instanceof ValidationException) {
            return $this->convertValidationExceptionToResponse($e, $request);
        }

        return $request->expectsJson()
                    ? $this->prepareJsonResponse($request, $e)
                    : $this->prepareResponse($request, $e);
    }

今回はバリデーションエラーの場合なのでconvertValidationExceptionToResponse()が実行される。

    // Illuminate/Foundation/Exceptions/Handler.php
    protected function convertValidationExceptionToResponse(ValidationException $e, $request)
    {
        if ($e->response) {
            return $e->response;
        }

        return $request->expectsJson()
                    ? $this->invalidJson($request, $e)
                    : $this->invalid($request, $e);
    }

expectsJson()はヘッダにX-Requested-With: XMLHttpRequestが含まれているか、ヘッダにAccept: .../jsonもしくはAccept: ...+jsonが含まれている場合にjsonレスポンスを返却する。

そのためミドルウェアでヘッダを追加することでjsonレスポンスが取得できる。

headers->set('Accept', 'application/json');
        return $next($request);
    }
}

 [
            \App\Http\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            // \Illuminate\Session\Middleware\AuthenticateSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            \App\Http\Middleware\VerifyCsrfToken::class,
            \Illuminate\Routing\Middleware\SubstituteBindings::class,
        ],

        'api' => [
            'throttle:60,1',
            \Illuminate\Routing\Middleware\SubstituteBindings::class,
            \App\Http\Middleware\EnforceJson::class, // 追加
        ],
    ];

    // ...
}

個人的には返却するメッセージを変更できるのでfailedValidation()をオーバーライドするほうが好みです。

参考

【Laravel】Eloquent Tips

2019-06-30T11:52:44+09:00

Eloquentを使う際にちょっと便利になるTipsをまとめてみました。
網羅性はないので参考程度に。

テーブル名の変更

$tableを定義することで任意のテーブルへのアクセス出来ます。



主キー名の変更

$primaryKeyを定義して変更することが可能です。



主キーの型を変更する

$keyTypeを定義して変更することが可能です。



主キーのインクリメントをしないようにする

$incrementingを定義して変更することが可能です。



デフォルトのタイムスタンプを使用しないようにする

$timestampsを定義することでデフォルトのタイムスタンプを使用しなくなります。



詳細はIlluminate\Database\Eloquent\Concerns\HasTimestampsを参照してください。

タイムスタンプのカラム名を変更する

モデルクラスにCREATED_AT、UPDATED_ATを定義することで変更できます。



タイムスタンプのプロパティからCarbonのメソッドを実行

次のようなマイグレーションを作成します。

bigIncrements('id');
            $table->string('text');
            // created_at, updated_atカラムが追加されます。
            $table->timestamps();
        });
    }

    public function down()
    {
        Schema::dropIfExists('sample');
    }
}


モデルクラスをSampleとした時、次のような実行が可能です。

created_at->diffForHumans();
    }
}


created_at、updated_atにアクセスすると、Carbonオブジェクトに変換してくれています。

そのため、diffForHumansなどのメソッドが呼び出せます。

詳細はIlluminate\Database\Eloquent\Concerns\HasAttributesを参照してください。

また、独自にCarbonオブジェクトで受け取りたいカラムを設定したい場合は$datesを定義することで可能です。



参考


Eloquent: Getting Started - Laravel - The PHP Framework For Web Artisans
Eloquent: Mutators - Laravel - The PHP Framework For Web Artisans



ボトムアップDDDを写経した
2018-09-29T18:37:56+09:00
まえがき

最近、通勤の合間などにIDDDを読んで少しづつDDDの知識を取り入れている。ユビキタス言語や境界づけられたコンテキストなど、概念的な定義が個人的に難しくて読むのに時間がかかっている。

そんな時にnrsさんのブログに書かれている、ボトムアップドメイン駆動設計を読んだ。理解や実践が難しい箇所はひとまず置いておき、理解しやすく実践しやすい箇所からまず始めてみようという内容だ。

自分にぴったりだと思って一通り読んだ後、せっかくなのでPHPとLaravelを使って写経をしてみた。一通り書いてみた感想としては、OOPの特性を活かしたコーディングとはこういうことなんだなとふんわり掴め、責務の所在が明確だとファイルが増えても処理が追いやすいなと感じた。

参考にした記事で扱われているものは次の5つ。どれも技術的な要素なので、普段コードを書いている人にとっては読みやすいと思う。


値オブジェクト
エンティティ
ドメインサービス
リポジトリ
アプリケーションサービス


また、サンプルとは異なる実装をしている箇所を以下で補足する。

変更点

コンストラクタ

PHPは__construct()を複数定義出来ない。そのため、今回はデフォルト引数を用いて実装を行った。

id = $id === null ? new UserId(Util::guid()) : $id;
        $this->userName = $userName;
        $this->fullName = $fullName;
    }

    // 以下の処理は省略...
}


ただ、必ず引数で受け取る$userNameと$fullNameを引数としたコンストラクタを定義し、2つの引数に合わせて$idと3つを引数に受け取る静的メソッドを定義すれば擬似的に複数定義することも出来なくはない。

id = new UserId(Util::guid());
        $this->userName = $userName;
        $this->fullName = $fullName;
    }

    public static function ctorWithId(
        UserName $userName,
        FullName $fullName,
        UserId $id
    ) {
        $instance = new self($userName, $fullName);
        $instance->id = $id;
        return $instance;
    }

    // 以下の処理は省略...
}


個人的な意見としては、生成処理のパターンが増えたり、複雑であればファクトリを用意すれば良いのかなという解釈でいる。

等価性の判定

C#やJavaのObjectクラスにはequals()というメソッドが定義されており、等価の判別が出来る。これもPHPには用意されていないので、汎用的なメソッドとして用意し、インターフェースを実装した。





リポジトリ

Laravelを使用したということもあり、学習も兼ねてEloquentを用いて実装した。

userEloquent = $userEloquent;
    }

    /**
     * @param UserId $userId
     * @return User|null
     */
    public function findByUserId(UserId $userId)
    {
        $target = $this->userEloquent->find($userId->value());

        if ($target === null) {
            return null;
        }

        return new User(
            new UserName($target->user_name),
            new FullName($target->first_name, $target->family_name),
            $userId
        );
    }

    /**
     * @param UserName $userName
     * @return User|null
     */
    public function findByUserName(UserName $userName)
    {
        $target = $this->userEloquent->findByUserName($userName);

        return $target;
    }

    /**
     * @return User[]
     */
    public function findAll()
    {
        $users = $this->userEloquent
            ->all()
            ->map(function (UserEloquent $userEloquent) {
                return new User(
                    new UserName($userEloquent->user_name),
                    new FullName(
                        $userEloquent->first_name,
                        $userEloquent->family_name
                    ),
                    new UserId($userEloquent->id)
                );
            })->toArray();

        return $users;
    }

    public function save(User $user)
    {
        $this->userEloquent->persist($user);
    }

    public function delete(UserId $userId)
    {
        $this->userEloquent->deleteByUserId($userId);
    }
}


あとがき

正直なところ、読む前はリポジトリやエンティティを用いてDDDしてみたというような記事をみかけては、「それって〇〇アーキテクチャを適用しただけでは…？」と思っていた。でも実際書いてみると、かなり歯ごたえがあって実装したときの達成感のようなものがあったので、書きたくなるのもわかるなぁという感じ。こうして自分も記事にしているので。

ただ参考記事や書籍にも書かれているように、ユビキタス言語や境界づけられたコンテキストなどの概念がより重要であり、技術的な側面だけを注力するといわゆる軽量DDDに陥ってしまうので、戦略的設計に関わる知識もインプットしていく。


  軽量DDDとは、DDDの戦術的パターンの一部だけをつまみ食いする方法で、ユビキタス言語を見つけ出して育てていこうなどという気は毛頭ない。おまけにこの手法は、境界づけられたコンテキストやコンテキストマッピングも使わずに済ませることが多い。技術面だけに注目して、技術的な問題だけを解決したがっているのだ。この方法にはメリットもあるが、戦略的モデリングを併用したときのような大きな見返りは得られない。（実践ドメイン駆動設計より）


最後に写経したものはGitHubに置いているので、参考になれば。

[https://github.com/chocol4t/bottom-up-ddd-php:embed]

nrsさんのサンプルコードはこちら。(C#)

[https://github.com/nrslib/BottomUpDDD:embed]

参考URL


ytake/valueobjects


Utilクラスを参考にしました。




AngularのプロジェクトをGithub Pagesに公開する
2018-07-11T13:04:02+09:00
Crieit初投稿です。元記事はこちら

AngularのプロジェクトをGithub Pagesにデプロイしたときのメモ。

angular-cli-ghpagesというパッケージを使用することで簡単にデプロイ出来た。

インストール

コマンドの利用するには、次の条件を満たしておく必要がある。


Node.js: 4.x以上
Git: 1.7.6以上
（オプション）angular-cliで作成されたプロジェクト


今回実行した環境は次の通り。


MacBook Air (Early 2015)
macOS High Sierra (10.13.5)
angular-cli: 6.0.7
Node.js: 8.11.2
Git: 2.17.1


使い方

angular-cli v6だと、ビルド時のディレクトリ構成がdist/REPOSITORY_NAMEとなっている。

そのため、ng buildもしくはangular-cli-ghpagesでディレクトリを指定する必要がある。

今回はangular-cli-ghpagesのオプションを使用した。

ng build --prod --base-href "https://USERNAME.github.io/REPOSITORY_NAME/"
angular-cli-ghpages --dir="dist/REPOSITORY_NAME"


もしくは、

ng build --prod --base-href "/REPOSITORY_NAME/"
angular-cli-ghpages --dir="dist/REPOSITORY_NAME"


もしくは、

# <base href="">となる
ng build --prod
angular-cli-ghpages --dir="dist/REPOSITORY_NAME"


を実行すると、リモートへプッシュが行われる。

angular-cli-ghpagesの代わりにnghでも実行可能。

オプション

コマンド実行時にいくつかオプション設定が可能。

使用したものだけ記載しているので、他のオプションについてはREADME.mdを参照してください。

--message


コミット時のメッセージを設定。デフォルトはAuto-generated commit
e.g. ngh --message="New message"


--dir


デプロイするディレクトリを設定。デフォルトはdist
angular-cli v6だと"outputPath": "dist/REPOSITORY_NAME"となっているので注意
e.g. ngh --dir="dist/REPOSITORY_NAME"


--branch


プッシュ先のブランチ名を設定。デフォルトはgh-pages
e.g. ngh --branch=other-branch


Gihub Pagesの設定

nghでプッシュされたのが確認出来れば以下を設定する。


GithubのリポジトリのSettingsタブをクリック。
Github Pagesの項目までスクロールし、Sourceからプッシュしたブランチを設定。
URLにアクセスしてページが表示されれば完了！


参考URL


angular-schule/angular-cli-ghpages
Angular アプリケーションを GitHub Pages で公開する方法 - Qiita

chocoの投稿 - Crieit

DockerでXdebugのインストールを失敗した場合

FormRequestのバリデーション失敗時にjsonを返す

failedValidation()のオーバーライド

ヘッダーにAcceptまたはX-Requested-Withを追加する

【Laravel】Eloquent Tips

ボトムアップDDDを写経した

AngularのプロジェクトをGithub Pagesに公開する

`failedValidation()`のオーバーライド

ヘッダーに`Accept`または`X-Requested-With`を追加する