「違いはわかったけど、実際の開発でどう役立つの？」

そう思った方もいるかもしれません。 実は、この使い分けを徹底すると、「運用の楽さ」 が劇的に変わるんです！

今回は実践編として、「例外の種類によって、Slack通知やエラー画面を自動で振り分ける方法」 をご紹介します。

すべてのエラーを通知していませんか？

開発現場でよくあるのが、「エラーが出たら全部Slackに通知！」という運用。 これ、最初はいいんですが、だんだんこうなりませんか？

• 深夜に「DB接続タイムアウト」の通知が来て叩き起こされる（でも数秒後に自然復旧してる）

• 通知が多すぎて、本当に重要なバグ報告を見逃す

• 結果、「通知チャンネル誰も見なくなる」 現象が発生…

これは、「バグ（緊急）」 と 「環境トラブル（要確認）」 を混ぜてしまっているのが原因です。

「型」で振り分ける実装パターン

ここで、前回の知識が活きてきます。 例外ハンドラー（エラーを一元管理するクラス）で、以下のように振り分けてみましょう。

use Psr\Log\LoggerInterface;

class AppExceptionHandler
{
    public function __construct(
        private LoggerInterface $logger,
        private SlackNotifier $slack
    ) {}

    public function handle(\Throwable $e): void
    {
        // パターン1：LogicException / DomainException
        // 意味：「コードがおかしい（バグ）」
        if ($e instanceof \LogicException) {
            // これは緊急事態！開発者にすぐ知らせる
            $this->logger->critical($e->getMessage());
            $this->slack->send("🚨 緊急: 実装バグが発生！すぐ直して！: " . $e->getMessage());
            
            // ユーザーには「システムエラー」とだけ表示
            $this->renderErrorPage(500);
            return;
        }

        // パターン2：RuntimeException
        // 意味：「外部要因で失敗（環境エラー）」
        if ($e instanceof \RuntimeException) {
            // ログには残すけど、深夜に叩き起こすほどではないかも
            $this->logger->error($e->getMessage());
            
            // ユーザーには「現在混み合っています」など、やんわり伝える
            $this->renderErrorPage(503);
            return;
        }

        // その他の予期せぬエラー
        $this->logger->error('Unknown Error: ' . $e->getMessage());
        $this->renderErrorPage(500);
    }
}

この設計のメリット

こうすることで、開発チームの動き方が変わります。

1. Slack通知が来たら「即対応」

   • LogicException だけが通知されるので、「通知 = 自分のコードミス」と認識できます。

2. ログが綺麗になる

   • 一時的な接続エラーなどはログファイルに溜まるだけなので、精神衛生上とても良いです（もちろん定期的なチェックは必要ですよ！）。

3. ユーザーへの案内が親切になる

   • バグなら 500、アクセス過多なら 503 と、状況に合わせたHTTPステータスコードを返せます。

例外処理は「未来の自分」へのメッセージ

例外クラスを使い分けることは、単なるルールではありません。

• LogicException を投げるときは、「これバグだから絶対直してね！」というメッセージ。

• RuntimeException を投げるときは、「運用でカバーしてね」というメッセージ。

この意図を込めてコードを書けるようになると、一人前のエンジニアへまた一歩近づけます。 「エラーハンドリング」という地味な部分ですが、こここだわるとカッコいいですよ！

ぜひ、自分たちのプロジェクトにも導入できないか検討してみてくださいね。

「全部 Exception クラスを使っちゃってるけど、これっていいの？」

PHPを勉強し始めて少し経つと、こんな悩みが出てきませんか？ 実は、僕も最初はそうでした。

でも、「例外の型（種類）」 を適切に使い分けるだけで、コードの品質がグッと上がり、バグの原因究明が驚くほど早くなるんです。

今回は、PHPの標準例外（SPL）の中でも特に重要な LogicException、DomainException、RuntimeException の3つについて、「現場ではどう使い分けているのか」 を解説していきます！

なぜ使い分ける必要があるの？

結論から言うと、「誰のせいなのか」 をはっきりさせるためです。

エラーが起きたとき、それが「プログラマーのミス（バグ）」なのか、「運悪くサーバーが落ちた（環境要因）」のかによって、対応方法は変わりますよね？

• バグなら → コードを修正しないといけない

• 環境要因なら → リトライしたり、ユーザーに「混み合ってます」と伝えたりする

これをクラスの型で表現するために、使い分けが必要なんです。

LogicException（ロジック例外）

「これは開発者のミス！ コードを直して！」

これは、「プログラムの論理がおかしい」ときに投げる例外です。 基本的に、本番環境でこれが出たらアウト。即修正案件です。

例えば、「APIキーをセットしていないのに、リクエストを送ろうとした」みたいなケースですね/p>

class ApiClient
{
    private ?string $apiKey = null;

    public function setApiKey(string $key): void
    {
        $this->apiKey = $key;
    }

    public function request(): void
    {
        if ($this->apiKey === null) {
            // 開発者がセットアップ手順を間違えているため、LogicException
            throw new \LogicException('API Keyが設定されていません。request()の前にsetApiKey()を呼んでください。');
        }

        // リクエスト処理...
    }
}

この例外が出たら、catch して握りつぶすのではなく、コード自体を直しましょう。

2. DomainException（ドメイン例外）

「そのデータ、仕様としてありえないよ！」

これは LogicException の親戚みたいなものです。 「ロジックは動くけど、渡されたデータがビジネスルール（仕様）としてありえない」場合に使います。

例えば、「信号機の色」を扱うクラスがあったとして、「紫」を指定されたら困りますよね？

class TrafficLight
{
    private const ALLOWED_COLORS = ['red', 'yellow', 'blue'];

    public function __construct(private string $color)
    {
        if (!in_array($color, self::ALLOWED_COLORS, true)) {
            // 定義外の値がコードから渡された！
            throw new \DomainException("色 '{$color}' は信号機に存在しません。");
        }
    }
}

ユーザーの入力ミスというよりは、「コード上で変な値を渡してしまった」ときに検知するためのものです。

3. RuntimeException（実行時例外）

「コードは合ってるけど、環境のせいで失敗しました…」

一番よく使うのがこれです。 コードは正しいけれど、「DBに繋がらない」「ファイルがない」「外部APIが落ちてる」 といった、実行時の状況（Runtime）によって起きるエラーです。

class ConfigLoader
{
    public function load(string $filePath): array
    {
        if (!file_exists($filePath)) {
            // パスは合ってるはずだけど、ファイルが消えてる（実行時の事情）
            throw new \RuntimeException("設定ファイルが見つかりません: {$filePath}");
        }
        
        // 読み込み処理...
    }
}

このエラーが出たときは、try-catch で捕まえて「ただいま混み合っております」のようなエラー画面を出してあげる必要があります

まとめ

• Logic / Domain 系

  • 意味：「コードのバグ」

  • 対応：コードを修正する（Catchして無視しちゃダメ！）

• Runtime 系

  • 意味：「実行時のトラブル」

  • 対応：エラー画面を出したり、ログに残したりして運用でカバーする

この意識を持つだけで、「エラーが起きたときに何をすればいいか」が一瞬でわかるようになります。 ぜひ、明日からのコーディングで意識してみてくださいね！

しかし、ローカルのDocker Compose環境では問題なく動作しても、AWSのECS Fargateのような本番環境にデプロイしようとすると、いくつかの疑問に直面します。

• 「NginxとPHP-FPMコンテナはどう連携させるのがベスト？」
• 「fastcgi_pass ってローカルと設定を変える必要ある？」
• 「InertiaでビルドしたReactのJS/CSSファイルは、結局どのコンテナに置くのが正解？」

この記事では、fastcgi_pass の基本から、ECS Fargateでの最適なコンテナ構成、そしてInertia/Reactプロジェクト特有の「静的ファイルの配置場所」問題までを、順を追って解説します。

fastcgi_pass とは？

NginxとPHP-FPMの「橋渡し」

まず基本のおさらいです。Nginxは高性能なWebサーバーですが、それ自体はPHPコードを実行できません。
一方、PHP-FPMはPHPコードを実行することに特化したプロセス（サーバー）です。

Nginxがクライアント（ブラウザ）から .php ファイルへのリクエストを受け取ったとき、そのリクエストをPHP-FPMに処理してもらう必要があります。

このとき、Nginxの設定ファイル（nginx.conf）で、「どのPHP-FPMに処理を依頼するか」の宛先を指定するのが fastcgi_pass ディレクティブです。

location ~ \.php$ {
    # ...
    # ↓ この一行が「橋渡し」の指定
    fastcgi_pass php-fpm-server:9000; 
}

ローカル開発 (Docker Compose) での構成

ローカル開発では、「1コンテナ1責務」の原則に従い、NginxとPHP-FPMを別々のコンテナとして docker-compose.yml で定義するのが一般的です。

# docker-compose.yml (抜粋)
version: '3'
services:
  # Nginxコンテナ
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./laravel-project:/var/www/html

  # PHP-FPMコンテナ
  php:
    build: . # PHP-FPMとLaravelコードを含むDockerfile
    volumes:
      - ./laravel-project:/var/www/html

この構成では、NginxコンテナとPHPコンテナは 別々のネットワーク空間 に存在します。Docker Composeが提供する内部ネットワークを介して、サービス名で通信します。

したがって、NginxコンテナからPHPコンテナへは、php というサービス名（ホスト名）を使ってアクセスします。

# nginx.conf (Docker Compose用)
location ~ \.php$ {
    # ...
    # 'php' サービス（コンテナ）の 9000番ポートに転送
    fastcgi_pass php:9000;
}

（※ このTCP/IP通信によるパフォーマンスやセキュリティの懸念は、コンテナ間通信がDockerの内部ネットワークに限定されていれば、実用上ほとんど問題になりません。）

【1タスク2コンテナ】本番 (ECS Fargate) での構成：

さて、本題のECS Fargateです。
ECSでは、docker-compose.yml に相当するものとして「タスク定義 (Task Definition)」を使います。

ここで重要なキーポイントは、「1つのタスク定義の中で、NginxコンテナとPHP-FPMコンテナの2つを定義する」ことです。

これら2つのコンテナは、1セットで「Webアプリケーションサーバー」として機能します。

ECS Fargateでのfastcgi_passはどうなる？

ECSの同一タスク内で実行されるコンテナは、同じネットワーク空間（ネットワークモード awsvpc）を共有します。

これは、Nginxコンテナから見ると、PHP-FPMコンテナが「他人」ではなく、「自分自身（localhost）」として見えることを意味します。

したがって、ECS Fargate用のNginxイメージに含める nginx.conf の設定は、以下のようになります。

# nginx.conf (ECS Fargate用)
location ~ \.php$ {
    # ...
    # サービス名ではなく、localhost (127.0.0.1) を指定する
    fastcgi_pass 127.0.0.1:9000;
}

タスク定義のイメージ

タスク定義では、以下のように設定します。

• コンテナ-A: php-fpm-container
  • イメージ: （Laravelコードを含むPHP-FPMイメージ）
  • ポートマッピング: なし (外部に公開する必要はないため)
• コンテナ-B: nginx-container
  • イメージ: （設定済みのnginx.confと静的ファイルを含むNginxイメージ）
  • ポートマッピング: 80:80 (ALBからのトラフィックを受け取るため)

ALB（ロードバランサー）からのトラフィックはNginxコンテナが受け取り、必要に応じて localhost:9000 を介してPHP-FPMコンテナに処理を渡します。

Inertia/Reactのビルドファイルはどこに置く？

ここで、Inertia/React構成特有の問題に直面します。

「InertiaはLaravel（PHP）がビューを配信する仕組みだから、npm run build で生成された public/build フォルダは、PHP-FPMコンテナにだけ置けば良いのでは？」

これはよくある誤解ですが、パフォーマンスと責務分離の観点から、ビルドした静的ファイル（JS/CSS）はNginxコンテナに配置するのが正解です。

この理由を理解するために、Inertiaのページが読み込まれる2段階のフローを見てみましょう。

ステップ1: HTMLシェルのリクエスト (PHP-FPMが処理)

1. ブラウザが https://example.com/dashboard にアクセスします。
2. ALB → Nginxコンテナがリクエストを受け取ります。
3. NginxはこれがPHPのリクエストだと判断し、fastcgi_pass 127.0.0.1:9000 を使ってPHP-FPMコンテナに転送します。
4. PHP (Laravel) が起動し、Inertiaは app.blade.php をレンダリングしようとします。
5. このとき、PHPは public/build/manifest.json を読み取り、HTMLに含めるべきJS/CSSのファイル名を特定します。
6. PHPは以下のようなHTMLの「ガワ」を生成し、Nginx経由でブラウザに返します。

   <html>
   <head>
       <script src="/build/assets/app.12345.js" defer></script>
       <link rel="stylesheet" href="/build/assets/app.67890.css">
   </head>
   <body>
       <div id="app" data-page="..."></div>
   </body>
   </html>
   

ステップ2: 静的アセット(JS/CSS)のリクエスト (Nginxが処理)

1. ブラウザは、ステップ1で受け取ったHTMLを解析します。
2. 「/build/assets/app.12345.js と /build/assets/app.67890.css が必要だ」と判断し、ブラウザは別途2回のリクエストをサーバーに送信します。
3. このリクエストは、もはやPHPとは全く関係ありません。
4. ALB → Nginxコンテナがこの2つのリクエストを受け取ります。
5. Nginxは「自分の管理下（public フォルダ）にそのファイルがあるか？」を探します。
6. Nginxコンテナに public/build/ 以下の実体ファイルが存在するため、NginxはPHP-FPMを起動することなく、それらの静的ファイルを超高速でブラウザに直接返します。

もし、NginxコンテナにJS/CSSファイルがなければ、このリクエストもPHP-FPMに転送されてしまい、「JSファイルを取得するためだけにLaravelを起動する」という深刻なパフォーマンスボトルネックが発生します。

CI/CDでのベストプラクティス

上記2ステップから、CI/CDパイプラインでDockerイメージをビルドする際は、以下の構成が最適です。

1. npm run build を実行し、public/build ディレクトリを生成します。
2. PHP-FPMイメージのビルド:
   • Laravelのコード（app/, routes/ など）をコピーします。
   • ステップ1のために public/build/manifest.json をコピーします。（リンク生成に必要）
3. Nginxイメージのビルド:
   • nginx.conf をコピーします。
   • ステップ2のために public フォルダ全体（index.php と、public/build 以下の 全てのJS/CSSファイル を含む）をコピーします。（静的アセットの配信用）

結論

manifest.json はPHP-FPMコンテナに、JS/CSSの実体ファイルはNginxコンテナに必要です。

両方のイメージに public フォルダ（または public/build）全体をコピーするのが、最もシンプルで確実な方法です。

まとめ

ECS Fargateで Laravel + Inertia + React 構成を動かすための要点をまとめます。

1. 構成: 「1タスク2コンテナ（Nginx + PHP-FPM）」構成を採用します。
2. fastcgi_pass: NginxからPHP-FPMへの通信は、同一タスク内のため fastcgi_pass 127.0.0.1:9000; を指定します。
3. 静的ファイル: ビルドしたJS/CSSは、パフォーマンス最適化のためNginxコンテナに配置し、Nginxから直接配信させます。
4. manifest.json: HTMLシェル生成のため、PHP-FPMコンテナにも manifest.json が必要です。

この構成により、PHP-FPMは動的処理に専念し、Nginxは静的ファイルの高速配信に専念するという、「1コンテナ1責務」のメリットを最大限に活かした、スケーラブルな本番環境を構築できます。

I`m PHPer!!!!!

便利なstatic

PHPの static メソッドは、インスタンスを生成せずにクラスから直接呼び出せるメソッドです。

使うべきタイミング

状態を持たない処理

インスタンスの状態に依存しない、独立した処理を行う場合に適しています。例えば、ユーティリティ関数やヘルパー関数などがこれに該当します。

class MathHelper {
  public static function add($a, $b) {
    return $a + $b;
  }
}

echo MathHelper::add(3, 4); // 出力: 7

ファクトリーメソッド

クラスのインスタンスを生成するメソッド（ファクトリーメソッド）として使用されることがあります。

この場合、`new`キーワードを隠蔽して、インスタンス化の過程を制御できます。

class User {
  public $name;

  private function __construct($name) {
    $this->name = $name;
  }

  public static function create($name) {
    return new self($name);
  }
}

$user = User::create('John Doe');

あまり使いたくないね。。。

シングルトンパターン

特定のクラスのインスタンスが一つだけ存在することを保証するシングルトンパターンの実装に利用されます。

<?php

class Singleton
{
    private static $instance;

    private function __construct()
    {
// プライベートコンストラクタ
    }

    public static function getInstance()
    {
        if (self::$instance === null) {
            self::$instance = new self();
        }
        return self::$instance;
    }
}

$singleton = Singleton::getInstance();

だめな使い方

インスタンスの状態を操作する処理

インスタンスの状態に依存するメソッドに`static`を使うべきではありません。staticメソッドはクラスレベルで動作するため、インスタンス固有の状態を保持することができません。

class User {
  private $name;

  public static function setName($name) {
    $this->name = $name; // エラー: $thisを使えない
  }
}

過度な使用

全てのメソッドを`static`にすることは避けるべきです。

staticメソッドを多用すると、オブジェクト指向プログラミングの基本原則であるカプセル化や多態性が損なわれる可能性があります。
特に、後からメソッドをオーバーライドする必要が出てきた場合に柔軟性を失います。

依存性注入の回避

staticメソッドは依存性注入と相性が悪く、テストやメンテナンスが難しくなる場合があります。テスト可能なコードを維持するためには、インスタンスメソッドを使用し、必要な依存関係をコンストラクタやセッターで注入する方が望ましいです。

まとめ

static メソッドは、クラス固有の処理やユーティリティ関数として適切に使用することで、コードの構造を明確にし、インスタンス化を不要にするメリットがあります。ただし、過度な使用はオブジェクト指向の原則を損なう可能性があるため、状況に応じて適切に使い分けることが重要です。

1. 概要
   • エラー内容
   • 環境
2. 原因
3. 解決方法
   • rollupのインストール
   • deployerのBuildタスクの修正
4. 番外編
5. おわり

概要

Deployerを使ってクラウドサーバーへのデプロイを行うとBuildエラーが発生した。

ローカルでのビルドは問題なく通るのですが、クラウドサーバーへ上げる際に死ぬ。

初めて出会ったエラーのため解消に時間がかかったので、助かる人が増えることを願って記事に残します。

エラー内容

npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@rollup%2frollup-linux-x64-musl--save-optional - Not found
npm ERR! 404 
npm ERR! 404  '@rollup/rollup-linux-x64-musl--save-optional@*' is not in this registry.
npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

npm ERR! A complete log of this run can be found in: /Users/oshidamarina/.npm/_logs/2024-08-13T03_48_16_120Z-debug-0.log

環境

• Laravel 10
• Vue3
• TypeScript5
• Tailwind
• DaisyUi
• Macbook Air（開発機）
• AmazonLinux2023（本番サーバー）

原因

Viteのビルド中に発生する `@rollup/rollup-linux-x64-musl` モジュールが見つからない問題に対処しています。この問題は、ViteがRollupのネイティブバイナリに依存しているため、特定の環境（特にDockerコンテナやLinux環境）で発生することがあるとのこと。

https://github.com/vitejs/vite/discussions/15532

解決方法

rollupのインストール

npm install @rollup/rollup-linux-x64-musl --save-optional

package.json に下記の記載があること。

"optionalDependencies": {
      "@rollup/rollup-linux-x64-musl": "^4.20.0"
 }

deployerのBuildタスクの修正

task('deploy', [
    'deploy:prepare',
    'deploy:vendors',
    'deploy:shared',
    'deploy:writable',
    'build',
    'artisan:migrate',
    'deploy:publish',
]);

// Build task: run npm install and npm run build
desc('Build the project');
task('build', function () {
    run('cd {{release_path}} && npm install && npm run build');
});

番外編

DeployerのBuildタスクを以下のように調整してみると僕の環境では通りました。

task('deploy', [
    'deploy:prepare',
    'deploy:vendors',
    'deploy:shared',
    'deploy:writable',
    'build',
    'artisan:migrate',
    'deploy:publish', 
]);

// Build task: run npm install and npm run build
desc('Build the project');
task('build', function () {
    run('cd {{release_path}} && rm -rf node_modules package-lock.json'); // FIXME： 原因は他にある
    run('cd {{release_path}} && npm install && npm run build');
});

ただし、この方法ではBuildは成功するが、ブラウザ表示に難がでてくるという記事もあったため、取りやめ。

多くの人が解決しているであろう rollup の修正で対応することにしましたー。

おわり

Buildが通ったー！ってことで終わりです。
Viteのバージョンを調整したりしたら意外とすんなり解決したりするのかなーとおもったり…

お困りの方も試してみてください。

Interfaceは、コードの可読性や保守性を向上させる強力なツールです。

この記事では、僕がInterfaceを使う理由とその利点について、具体例を交えながら説明します。

コードの一貫性を保つ

Interfaceを使うことで、プロジェクト全体で一貫したメソッドシグネチャを保つことができます。例えば、複数のクラスが同じ操作を実行する場合、それぞれのクラスに同じメソッドを実装させることが可能です。これにより、コードを読む際にメソッドの名前や引数の形式に迷うことがなくなります。

interface LoggerInterface {
  public function log(string $message): void;
}

class FileLogger implements LoggerInterface {
  public function log(string $message): void {
    // ファイルにログを記録する処理
  }
}

class DatabaseLogger implements LoggerInterface {
  public function log(string $message): void {
    // データベースにログを記録する処理
  }
}

依存関係の注入を容易にする

Interfaceを使うことで、依存関係の注入が容易になります。

特定のクラスに依存するのではなく、Interfaceに依存することで、将来的にクラスを変更する場合でも、コード全体に大きな影響を与えずに済みます。

class UserController {
  private $logger;

  public function __construct(LoggerInterface $logger) {
    $this->logger = $logger;
  }

  public function createUser(string $name): void {
    // ユーザー作成の処理
    $this->logger->log("User created: $name");
  }
}

テストの容易化

Interfaceを使用することで、テストが容易になります。
モックオブジェクトやスタブを使って、依存関係を簡単に置き換えることができるため、ユニットテストの実行が簡単になります。

モックができないとUTが書きづらい場面が多々出てくるので、そのためだけに Interface を使っていると言っても過言ではないです。

class MockLogger implements LoggerInterface {
  public function log(string $message): void {
    // テスト用のモック処理
  }
}

$logger = new MockLogger();
$controller = new UserController($logger);
$controller->createUser('John Doe');
// ここでログが正しく動作するかをテスト

拡張性の向上

Interfaceを使うことで、新しい機能の追加が容易になります。

例えば、新しいタイプのLoggerを追加する場合、既存のコードを変更することなく、新しいクラスを追加するだけで済みます。

class EmailLogger implements LoggerInterface {
  public function log(string $message): void {
    // メールにログを送信する処理
  }
}

まとめ

Interfaceを使うことで、コードの一貫性、依存関係の管理、テストの容易化、拡張性の向上といった多くの利点があります。PHPでの開発において、Interfaceを効果的に活用することで、より健全で保守性の高いコードを実現することができます。ぜひ、皆さんもInterfaceの利点を活用してみてください。

メモリ制限の設定 (memori_limit)

PHPスクリプトが消費することができる最大メモリ量を指定します。デフォルト設定では「128M」が多いですが、大規模なアプリケーションを扱う場合はこの値を増やす必要があります。不足するとスクリプトが突然停止することがあるため、適切なメモリ量を設定しましょう。

memory_limit = 256M

実行時間の制限 (max_execution_time)

スクリプトが実行を終了するまでの最大時間を秒単位で設定します。デフォルトは「30秒」ですが、時間がかかるプロセスを扱う場合はこの値を調整するこことが重要です。

max_execution_time = 60

エラーレポーティング (error_reporting)

開発中はすべてのエラーを表示することが重要です。しかし、本番環境ではエラー表示を抑えるべきです。この設定を通じて、どのレベルのエラーをレポートするかを制御できます。

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

ファイルアップロード (file_uploads)

ファイルアップロードを許可するかどうかを制御します。セキュリティ上の理由から、使用しない場合は無効化することが推奨されます。

file_uploads = On

セッションのセキュリティ設定

セッションIDの扱いには特に注意が必要です。セッションハイジャックを防ぐために、セッションIDの再生成やセキュアなクッキーの使用が推奨されます。

session.use_strict_mode = 1
session.cookie_secure = 1
session.cookie_httponly = 1

まとめ

これらの設定は、PHPのパフォーマンスとセキュリティを大きく向上させることができます。php.iniの設定は一見複雑に見えるかもしれませんが、それぞれの項目に慎重に注意を払い、アプリケーションのニーズに応じて適切に調整することが非常に重要です。この記事があなたのPHP設定を見直すきっかけになれば幸いです。

CakePHPを使った開発の際に躓いたポイントを解説しますぅ

概要

データ取得時に関連データを合わせて取得したい。関連データの取得時には条件に一致しないデータが

関連データを用いて取得条件を絞りこみ、関連データが条件に一致しない場合、親も取得しないようにしたい。

関連データの取得方法

CakePHPでのデータ取得はmatching, innerJoinWith を用いることで、SQLのJOINに類似した操作が実現できます。

これにより、特定の関連データに基づく厳密なデータフィルタリングが可能となります。

matchingはN:Nの関係性のときに強力な関数となるが、条件指定の際に思った挙動にならないため注意が必要。

MatchingとInnerJoinWith

対応表として以下の形になる。

CakePHPのマニュアルのせいで時間取られたので、備忘録として残しておきっます。

概要

Commandクラスからメールに添付するURL生成を行いたい。

その際に生成されるURLはHTTPS化されたURLを添付したい。

現環境 ↓

• CakePHP 4.4
• PHP 8.1

困ったこと

ControllerやViewでURL生成を行うと現在のoriginを見るのですが、Commandクラスなどoriginを見れないものは明示的にオプションを示さないといけないのがCakePHPの掟です。

今回の目的である、CommandクラスからHTTPS化されたURLを添付するにはどうしたらいいかというと、マニュアルのとおりに、生成時のオプションにHTTPSの指定をする必要がある。

_https true にすると普通の URL から https に変換します。 false にすると、強制的に http になります。

URL の生成

$routes->url([
    'controller' => 'コントローラー名',
    'action' => 'アクション名',
    '_https' => true,
]);

これだけでHTTPSを指定できるのは、便利だなと思った矢先、HTTPSになっていない。

Routerクラスのインポート、スペルミスなどを確認してもHTTPS化ができていない。

どうしてもHTTPS化が必須の要件だった、CakePHP3のマニュアルも読んでみた。

驚きの展開だったのが、Cake3とCake４でオプションの内容が違うことがわかった。

_ssl true にすると普通の URL から https に変換します。 false にすると、強制的に http になります。

URL の生成

以下の形で指定すると今回の目的を達成することができた。

$routes->url([
    'controller' => 'Articles',
    'action' => 'index',
    '_ssl' => true,
]);

枯れた技術を使うのはちょっと手間がかかりますねぇ。

SPAを構築するのはコスト的に対応が難しいため、Laravelプロジェクトの一部にVueを導入する方法を解説しまっす。

環境

• PHP8.2
• Laravel10
• Vue3
  • node v18.19.1
  • npm 10.5.0

やりたいこと

Laravel10の一部にVue.jsを適用する

• Vueコンポーネントを定義する
• Vueコンポーネントをバインドする
• Vueコンポーネントにバックエンドからデータを渡す

手順

なにわともあれVueのインストール

LaravelはビルドツールにViteを採用しているため、ViteのプラグインとしてVueをインストールします。
（CLIでインストールしても良いと思いますよ！

$ npm install @vitejs/plugin-vue

$ npm install @vitejs/plugin-vue --save-dev

vite.config.js の設定

インストールしたVueを設定ファイルに追記します

import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue'; // 追記

export default defineConfig({
  plugins: [vue()] // 追記
});

app.jsを使える状態に持っていく

Vueコンポーネントをグローバルコンポーネントとして登録するために、以下の形でapp.jsを編集します。

下記の記述でやりたいこととしては、コンポーネントの作成及びコンポーネントのマウントです。

import './bootstrap';
import {createApp} from 'vue';
import Alpine from 'alpinejs';
import VueDatePicker from './Components/Utility/CsrfToken.vue';
import VueDatePicker from './Components/Utility/DatePicker.vue';
import AddSalesListModal from "./Components/AddSalesListModal.vue";

window.Alpine = Alpine;

Alpine.start();

const app = createApp({});

// グローバルコンポーネント
app.component('csrf-token', CsrfToken);
app.component('add-sales-list-modal', AddSalesListModal);
app.component('date-picker', VueDatePicker);

// #appにマウント
app.mount('#app');

マウント先の指定

app.js でマウント先を id=’app’ としたため、以下のように blade ファイルにマウント先となる記述を設定します。

<body id="app" class="font-sans antialiased flex flex-col min-h-screen">
~
~
~
</body>

コンポーネントの作成

試しにLaravelで生成されるCSRFトークンを扱うコンポーネントを作成します。

このコンポーネントはaxios等で非同期通信を実装するときなどに重宝されるはずですので、皆さんも作っておくと便利ですよん。
（今回は擬似的にpタグにCSRFトークンを出力していますが、本来はしません

<script>
import { ref, onMounted } from 'vue';

export default function useCsrfToken() {
    const csrfToken = ref('');

    onMounted(() => {
        const token = document.querySelector('meta[name="csrf-token"]')?.getAttribute('content');
        if (token) {
            csrfToken.value = token;
        }
    });

    return csrfToken;
}
</script>

<template>
<p>{{ csrfToken }} </p>
</template>

コンポーネントの呼び出し

以下の通りに記述したらVueで取得したCSRFトークンが出力されているはずですぅぅ

<csrf-token></csrf-token>

Vueにバックエンドのデータを渡したいときには、以下の通りに実装してみてください

// Blade
<csrf-token :test='@json($test)'></csrf-token>

// Vue
<script setup>
import { defineProps, ref } from "vue";

const props = defineProps({
    test: Object,
});
</script>

最後に

SPAカッコいいから時間さえあればSPA化したい。