Laravel Sail 環境を PHPStorm でデバッグする #Laravel #PHPStorm

前提

  • Laravel v9.17.0
  • Sail v1.14.10

環境変数を定義

.envxdebug を有効化し、設定を変更する

SAIL_XDEBUG_MODE=develop,debug
SAIL_XDEBUG_CONFIG="client_host=host.docker.internal idekey=PHPSTORM start_with_request=yes"

ブラウザ拡張を使う方法なんかもあるが、 API とかだと必ずしもブラウザ経由とは限らないので、 start_with_request を有効にしておく。

起動する

アプリケーションを起動する

sail up -d

適当なところにブレークポイントを貼る。

デバッグコネクションの Listen を開始する。

アクセスする

ブレークポイントを通るようなリクエストを送る。

ダイアログが出るので、取り敢えず Accept しておく。

Server を設定する

PHP > Servers0.0.0.0 とかで追加されているので、 path mappings を設定する。

Project files を /var/www/html/ にしておけば OK のはず。

他の項目もお好みで。

おわり

設定が終わったらもう一度アクセスしてみて、ブレークポイントで止まることを確認する。

参考

Laravel の補完を PHPStorm で使いやすくする #Laravel #PHPStorm

概要

Laravel のモデルでクエリを組み立てようとすると、 Method 'where' not found と言われてしまう。

このせいで PHPStorm の補完が効かなかったり、警告が出てしまったりする。

<?php
// where のとこで警告が出る(動作は問題ない)
MyModel::where('name', $name)->first();

// query() をかませると平気なんだけれども、面倒
MyModel::query()->where('name', $name)->firstOrFail();

laravel-ide-helper を導入する

laravel-ide-helper で解決できそうなので導入してみる。

IDE補完用のコードを生成してくれるようだ。

github.com

README に従って入れてくだけ。

sail composer require --dev barryvdh/laravel-ide-helper

モデル以外にも役立ちそうなので、全部入れてみる。

sail php artisan ide-helper:generate
sail php artisan ide-helper:models
sail php artisan ide-helper:meta

直接プロダクトコードを上書きする方法と、別ファイルに切り出す方式が選べる。

あくまでヘルパーなので、別ファイルにしてみる。

Do you want to overwrite the existing model files? Choose no to write to _ide_helper_models.php instead (yes/no) [no]:
 > no

方針次第だと思うけど、対象のファイルを .gitignore に入れておくとよさそう。

別の警告が。。

無事補完はできるようになったのだが、別の警告が出るようになってしまった。

ファイルを別にする方式の弊害っぽいが、 Multiple definitions exist for class .. と言われてしまう。

色々調べてみたけれども、対象の警告をオフることにした。(しかし敗北感が。。)

参考

Google Domains のドメインのサブドメインを Amazon Route53 で利用する #terraform

Route53 でパプリックホストゾーンを作成

terraform だとこんな感じ。

resource "aws_route53_zone" "sample" {
  name = "sample.mydomain.dev"
}

パブリックホストゾーンを作成すると、NS レコードと SOA レコードは自動作成される。

Google Domains で NS レコードを作成する

Route53 側の NS レコードを、 Google Domains 側に設定する。

Amazon Route53 側

Google Domains 側

Amazon Route53 で A レコードを作成

terraform だとこんな感じ。

# Alias record の場合
resource "aws_route53_record" "sample" {
  zone_id = aws_route53_zone.sample.zone_id
  name    = aws_route53_zone.sample.name
  type    = "A"

  alias {
    name                   = aws_elb.sample.dns_name
    zone_id                = aws_elb.sample.zone_id
    evaluate_target_health = true
  }
}

# こっちは LB
resource "aws_elb" "sample" {
  name               = "sample-elb"
  availability_zones = ["us-east-1c"]

  listener {
    instance_port     = 80
    instance_protocol = "http"
    lb_port           = 80
    lb_protocol       = "http"
  }
}

その他

ホストゾーンを冪等で作ったり壊したりするケースがあんまり浮かばなかったので、作成と切り分けて参照の方がよいかもしれない。

data "aws_route53_zone" "sample" {
  name = "sample.mydomain.dev"
}

参考

Fixture Factories で Faker が日本語にならなかった #CakePHP

問題

CakePHP に Fixture Factories を導入しようとしていた。 Faker が利用できるので、日本語化しようと思ったがどうもうまくいかない。

原因と解決

defaultLocale がハイフン区切りの ja-JP になっていた。

アンダースコア区切りの ja_JP を指定することで解決した。

詳細

Fixture Factories で使用する Faker は、 I18n::getLocale() で取得した Locale を使用するようになっている。

なので、アプリケーション側で設定されている Locale が自動的に適用される。

github.com

今回は CakePHP 側で Locale 設定していたが、アンダースコアの ja_JP ではなく、 ja-JP になっていた。

処理を追っていくと、適用する Locale のプロバイダーがアンダースコア形式になっているのが前提のためだった。

備忘

原因としては分かったけれど、アンダースコアかハイフンかって、なにか仕様とか規格で決まってるのかなぁと思って調べてみた。

これ!という決定的な情報は見つからなかったんだけれども、どうやら Unix / Linux 系の言語設定ではアンダースコア区切りらしい。

locale コマンドや、LANG 環境変数を確認すると ja_JP.UTF-8 のようになっている。(まぁ自分の設定次第ではあるが)

ところが RFC5646 で言語タグのフォーマットを見てみると、ハイフン区切りで定義されている。

この辺で間違いが起こりやすいのかもしれない。

datatracker.ietf.org

CakePHP の国際化のドキュメントでは en_US とか fr_FR のようなアンダースコア形式がサンプルの中で用いられているので、アンダースコアで設定するのが正攻法で間違いなさそう。

book.cakephp.org

Android 開発に入門してみた #Android

なんかやったことないことやってみたいな〜、と思って Android 開発を少しだけやってみた。

特に Android 自体に強いこだわりがあったわけじゃないんだけれど、 Java や Kotlin を久しぶりに触りたいなって気持ちがあった。

どうやって入門したか

主に2冊の本を写経して動かしてって感じで進めた。

たった1日で基本が身に付く! Androidアプリ開発超入門

超入門というだけあって、サクッと全体像を掴むのにとてもよかった。

レイアウトエディタの使い方とか、Android開発の雰囲気が分かった気になれる。

改訂版が比較的新しいので、そこも安心できるポイントだった。

実際にアプリを公開するには規約を用意したりが必要なんでやってないが、テスト版を Play ストアで配布するところまで試したりした。

Androidアプリ開発の教科書

自分は第1版を読んだんだけれど、第2版が出てるので今から買うならそっちのほうがいいと思う。(リンクは第2版にしておいた)

Androidアプリ開発超入門は Java だったんだけれど、こちらは Kotlin を使った。(同じ本で Java 版もある)

Android アプリでどういうことができるのか、どうやればいいのか、を一通り知るにはいい感じ。

カメラアプリと連携したり、メディア再生したりとその気になれる。

一方で少し情報が古いのか、 LinearLayout が基本になっていて、 ConstraintLayout や RecyclerView はちょっとしか言及されていない。

自分の持っている端末が Android10 なのでそれを minSdk にしていたけれど、本のコードを写経すると deprecated なものもちょいちょいあった。

調べながら書き換えてみたりしたけど、第2版だとこの辺が新しくなってたりするのかもしれない。

関係ないけど、 Listener みたいなのって内部クラスガンガン作るのがお作法なのかな。

再利用しないなら、 Kotlin ならそのまま無名関数書くのでいい気がした。(多分今は Java でもできるか)

設計が知りたい

読んだ本は設計観点の話がなかったので、そのへんがとても気になっている。

FatActivity とか、状態管理地獄で容易に死ぬ世界が想像できたので。

Google 公式でそれっぽいドキュメントや Example もありそうだったけど、よさそうな本があったのでとりあえずそれを読んでみようかなと思ってる。

テストが知りたい

テストはどんな感じでやるのか、全然イメージできていない。。

Google 公式にドキュメントはあるのは観測しているけど、 UI があるだけに何をどこまでテストしていくのかが肝になりそう。

この辺は Web フロントエンドと似たような感じなのかな。

初心者向けにおすすめのコンテンツや教材があったら教えて下さい。

感想

実機で作ったものがあると、どんなにショボくても少なからず感動がありました。

僕らはいつもスプリントレビューをしていた

久々の出社、とある機能の実装が一段落し、Dev環境にデプロイした。

隣の席のプロダクトマネージャーにふと「見ます〜?」と言ったら「見る見る!」となった。

そしたら隣の島にいた別の人が「私も見たい!」となって覗きに来る。

なので実機(スマホアプリ)から簡単にデモをしてみた。

「この場合は〜になるんですよ」みたいな、他愛ない話を少しばかりした。

以前のチームを思い出した

もうコロナ前で前職にいたチームはこんな光景が当たり前だなと思い出した。

スクラムっぽい開発プロセスだったけど、スプリントレビュー*1の時間を待つことなく、一通り実装が終わると「ちょっと見てもらっていいですか〜」と声がかかった。

プロダクトオーナーを中心に開発者や他の人達も集まって、みんなで誰かの PC を後ろから覗き込んだ。

デモをして、フィードバックをして、簡単なものはすぐ取り込んだり、次のリリースに反映したりしてた。

それが日常の開発だった。

今は基本リモート

やっぱりオフラインがいい!なんて言うつもりはない。

リモートワークは便利だ。

公私も含めた生活において、総合的にリモートのほうが楽である。

月に数回程度の出社ですら、(僕自身はオフィスの徒歩圏内に住んでいるにも関わらず)少しばかり腰が重くなってしまう。

リモートになってからも、気になるところがあればキャプチャや動画をチャットツールで共有して、必要なら Slack のハドルや Zoom でフィードバックを送り合ってる。

今いるところも、いいチームだなって思う。

それでもライブ感から生まれる感情や一体感の高まりというのは、オフラインの方がいいなぁと感じたのも事実だ。

日常の風景

総合的にはリモートが日常である方が便利だ。

個人的にも、もうオフラインを日常にするのは難しいだろうなと思う。

だけどそれでも最高点を叩き出すのはオフラインな気がした。

いつでもどこでも音楽を聴ける Spotify は便利だけれど、それでもライブに足を運ぶ感覚に近いのかもしれない。

ただし誰もがライブを見に行くわけではないというのもまた、そうだろうと思う。

*1:スクラムでいうところのスプリントレビューはステークホルダーに対してのものなので、この表現が正確でない部分はある

Android で「Requested internal only, but not enough space」というエラー #Android

Android Studioエミュレータでアプリを起動しようとしたらエラーが発生してしまった。

java.io.IOException: Requested internal only, but not enough space

単純にエミューレータのデバイスで空きサイズが無いということらしい。

ストレージ容量を増やしたり、外部ストレージに保存する方法もあるみたい。

ただ作ってるアプリ的にゴミデータが溜まってるだけかなと思って調べてみたら、デバイスマネージャからお掃除できた。

お掃除したい端末で「Wipe Data」してあげれば OK。

f:id:su-kun1899:20220402194948p:plain

参考