Firebase AnalyticsのlogEventイベントをDebugViewでリアルタイム確認する方法

作者:

Firebase Analytics の logEvent を使用して送信したイベントデータをリアルタイムで確認するには、Firebase Console の「DebugView」機能を使用します。

DebugView は、開発中やデバッグ時に送信されたイベントを即時に可視化できるため、イベント設計や挙動の検証に役立ちます。

各プラットフォームごとのデバッグモードの有効化手順は以下のとおりです。

Web アプリの場合

  1. Google Analytics Debugger という Chrome 拡張機能をインストールします。
  2. 拡張機能を有効にした状態で Web アプリにアクセスします。

Android アプリの場合

  1. Android 端末にアプリをインストールした状態で、以下のコマンドを実行します。 
    adb shell setprop debug.firebase.analytics.app <your.app.package.name>

    <your.app.package.name>は、以下のようにbuild.gradle (Module: app)ファイルのapplicationIdの値を指定します。

    android {
   defaultConfig {
       applicationId "your.app.package.name"  // ← この値がパッケージ名です
   }
}
  2. 上記コマンド実行後、対象のアプリを起動します。

デバッグモードの無効化（Android）

デバッグモードを無効にするには、以下のコマンドを実行します。

adb shell setprop debug.firebase.analytics.app .none.

iOS アプリの場合

  1. Xcode で対象アプリのターゲットを選択します。
  2. メニューから「Product」→「Scheme」→「Edit Scheme…」を選択します。
  3. 左側メニューの「Run」→「Arguments」タブを開きます。
  4. 「Arguments Passed On Launch」に以下のフラグを追加します。 
    -FIRDebugEnabled

  5. 上記設定を保存し、アプリをビルドして実機で起動します。

参考

Dockerを使ってローカルにPHPをインストールせずにLaravelプロジェクトを構築・実行する方法

作者:

Laravel開発では、通常ローカルマシンにPHP、Composer、Laravelインストーラーなどをインストールして環境を構築します。
しかし、Dockerを活用すれば、これらをローカルに一切インストールせずに、Laravelプロジェクトの作成と実行が可能です。

本記事では、その具体的な手順と、ローカル非依存型の開発環境がもたらす実践的メリットについて解説します。

1. DockerでLaravelプロジェクトの初期セットアップ

1-1. Laravelプロジェクトの作成（Composer）

docker run -it --rm \
  --user "$(id -u):$(id -g)" \
  -v "$(pwd):/app" \
  -w /app \
  laravelsail/php84-composer:latest \
  composer create-project laravel/laravel my-app

このコマンドにより、現在のディレクトリに my-app フォルダが作成され、Laravelの初期ファイルが生成されます。

1-2. プロジェクトディレクトリへ移動

cd my-app

2. Laravel Sailの導入と開発サーバの起動

2-1. Laravel Sail のインストール（Docker 経由）

docker run -it --rm \
  --user "$(id -u):$(id -g)" \
  -v "$(pwd):/app" \
  -w /app \
  -e COMPOSER_HOME=/tmp/composer \
  laravelsail/php84-composer:latest \
  php artisan sail:install

2-2. 開発サーバの起動

./vendor/bin/sail up -d

これにより、Laravelプロジェクトの開発環境がバックグラウンドで起動します。
初回起動時にはDockerイメージのダウンロードとビルドが行われるため、数分かかる場合があります。

3. 開発環境の初期設定（おまけ）

Docker上のLaravel開発環境をより実用的に整備するための初期設定です。

3-1. .envファイルの確認・初期設定

APP_NAME=Laravel
APP_URL=http://localhost

3-2. セッションテーブルのマイグレーション作成と実行

./vendor/bin/sail artisan session:table
./vendor/bin/sail artisan migrate

3-3. アプリケーションキーの生成

./vendor/bin/sail artisan key:generate

3-4. 最初のページをブラウザで確認

http://localhost

4. DockerによるLaravel開発のメリット

Dockerを活用することで、以下のような利点が得られます。

  • ローカル環境のクリーン化
    開発用の依存パッケージをホストOSに直接インストールしないため、他プロジェクトとの競合を回避できます。

  • 本番環境との整合性
    Dockerで同一環境を構築することで、本番やCIと同様の設定で開発が可能になります。

  • PHPバージョンの柔軟な切り替え
    PHP 8.1、8.2、8.3などの異なるバージョンのDockerイメージを利用することで、容易に切り替えられます。

  • チーム間の環境統一
    コンテナを使用することで、OSの違いに依存せず、同一の手順で開発環境を再現可能です。

  • セキュリティリスクの低減
    ホストマシンにPHPやWebサーバを直接インストールしないため、常駐サービスや脆弱性の混入を抑制できます。

5. まとめ

DockerベースでLaravel開発環境を構築する手法は、可搬性・分離性・再現性のいずれにも優れています。
特にチーム開発やCI/CDとの統合においては、環境の一貫性を維持しながら柔軟な開発体制を実現できる点が大きなメリットです。

Macメンテナンスのコマンド集

作者:

開発や日常業務で使い続ける Mac には、定期的なメンテナンスが不可欠です。
不要ファイルや更新されていないパッケージの放置は、システムのパフォーマンス低下や開発環境の不安定化を招く原因となります。

本記事では、Homebrew・Mac App Store・Docker・Xcode など、主要なツールのアップデートおよびクリーンアップを一括で行うためのコマンドを紹介します。

コマンド一覧（概要）

# Homebrewの定義情報とインストール済みパッケージをアップデート
brew update && brew upgrade

# GUIアプリを含む全Caskアプリをアップグレード（自動更新アプリも対象）
brew upgrade --cask --greedy

# 古いパッケージとキャッシュを削除し、ストレージを最適化
brew cleanup

# 参照されなくなった不要な依存パッケージを削除（Homebrew 4.0以降）
brew autoremove

# Homebrew環境の健全性をチェック（警告が出たら適宜対応）
brew doctor

# Mac App Storeアプリを一括アップデート
mas upgrade

# Xcodeの派生データや不要シミュレータを削除
xcrun simctl delete unavailable
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# 未使用のDockerリソースとボリュームを削除（慎重に実行）
docker system prune -f --volumes

1. Homebrew パッケージの更新とアップグレード

brew update && brew upgrade

Homebrew のパッケージ定義情報を最新化し、インストール済みの CLI ツールを一括でアップグレードします。
セキュリティパッチの適用や新機能の取り込みにより、開発環境の安定性と安全性を確保するための基本的なメンテナンス操作です。

2. GUIアプリ（Cask）の包括的アップグレード

brew upgrade --cask --greedy

Homebrew で管理される GUI アプリケーションを含めてアップグレードします。
–greedy を指定することで、自動更新機能付きのアプリ（例：Chrome、Slack など）もアップグレード対象になります。

3. 古いバージョンやキャッシュの削除

brew cleanup

不要になったインストール済みの古いパッケージやキャッシュを削除し、ストレージの空き容量を確保します。
定期実行がおすすめです。

4. 孤立した依存パッケージの削除（Homebrew 4.0以降）

brew autoremove

他のパッケージから参照されていない依存パッケージを自動で検出し削除します。
Homebrew 環境をスリムかつクリーンに保つのに有効です。

5. Homebrew 環境の健全性チェック

brew doctor

Homebrew の設定やリンク状態など、環境の不整合を診断します。
警告が出た場合はその内容に応じて対応することで、潜在的なトラブルを未然に防げます。

6. Mac App Store アプリのアップデート

mas upgrade

mas CLI を使って、Mac App Store でインストールしたアプリを一括でアップデートします。
GUI を使わずに済むため、自動化にも最適です。

7. Xcode 関連のクリーニング（容量削減に有効）

xcrun simctl delete unavailable
rm -rf ~/Library/Developer/Xcode/DerivedData/*

Xcode を使った開発では、以下のような不要ファイルが溜まりやすく、ストレージを圧迫します。

  • 利用できなくなった古い iOS シミュレータ
  • ビルドごとに自動生成される派生データ（DerivedData）

これらを削除することで、数GB単位のストレージ空き容量を確保できる場合があります。
特にモバイルアプリ開発者にとっては、定期実行が推奨されるクリーニング項目です。

8. Docker の未使用リソースとボリュームの削除

docker system prune -f --volumes

未使用の Docker イメージ・コンテナ・ネットワーク・ボリュームを一括削除します。
実行前にリソースの使用状況を確認し、誤削除を防ぎましょう。

まとめ：メンテナンスを習慣化して安定した Mac 環境を

Homebrew や Docker を利用する開発環境では、依存関係の肥大化や不要ファイルの蓄積は避けられません。
以下のようなスクリプトにまとめて、定期的に実行する運用体制を整えることで、健全な開発基盤を維持できます。

実行手順を自動化するスクリプト例

#!/bin/bash

# Homebrewパッケージ更新とクリーンアップ
brew update && brew upgrade && brew upgrade --cask --greedy
brew cleanup && brew autoremove
brew doctor

# Mac App Storeアプリのアップデート
mas upgrade

# Xcode関連の不要ファイル削除
xcrun simctl delete unavailable
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# Dockerリソースの削除
docker system prune -f --volumes

Amazon Linux 2023でのRedisサポート終了と移行先まとめ

作者:

まずはざっくり説明

なぜ移行が必要？

Amazon Linux 2023で使っているRedis 6は、2025年8月31日でサポートが終わります。
サポートが終わると、バグ修正やセキュリティ更新が一切なくなり、システムにリスクが出ます。
そのため、別のバージョンやサービスへ移行する必要があります。

どんな選択肢がある？

簡単にまとめると次の3つです。

選択肢 特徴
Redis 7 現行に近いが、自分でインストールが必要。将来少し不安あり。
Valkey Redis互換の新しいOSS。AWS公式サポートもあり安心。
Amazon ElastiCache AWSが全部運用してくれる。超楽だけどコストは高め。

ざっくりイメージ図

 コスト重視
    ↑
 Valkey（低コスト）
    │
 Redis 7（ビルド必要）
    │
 ElastiCache（コスト高・超楽）
    ↓
 運用負荷重視

おすすめまとめ

あなたの希望 おすすめ
とにかく簡単にしたい Amazon ElastiCache
お金を抑えたい Valkey

ここから詳しい解説

はじめに

Amazon Linux 2023（AL2023）環境で稼働しているRedis 6は、2025年8月31日をもってサポート終了（EOL）となります。
これに伴い、セキュリティ更新や不具合修正が行われなくなるため、継続運用には新たな移行先の選定と準備が不可欠です。

本記事では、Redis 6 EOL対応に向けた移行先の検討ポイントおよび具体的な選択肢を詳しく整理します。

移行先選定のポイント

現在、RedisはLaravelベースのアプリケーションにおいて、キューやキャッシュに利用されています。
このため、以下の基準を重視して移行先を選定しました。

種別 内容
必須要件 Laravelとの互換性、AL2023への導入容易性
望ましい要件 長期的な保守体制、ライセンス上の安心、コスト最適化

移行候補一覧と詳細比較

1. Redis 7

  • Laravelとの互換性は高い
  • AL2023の標準リポジトリには未収録、独自ビルドが必要
  • Redis 7.4以降はライセンス変更（RSAL）により、商用利用に制限あり

2. Valkey

  • Redis 2〜7.2までと互換性あり（Laravelでも問題なし）
  • BSDライセンスで自由に使える
  • AWS公式パッケージがAL2023向けに提供済み
  • プロジェクト自体は新しいため、導入実績は発展途上

3. Amazon ElastiCache

  • AWS提供のマネージドRedisサービス
  • パッチ適用、スケーリング、監視すべて自動化
  • 導入が非常に簡単
  • ただし、ランニングコストは自前運用より高め

詳細比較表

項目 Redis 7 Valkey ElastiCache for Redis
Laravelとの互換性 高い 非常に高い 高い
AL2023対応 なし（ビルド必要） AWS公式パッケージあり AWSマネージド
ライセンス RSAL（制限あり） BSD（制限なし） AWS独自
導入の手間 中（ビルド作業あり） 低（簡単インストール） 低（数ステップ）
運用管理の負荷 高（自前対応） 高（自前対応） 低（AWSが対応）
コスト 低（ただし保守コストあり） 低 中〜高（スケールに応じ課金）
将来性 ライセンス変更リスクあり AWS公式採用で将来性あり 非常に高い

結論と推奨

パターンA：運用を楽にしたい場合

  • 選択肢：Amazon ElastiCache
  • 理由：AWSが運用代行、安定性と可用性が高い

パターンB：コストを重視したい場合

  • 選択肢：Valkey
  • 理由：Redis互換が高く、OSSとして自由に使える

おわりに

Redis 6のサポート終了は、システムリスク回避に向けた大きな節目です。
どの移行先を選ぶかは、コストと運用負荷のバランスを考慮して慎重に判断しましょう。

早めに計画を立て、移行準備を進めることを強く推奨します。