【PHP】Laravel【フレームワーク】 Part.8
■ このスレッドは過去ログ倉庫に格納されています
Laravel使ってるっていうと恥ずかしいよな
DjangoがfastAPIだろ 何が悲しくてPythonでサイト作らないといけないんだよ
どういう理由でチョイスするのか興味あるわ 世界ではphp自体がもはや廃れていく方向
日本だけガラパゴス化
webはpythonかjs（node）が主流 ここまで具体例の無い批判してて恥ずかしくねーのかw Django使ってみたけど何でLaravelなら簡単に出来る事がこんなに面倒なの？と言う場面が結構あった。
複数のマイクロサービスを立ち上げるのに良いかなってくらい webをpythonかjs（node）で構築する案件の規模ってどれくらいが主流なの？ぴんきり？ そもそも日本でwebをpython+djangoで始めるのはビジネス状のリスクがデカすぎるんだよね。趣味でやってろって思う。一番のネックは、エンジニアを市場から調達するのが難しくて、サービスが成長したときにすげー苦労すんだよね。過去2件ほどそういう残念なプロジェクト見かけたわ。 なぜ少ない日本のエンジニア市場でエンジニアを確保しようと思うんだろうか
世界中にエンジニアがいるのに 世界中のエンジニアって・・・
発注した事あるのか？
言語の違い、生活習慣の違いがどれだけ完成物に影響出すかしらないだろ >>545
オフショア開発やったことあんの？どの国？ インドとかいうんだろ？
ラマダンの時に当たった時あんのか？お祈りの時間に会議になった時あんのか？ ベトナムとかあの辺が最近多いらしいけど結局は意思疎通が出来る日本人の現地マネージャ次第かと
すべてリモートは無理がある >>546
オフショア開発したこと何回もあるがブリッジエンジニアがいるし現地にも日本語話すPMがいるんだよ
ていうかこんなの当たり前すぎだろ
しかも顧客は日本だけじゃなく世界的にやってるところも多い
Laravelerってこんなことすら知らないのか >>549
そりゃお前が底辺で参加してるからだなｗ
少しでも上流かマネジメントに関わっていれば、オフショアは地獄 オフショア開発で上がってくるのは出来の悪いモノが多い >>549
いや、俺はオフショア開発数年経験してるし、現地の会社数社の経営層と品質改善等に関して議論したこともあるが？ぶっちゃけ、オフショア開発本当に使ったことあるなら、そういう感想にはならないと思うんだが。 オフショアが良いか悪いか、モノと体制次第と言うしかない >>542
結局、日本のエンジニアが一番優秀で一番安い
NECや富士通がオフショアで10年以上失敗続けてるのに
なんでおまえがやれば成功すると思ったんだ？ 複雑なアルゴリズムを含むようなものはインド人とかにやらせた方が良いんでないか？あと東欧とか数学気質のある所。
日本人だと面倒な事言ってきそう >>553
こちらも現地までいってるから知ってるけど経営者やPMは日本人または日本で10年以上働いていた人
実際の開発は学生みたいな若いのが多いがピンキリ
品質低いなんて最初から織り込み済みで最初の準備と中間レビューで十分なんだが
任せっぱなしだとお前みたいにヒーヒー言うんだろうが >>558
あー、品質低くて当たり前の底辺に生きる人か。そりゃ会話にならんわ。品質の低さがビジネスの成長の阻害要因になることも分かってなさそうだな。 >>558
何の記事読んだんだよw
実際経験した事ないやつが書きそうな内容だな
学生さんかな？ >>554
開発効率や内容の話をするのがエンジニアってもんだが、
ここの奴らはそれ以前の段階だからな
Laravelが良いか否か、必要か必要じゃないかって、ここで話すようなことかよ いやそれだとQuoraになっちゃうから、ここはこれで良い 具体的な話をするとQuoraになるからこのままでいい指摘すら意味が分からない なんかLaravelerが変な方向でモめ始めて訳わからんけど、ヨシやれ！ >>562
この内容が飛躍しすぎだと思っている時点でわかってないね >>566
低くなりがちだからチェックして事前準備して中間チェックで品質あげとるんだが？
読めねえガイジならレスすんなボケ 品質ってバグじゃなくて技術的負債の話なんだけどそれ伝わってる？オフショア開発の場合、負債の増加が早くてベロシティ悪化してくじゃん？中間レビューでそれを防ゲルと思ってるの？ 負債ってなんだよ？
こちらが設計した技術なのに負債もクソもないだろ
おめえのところは検収すらしないのかよ
ゴミ会社乙だな >>570
それはさすがに煽るにしても筋が悪いよ
そもそも技術的負債は何にもしなくとも溜まっていくよ
根本的に練り直してから煽りなさいな
やり直し >>571
検収することが煽りで筋が悪いってことか？
意味わかんねえんだが
で技術的負債がゼロの開発を教えてくれるか？ 技術的負債の増加が早いことを指摘しているのに、他のやつのツッコミに対して技術的負債ゼロの開発を教えろやって言ってるあたり、読解力も底辺なのかな？ アホの集まりだな
オフショアになるとなんで技術的負債が増えるんだ？
例えばLaravel8を選んだとしてどこに技術的負債が早くなるのかオフショア開発と日本の開発で比較してくれ
設計や技術選定は同じ指定だ あーコイツ、マジでオフショア開発やったことあるって嘘ついてるか、オフショア開発の一部の工程しか担当したこと無い感じか。
自分が理解できないからって他責にしてアホ呼ばわりとは笑えるわ。そんなんで、教えてもらえると本気で思ってんのかな？ >>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でアクセスログ解析なんかは古典だけど
今でもアリなのでは無いかと ■ このスレッドは過去ログ倉庫に格納されています
