【PHP】Laravel【フレームワーク】 Part.8
■ このスレッドは過去ログ倉庫に格納されています
あーコイツ、マジでオフショア開発やったことあるって嘘ついてるか、オフショア開発の一部の工程しか担当したこと無い感じか。
自分が理解できないからって他責にしてアホ呼ばわりとは笑えるわ。そんなんで、教えてもらえると本気で思ってんのかな？ >>577
オフショア開発の一部工程しかやったことないのはお前だろ？
そりゃ一部工程しか関わってないときは俺もお前と同じ認識だったけど
オフショア開発全部に関わるようになった今は認識が違うんだよ >>578
へー、お前も俺みたいに現地のCEOらと開発品質について議論したり、プロセスについて議論したことあるんだ？それなのに技術的負債の蓄積が早いという話は理解できないのか？マジで？ >>578
「オフショア開発全部」ってワードに
使い方合ってる様で気持ち悪い違和感感じるんだけど俺だこ？ 俺だこって何だよw
俺だけかこれ？の略だから！決して打ち間違いでは無いから！ この殴り合いの感じ、5chらしくていいね
カンガルーがボクシングしてるAAをまさに体現してる 元請けからしてみたらテストコードが網羅されていればソースの出来なんて全く気にしないんだがな。
最悪別のベンダーに、テストケース満たすコードを作り直させればいいっていう割り切りすら持ってる。 すいません、
新規会員登録のバリデーションルールをいじっていたら、登録済みユーザーのログイン画面でバリデーションエラーが表示されログインできなくなりました。
DB接続はできています。
原因お分かりの方教えていただけないでしょうか。 原因はバリデーションルールをいじったからだろ
そのバリデーションルールが新規会員登録にしか影響しないようになってるの？ >>589
registerControllerの中のvalidatorをいじったまでです。
そこが影響してるのかわかりませんが
authの中身見ても問題はなかったので
laravel のログインエラーに詳しい方いないかなあと。
正直全く理由がわからず手詰まりです。 >>588
おめえSVNかCVSでソースコード管理してないの？ >>591
SVNとかCVSはよく分かりませんがギット？は使ってます。 だったらログイン時にもそのコントローラー通ってるくらいしか考えられないでしょ
ログイン時はバリデーションルール適用しないようにすれば良いんじゃないの？
その直し方で弊害ないかどうかは知らんけど Eloquentとクエリビルダのget()の結果を扱うときに違いがあるのが気持ち悪い
$itemsはget()の結果
★Eloquent
foreach ($items as $item) {
$item→foo; ←エラーにならない
$item['foo']; ←エラーにならない
}
★クエリビルダ
foreach ($items as $item) {
$item→foo; ←エラーにならない
$item['foo']; ←エラーになる
} あと、toArray()しても完全にPHPの配列として扱えるのはEloquentの方だけというのも気持ち悪い >>594
俺はEloquentとクエリビルダってデータベースからデータを取ってくる
って部分が同じってだけの別サービスって思って使っとかないと
どうしても合わせたいって話なら
Eloquentに寄せていく感じであれば、こんなとか
DB::table('table_name')->get()->mapInto(Illuminate\Support\Fluent::class);
コレクション当てるとかがいいんじゃないかな？
mapInto(Illuminate\Support\Collection::class)
何にするかはその日の気分で
このあたり使っとけばtoArray()で動作一緒になるっしょ？
毎回mapInto書きたくなければ
eventかmacroをサービスプロバイダで登録しちゃえば一回でOK
検証してないけど多分行けるはず
それかイテレーター書いてそっちに流すとかかねぇ
クエリビルダは全然使わないから正確に回答できてるかわからんけども collectionで操作したとしてもコールバック内で同じ気持ち悪い感じになるんじゃないかな？
作法としても機能的にもcollection使って操作した方が断然いいと思う
超思うんだけど、ドキュメントの例だとforeach使ってるから変な感じに広まっちゃうよね
あと、collectionのtoArray()とall()とかあんまり説明されてなくて不親切だなーとか思ったり思わなかったり >>594
クエリビルダはハイドレート先のクラスが無いため、標準クラスとして返す。だから配列としてアクセスできないという身も蓋もない話なんだけど、まぁ確かに最初は気持ち悪く感じるよね。
ただ気持ち悪いからって理由でハイドレートするような処理を追加しちゃうと、結局eloquent並みにパフォーマンスが劣化しちゃうから、それぞれの特性に応じて使い分けてくしかないんじゃないかな。 みなさんありがとう
事の発端は元々Eloquentで取得していた処理を、
結合が複雑になったのでクエリビルダーに書き換えたところ
\Log::debug(取得結果);でエラーになった。
（stdClassを渡したため）
恥ずかしながらそこで初めてEloquentとクエリビルダーの戻り値の違いに気づいた。
上で書かれているように、Eloquentとクエリビルダが別サービスっていう認識はなく、
取得方法を変えたから取得結果を扱う後続処理にも変更を入れるっていうのはなんか納得いかず、
後続処理に変更を加えず済むにはどうすればいいのかなと思い悩んでたので愚痴を書き込みました。 php8.2で動的プロパティが禁止になるみたいだけどLaravel大丈夫かな？
結構動的プロパティ使ってるよね >>601
さすがにマイナーバージョンで禁止するようなことは、あのニキータおばさんでもしないと思うんだ。
てか、これやったらPHPerの暴動起きると思うよ。厳格なPHPを別プロジェクトで作ろうぜって話も昔あったけど、やるならそっちでどうぞって感じ。たぶん支持は得られないだろう。 >>600
もっと言うとeloquentが返すcollectionとクエリビルダが返すcollectionも似てるけど別の性質(メソッドとか)なので
確認の手間考えたら書き直しちゃった方が早いなんて事もありそう
>>601
俺の記憶では動的プロパティ使ってないはず
一回マジックメソッドに渡してから
普通にメソッド経由で処理する仕様じゃない？
https://github.com/laravel/framework/blob/master/src/Illuminate/Support/Fluent.php
こーゆーの 中間テーブルの取り出し方、いろんなサイト見てもいまいちわからん、、、 >>604
中間テーブルって普通モデルキーしかないけど
それ以外にカラムがあってその値を取り出したいって話？ >>603
プロパティはアロー演算子でアクセスするように書き直してたら今度は別の事象が、、、
↓ともに戻り値はIlluminate\\Support\\Collection Objectなんだけど、foreachやコレクションのeach内でのレコードの扱いは①は配列で②はstdObject、、、
① collect($array);
② \DB::table('hoge')->get();
foreachやeachで扱う配列がどの機能によって作成された配列なのか意識しないといけない
あとクライアントに返却するAPIのレスポンスに複数の配列をセットするときに↓みたいになることは普通なのか
return [
hoge1 => $hoge1, ←PHPの配列
hoge2 => $hoge2, ←Collectionの配列（Illuminate\Support\Collection）
hoge3 => $hoge3, ←クエリビルダの配列（Illuminate\Support\Collection）
hoge4 => $hoge4, ←Eloquentの配列（Illuminate\Database\Eloquent\Model）
];
試してみたらクライアントではすべてJSON形式で受け取れたから問題なさそうだけど、、、
Laravel始めたばかりでわからないことだらけだけど気にしすぎなのか、、、 >>606
なんか仕事飽きてきたから返事するわ
完全に俺の知識の上でって話になるから間違えてたら申し訳ない
> foreachやeachで扱う配列がどの機能によって作成された配列なのか意識しないといけない
この認識が少し違うかなって思ってて
意識しなきゃいけないのは「処理しようとしている値(配列、Eloquent、stringなど)が何なのか？」じゃないかな？
その上で渡されるであろう形式が不明な場合はどの型でもいいけど決まった型に変換してから処理する方が後々楽かなと
ちょうどその部分触ってたからコード載せとくね
https://gist.github.com/atamiso/afb6deb2a9dd85e691cb64faed0fc995
該当部分切り出してあるだけだからそんなに大層なものじゃないけど
これで言えばコレクション入れようがModel入れようが
配列が戻ってくることが確定してるから戻り値を配列として処理してあげればよくなる
でもまあ今回の話では全然必要ないのよね 続き
何でかというとLaravelのヘルパで解決可能なお話なの
https://readouble.com/laravel/8.x/ja/helpers.html#method-data-get
このヘルパは、オブジェクトにプロパティが存在するならその値を戻すし
配列にキーがあればその値を戻してくれるって子なのよ
クエリビルダ
data_get( DB::table('users')->first(),'プロパティ名','デフォルトの値');
Eloquent
data_get( User::query()->first() , 'プロパティ名' , 'デフォルトの値' ) ;
配列
data_get( ['id' => 10 , 'name' => '名前' ] , 'キー名' , 'デフォルトの値' ) ;
こんな感じね
それからEloquentが返却するコレクションはIlluminate\Database\Eloquent\Collection
クエリビルダが返却するコレクションはIlluminate\Support\Collection
なので微妙に違うので気を付けてくださいね 続き
> クライアントに返却するAPIのレスポンスに複数の配列をセットするときに↓みたいになることは普通なのか
普通にあると思う、例えばユーザー情報取得API叩いた時とか
実データ部分、メタデータ入れとく部分、デバッグ時なんかはその辺りの情報も入れるかな
そういう話ではなく他の関係ないテーブルのデータとかの話なんだが？って言われそうなので先に書いておくけど
出力する一歩手前の段階で渡されたデータの種類なんて知った所でなんの役にも立たないでしょ？
そこでやらなきゃいけない事は受け取ったデータを仕様に沿った形で返却するだけでいい
ドキュメントで言うとこの辺りが該当部分だと思うから見てみてね
https://readouble.com/laravel/8.x/ja/eloquent-resources.html#data-wrapping-and-pagination
> 試してみたらクライアントではすべてJSON形式で受け取れたから問題なさそうだけど、、、
これは上にも書いたけどレスポンスの手前でjsonに変換してくれてるからなんだけどかなり緩く受け取ってくれるから便利
ArrayableとかJsonableインターフェースが実装されてればまず問題ないはず
強烈な長文になってしまいましたが参考にしてみてください
間違いあってもいじめないでね
Discordの悪夢がよみがえるから
おしまい お前らどうした？
Laravelスレで真面目にLaravelの議論しているなんて・・・ >>605
はい、、、てかわざわざ中間テーブル作らなくても普通のテーブルに複数idもっててondeleteで関連持たせればbelongstomanyとかやらなくても良いのでは？と感じてたんです >>611
それだと多対多の関係作れないでしょ？
無理矢理作ったとしてもお互いが依存しまくってわけわからんってならない？
それともネストしてるリレーション考えてる？ 申し訳ありません。なにか参考になるサイトあれば教えてください。公式やQiitaの内容みてpivotで取得しようとしても取れなくて >>613
ブックマーク検索したら出てきたやつ
https://www.ritolab.com/entry/122
一応聞いておくけど確実に多対多のリレーションできてて
実際にデータ同士をattach使って関連付けたり
detach使って切り離したりは確実に出来るんだよね？
できてるなら Model::with('相手先')->where(条件)->get()
ってやったら勝手にpivotに入ってくると思ったけどな・・・ >>609
ありがとうございます。
データの取得方法や生成方法が変わって扱うデータ形式が変わったから、
後続処理にも変更（$item->valueを$item['value']に変えないといけないみたいな）を入れる必要があるというのは嫌だったので
gitのコードとヘルパすごい参考になりました。 お疲れ様です。
laravelで会員登録時にハッシュ化してDBに保存されたパスワードを、admin画面でユーザー情報編集時に●●●表記で編集フォームに復元する際
上手く渡すにはどうすればいいのでしょうか。
ご教授頂きたく宜しくお願い致します。 今の仕様だとハッシュの文字数分●が表示されてしまうのでおかしいです。 ハッシュ化しているのに元の文字列が復元できたら意味ないやんw 元のパスワードの文字数を別カラムに保存しておけば●の数を再現できるぞ >>620
釣り？もしかして、「ポリモーフィック関連はアンチパターンである」を勘違いして、多対多自体をアンチパターンと勘違いしている？ そもそも●の数をハッシュ化前と一致させることに何の意味もないと思うんだが。プロフィール変更画面で●を並べるどころか、パスワード欄を空白にしてるサイトも結構あるはず。 ワイも登録されているパスワードを表示せず空欄でいいと思う 客に言われた通りの仕様しか作れない底辺が偉そうだなwww アホか客に作らせた方が楽だろうが
仕様考えるのが一番めんどいんだよ 仕様がクソだと実装もクソになりがち。クソな仕様を無くしてしまえば、実装コストゼロ。言われたままに作るのは3流。 アホか客のクソ仕様をそのままバカ正直にクソ実装するわけないだろ無能じゃないんだから
つーか実装コストゼロって何だよお前は魔法使いか何かか 具体的な話が一切出ない言い争いしてるし・・・
何なんだここは アクセスログみたいな時系列データってどういう設計にしてますか？
作る度に毎回腑に落ちない感じになっちゃうからみんなどうやってるのか知りたくて・・・
一般的なショッピングサイト
月間PV100万から300万
規模感はこのくらいって想定 >>633
多少ログが大きくなったりする場合はPHPだけでどうにかすることは難しいので
fluentdを利用してPHP側からはfluentdに投げるだけの仕様にして
その先の設計はまた別に考えた方がいいかもね
良くあるのがfluentd,Elasticsearch,kibanaでアクセスログ解析なんかは古典だけど
今でもアリなのでは無いかと >>634
かなり昔fluentd,GigQuery,Grafanaって構成でやってみたことあったんだけど
その時の感想っていうか反応が
・完全にオーバースペック
・小回りが利かない
・ランニング思った以上にかかる
・費用対効果悪い
って散々な目に合ったトラウマがあって恐怖心しかないｗ
完全に自分の実力過大評価してたなーって今は思う
結局ランニングいくらなの？って質問に答えられるなら
あの頃の俺のリベンジをしたい気もする
どの程度で運用可能なのかね、実際 Apacheでaccess_logに吐くだけだわ
もちろんそれでいいとは思っていない アクセスログってユーザーのアクセスログならGoogleアナリティクスだけど、バックエンド側のログのほうがほしいの？ DB使うならテーブルをログ取得用と集計用にわけないと、すぐ肥大化するよ GAは使いこなせる人間がいないのと
タグマネ入ってるから無料超えちゃう
故に提案したら面倒みる事になるのが嫌かな
しかも俺が作った訳じゃないって理由で単価が安い
その割に俺の学習コストかかる
まあ人生最後にリベンジしたいって気持ちはでかい
あ、この話ってあくまで空想上の話だからね
相談された時に何か美味しいご飯が食べられそう
って匂いがからとかじゃないんだかんねっ >>641
いや今時Apacheなんて誰も使わないだろ Apacheって3割ぐらいしか使われていないってシェアが発表されてた気がする Apacheの新規導入はもはや少数派だと思うけど
更新しながら使い続けてるApacheに乗せるのは普通にある Apacheでダメな理由も特にないからな
シェア3割と言ってもnginxも3割で後はその他って感じらしい laravel動かすのにnginxはapacheの代わりにならないだろ apacheの上位互換のサーバがあるなら使ってるかもしれないけど
現状はapache+nginxのリバースプロキシ よくわからないんだけどapache単独で使うのとapache+nginx使うのとでは
どういうメリットがあるの？ laravel6だけど環境回り何も変えていないのにcomposer install や update するとエラーが出るようになった。
最初はPHPの目盛り足りないって怒られたからおかしいなって思って、
memory_limitいろいろ変えて試してたんだけど解決せず、
最終的にmemory_limit=-1にして実行したら、↓のエラーが発生
Killed artisan package:discover --ansi
Script @php artisan package:discover --ansi handling the post-autoload-dump event returned with error code 137
昨日まではエラー出なかったのに今日急にエラーが発生するようなた。
解決方法わからず、、、同じ現象の人いませんか、、、
★PHP
root@app:/app# php -v
PHP 8.0.7 (cli) (built: Jun 28 2021 20:47:22) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.7, Copyright (c) Zend Technologies
★composer
root@app:/app# composer --version
Composer version 2.0.14 2021-05-21 17:03:37 >>647
Laravel+nginxで何が困るの？ twitter検索したら昨日くらいから似た症状の書き込みありますね、、、
composerの問題っぽい？ >>650
composerのバージョン上げたとか
プロジェクトごとコピーとか移動した？ だからcomposer嫌いなんだよ
もう何でもかんでもcomposerで入れるようになってるからcomposerが動かなくなったら詰むのに割とよく動かなくなって詰む composerで詰むとかそんなんたびたび起きるか？
なんか変なことしてるんでしょ >>653
composerのバージョンは上げていません。
バージョンを2.1.8に上げてinstallやupdateしても解決しませんでした。
ちなみに、laravel6の最新プロジェクトを新たにcreate-projectしてcomposer updateしたらエラーなく正常にvendorが作られました。
元のプロジェクトのcomposer.jsonと違いがあるのか確認中です。 >>654
それが嫌なら高性能なパッケージ管理システム作りなさいな
無能な俺たちは便利なツールを無料で使わせてもらってるって事を忘れちゃいけない
知識不足を棚に上げて作ってくれた方々に対してのリスペクトが無さすぎるよ >>658
まてまて、「環境回り」の中にcomposerでインストールされるであろうパッケージ群も含まれてるって認識なんだけど・・・
discoverしちゃダメなパッケージdiscoverしてるんじゃないの？
.envファイル無しで >>660
.envファイルがあるのは確認しました。
installやupdateが正常に行えてたときのソースバージョンから、
エラーが発生したときのソースバージョンまでのコミットを1つづ確認したところ、
あるコミットが含まれるバージョンでcomposer installやupdateでエラーが発生することが確認できました。
修正内容のどこが影響してたのかはこれから確認になりますが、
アプリの動作はエラーもなく正常だったのでまさかcomposerに影響してるとは思いませんでした。
原因はcomposerのバージョンではなくく初歩的なミスのようです、、、すみませんでした、、、 >>661
パッケージディスカバリーなんてゴリゴリ影響ある部分だよ
人間の側が間違いを起こさなけりゃ機械も決して悪さはしねえもんだ。 >>662
ありがとうごじあます。勉強になりました。 >>659
>無能な俺たちは
多分、毎回それ言ってるのお前だと思うけど、
お前が無能であるから使っている事と俺を一緒にするな。 >>664
無能だなんだって始めて書いたんだけど・・・
そうだね、ごめんね一緒にして悪かったね
俺は自分の事を有能だなんて思った事なんて一度も無いからおそらく無能なんだろうね
だけど今までcomposerが動く要件を満たしているのであれば、動かなくて詰んだ事なんてないよ
「詰む方が有能なんだもん！」って言いたいのかな？
君は表面さらっただけの湯葉みたいな知識しかない割に自己評価高く見積もりすぎだと思うので気をつけようね composer程度も扱えないやつはまじでPHPいじらないでほしい >>667
Issueが182も溜まってるからいくつかクローズしてこいよ Ver2に移行した際に軽い不具合はあったが、それくらいだな
これを使わないなら自力でパッケージ管理してるの？
それは確かにすごい能力だと思うし、自分には真似できない composerでどうのこうの言ってるような奴は
npmなどのjsのパッケージ管理ツールとか異次元なのではw お前らえらそーに言うけどアホ面してcomposer updateとかコマンド打ってるだけだろ？
それがいくらぐぐっても解決しない謎のエラー吐いたら直せるスキルあんのか？
誰かが作ったもの使ってるだけでたまたまうまく動いてるだけのバカが偉そうにすんな無能 どうせメモリ足りないよエラーとか依存性のエラーとかだろ
どうにでも対応できるだろw >>672
bugだけでも36残ってるからどうにでも対応して直してこいよ >>674
Issueが182も溜まってるって言ってんじゃん
バカなの？読めないの？
読めたらコメントしてこいよ >>672
て思うやん？メモリ増やしても解決しねーんだわこれが
さてお前ならどうする？ >>675
愚直なのはいい事だと思うけど
目的地までの道は1本だけじゃないのよ
いつも使ってる道が工事中なら別ルート使うでしょ？
その別ルートをどれだけ知ってるかが経験や知識なのね
もう一度いうけど君は圧倒的にそれが足りないよ
多分まだ若いんだから先人達が書いた素晴らしいコードを何万行も読み込んで勉強しよう
呼吸する様にgithubのコードを読もう
そうすれば数年後には今の俺なんか目じゃないくらいのエンジニアになってるはずだから ■ このスレッドは過去ログ倉庫に格納されています
