【PHP】Laravel【フレームワーク】 Part.6

**nobodyさん** · 2021/05/25(火) 20:01:01.50

Laravel
ウェブ職人のためのPHPフレームワーク

本家
https://laravel.com/

git
https://github.com/laravel

動画チュートリアル(英語)
https://laracasts.com/

和訳ドキュメント
http://laravel.jp/

※前スレ
【PHP】Laravel【フレームワーク】 Part.5
https://medaka.5ch.net/test/read.cgi/php/1618535648/

**nobodyさん** · 2021/06/16(水) 20:12:12.16

>>589
根拠ゼロで草

**nobodyさん** · 2021/06/16(水) 20:17:13.52

保険屋さんとかデータ系とかJavaで自前で作ってる現場多かったよ

**nobodyさん** · 2021/06/16(水) 20:17:23.57

>>592
それはさすがに知らねーよ
大手勤務の俺が120分でログアウトする仕組みで無双した件的なラノベの矛盾点が論点なんだから

**nobodyさん** · 2021/06/16(水) 20:20:13.41

結局DBの時間見るとのセッション期限を更新しないのはどっちが良いんだよ

**nobodyさん** · 2021/06/16(水) 21:03:26.40

どっちでも良いだろ
どうせ大してアクセスのないサイトだろ

**nobodyさん** · 2021/06/16(水) 21:03:43.31

このスレの総意としては>>534のやり方を推奨だよ

**nobodyさん** · 2021/06/16(水) 21:06:57.77

スレの総意おじさんもずっとこのスレいるよな
的外れなことばっかり言う

**nobodyさん** · 2021/06/16(水) 21:29:26.18

お前ら本当に暇なんだな
大手だの零細以前にまず働いてんのか？

**nobodyさん** · 2021/06/16(水) 21:40:00.79

半分くらいは実際に仕事で使ってそうだけど
残り半分は趣味とかやろな

**nobodyさん** · 2021/06/17(木) 01:10:46.72

ここにいる全員がその半分に属してるんだよ

**nobodyさん** · 2021/06/17(木) 06:46:12.22

ほんとにバカしか居ねぇなぁ…。

**nobodyさん** · 2021/06/17(木) 07:28:04.84

お前だってそうだろ

**nobodyさん** · 2021/06/17(木) 07:38:58.35

アプリ側で時間管理して超過したら強制ログアウトでええやろ

**nobodyさん** · 2021/06/17(木) 07:42:06.92

>>596
ロードバランサ使ったりAWSで複数インスタンス使ってるような構成だとDBでセッション管理してると思う
だから今回のような疑問が出てくる時点でおそらくシステム構成を理解できてない

もしくは既存システムをいじりたくないのであれば別途監視アプリを作って常駐させる
C言語使えるならこっちのほうが楽かもね

**nobodyさん** · 2021/06/17(木) 07:47:30.33

>>589
独自FW作るのはLaravel以前からやってる案件
cakeの頃に独自FW作るのが流行った
codeigniterに皮かぶせて独自FWっていってるのもあったな
とにかく一世代前の話
昔からやってる人は慣れてる独自FWで揃えたいっていうのもあるだろう
会社として複数FWを利用すると教育コストがかかっちゃうから一度採用したFWは変えられないという都合もある

ただ、新陳代謝が一巡してるであろう今の時期になってもまだ独自FWのままっていうのは
特殊な事情があるのか、もしくは開発者が入れ替わってない（高齢化）のか、もしくは開発者のレベルが低すぎて
言われたままやる人しかおらずもはやFW入れ替えなんていうことをするパワーがないのだろう

独自FWっていうのは下請け企業が他社に仕事を取られない為の難読化テクニックの一つ

**nobodyさん** · 2021/06/17(木) 07:48:57.47

>>606
DBってリレーショナルDBのことか？
そんなとこでセッション管理しないだろ
今までの現場はほぼRedisだわ

**nobodyさん** · 2021/06/17(木) 08:03:25.51

>>608
どっちでもいいんちゃう？
DBでも大して遅くはならんやろ

**nobodyさん** · 2021/06/17(木) 08:05:12.58

>>608
インフラ設計したことある？IaaSとかで売上の立たない業務システム作るときは、月額のインフラコスト少しでも減らしたいからKVSじゃなくてDB使うケースはありえるでしょ。

わざわざセッションドライバやキャッシュドライバにDBが用意されているのはなぜか考えような。

**nobodyさん** · 2021/06/17(木) 08:05:30.80

過疎システムなら別にRDBで管理しようがRedisで管理しようがあんま変わらないけど、
ロードバランサで負荷分散が必要になる規模だとRDBでセッション管理するのは非効率極まりないね

**nobodyさん** · 2021/06/17(木) 08:07:11.27

RedisってNoSQLだし、そりゃRDBよりも高速だよね

**nobodyさん** · 2021/06/17(木) 08:09:41.75

＞ロードバランサ使ったりAWSで複数インスタンス使ってるような構成だとDBでセッション管理してると思う

↓

＞ IaaSとかで売上の立たない業務システム作るときは、月額のインフラコスト少しでも減らしたいからKVSじゃなくてDB使うケースはありえるでしょ。

**nobodyさん** · 2021/06/17(木) 08:10:53.06

どうせDBアクセスしまくるんだからセッション管理分が1、2回ぐらい増えても大してレスポンス変わらんやろ

**nobodyさん** · 2021/06/17(木) 08:13:21.38

>>613
いやさすがに別人だろ…
同一人物だったら笑うが、ワッチョイ無いのが悔やまれるな

**nobodyさん** · 2021/06/17(木) 08:28:34.83

>>607
自前FWでドキュメントもある所もあった。自前FWを作ったコストを相殺できるくらいには各種案件に使おうとしてるようだった

**nobodyさん** · 2021/06/17(木) 08:35:34.07

>>616
独自FWだと下請けに出すときに困るんだよ
というか出された下請けが困る
つまりワイが困る

**nobodyさん** · 2021/06/17(木) 08:36:02.14

独自FWはバージョン管理で破綻しやすい
パブリックなFWだと案件のほうをあわせるしかない
しかし、独自FWだとFWを案件にあわせていく

案件の数だけ枝がわかれた独自FWなんてただの悪夢だ

**nobodyさん** · 2021/06/17(木) 08:37:39.20

composerはそもそも使ってるのかな？

**nobodyさん** · 2021/06/17(木) 09:41:33.08

>>614
誰もレスポンス速度のこと言ってないよ
安いRedisを使うか高いRDBを使うか、コストの話だよ

**nobodyさん** · 2021/06/17(木) 09:50:44.17

>>613
何が言いたいのか詳しく。ちなみに>>606は俺じゃないけどな。

**nobodyさん** · 2021/06/17(木) 09:51:25.32

業務に使ってるRDBMSを使いまわしたってかまわないし
セッション用にNOSQLを使う場合もあるだろう
細かい条件を決めてベストを尽くすのがおまえらの仕事
ここで何も聞かずにベストプラクティスが決まるようならおまえらの仕事は不要だよ

予算ないならRDBMS1台とロードバランサー1台、インスタンス1台の構成で
アクセス増えてきたら動的にインスタンス起動ってところじゃないのかな

本当に金かけたくないならインスタンス1台に全盛りでスケーラビリティなしだ

**nobodyさん** · 2021/06/17(木) 09:56:11.83

ロードバランサーの用途を負荷分散のためだけとか思ってる奴が何人か居るんだな。冗長化必須の場合もロードバランサーで複数のインスタンス使うよ。

業務システムだと負荷は無くても落としたらしばかれるからそういう構成になる。まぁ零細だと多少落ちてもそんなもんだって許されるのかもしれないが。

**nobodyさん** · 2021/06/17(木) 10:07:56.12

>>619
独自FWの場合、composerは使わない
独自FWのメリットはソースコードを非公開にできることが大きい
公開することによって脆弱性が見つかる場合もあるから

**nobodyさん** · 2021/06/17(木) 10:37:16.95

いい加減独自FWなんて負債以外の何者にもならないって、皆痛い目して学んどるやろ
まあ非独自にしたって100%解決はせんけど

**nobodyさん** · 2021/06/17(木) 11:00:02.08

>>624
OSSの思想と真逆のアプローチをとるんだな

公開して皆で脆弱性を見つけて修正できるという思想、
非公開にすれば脆弱性を見つけるのが難しくなるという思想。

日本らしいといえば日本らしいな。

**nobodyさん** · 2021/06/17(木) 11:15:57.65

毎日のようにSQLインジェクションくさいアクセスログを見ている身としては、非公開FWのほうが安全てのは思考停止すぎるよとだけ言っておく。

**nobodyさん** · 2021/06/17(木) 11:28:39.27

composerでどうにかなる程度の枝しか作ってないと思ってるのか？
案件ごとに独自進化する地獄を見せつけてやりたい
案件バージョンとFWバージョンのグリッドを見て涙するがいい

**nobodyさん** · 2021/06/17(木) 11:42:55.10

なんでドヤ顔でバッドノウハウ自慢してるんだ

**nobodyさん** · 2021/06/17(木) 11:52:04.34

囚人はつながれた鎖の大きさでマウントをとる

**nobodyさん** · 2021/06/17(木) 11:52:55.96

なにそれいい言葉だなどこで覚えたの

**nobodyさん** · 2021/06/17(木) 12:07:09.91

自前FW作ってる所はVPCで業務に使ってるとかそんなのだった気がする。確かに案件毎の別バージョンは地獄っぽかった

**nobodyさん** · 2021/06/17(木) 13:27:43.67

>>627
それ言うほど問題か？SQLインジェクションなんて真っ先に対策するじゃん
XSSとかCSRFとかある程度の脆弱性対策してから開発するだろ

**nobodyさん** · 2021/06/17(木) 13:42:57.50

アメリカ人「OSSにすれば脆弱性が見つかる」
日本人「OSSにすれば脆弱性が見つかる」

**nobodyさん** · 2021/06/17(木) 13:50:26.10

>>633
その対策がガバガバだったらどうするの？

**nobodyさん** · 2021/06/17(木) 13:54:35.52

>>635
そんなレベルのやつはOSSフレームワーク使っても脆弱なシステムしか作れんよ
根っこが理解できてないんだから

**nobodyさん** · 2021/06/17(木) 14:01:44.56

>>633
そういうことではなくて、独自だろうが何だろうが、外に出す以上は一定の脅威に晒されることに変わりがなく、コードから脆弱性を見つけられないという点は何ら安全を保証するものでもないし、公開しているFWより安全であることの証明にもならないって指摘。

**nobodyさん** · 2021/06/17(木) 15:51:52.25

Web公開したらまっさきに攻撃してくるのがトレンドマイクロ

**nobodyさん** · 2021/06/17(木) 17:33:38.73

20年ぐらい前のペーペーの頃、SQLインジェクション（実際には実行できない）があるって
見知らぬ奴がわざわざお問合せフォームから連絡してきたっけ

当時は不正アクセス防止法とかないから、攻撃しようと思えばできたろうけど
単に教えてくるって良いやつだったんだな

**nobodyさん** · 2021/06/17(木) 18:03:54.76

>>633
一般的な会社は画面に「データを返してほしかったらビットコインをよこせ（意訳）」って表示されてから対策をはじめるんだよ

**nobodyさん** · 2021/06/17(木) 18:04:54.95

>>636
さすがにそれは違うだろ
少なくともオレオレFWで作るよりははるかに安全

**nobodyさん** · 2021/06/17(木) 18:04:55.83

>>634
海外の有名FWと公開したところで誰も使わないであろう弊社FWを比較するのはちょっと違和感を感じる

**nobodyさん** · 2021/06/17(木) 18:07:22.40

>>638
githubを巡回してるロボいるよな
あれAWS社は有名だけどあとはどこが巡回してるんだ

**nobodyさん** · 2021/06/17(木) 18:17:59.36

>>640
え、お前の会社が日本の標準なの？

**nobodyさん** · 2021/06/17(木) 18:27:41.08

>>644
社名に日本って入ってるし

**nobodyさん** · 2021/06/17(木) 20:33:27.24

LaravelでFWの素の状態を知ってから他のFWを触ると面白いよね。
あーこの部分をこうしてるんだーってFW制作者の工夫が分かるようになる。
そんでもってやっぱSymfonyとCakeは勉強になるチューニングしてあって評価の高さも納得できる。

**nobodyさん** · 2021/06/17(木) 21:18:29.83

Cakeももう少し頑張ってくれたら良いんだけどね

**nobodyさん** · 2021/06/17(木) 21:38:11.06

cakeはなぜ廃れたんだ？
オフィシャルサイトは良さげなのに

**nobodyさん** · 2021/06/17(木) 21:50:39.37

Laravelが使いやすいから

**nobodyさん** · 2021/06/17(木) 21:51:54.09

Cakeと比べてどう使いやすいの？速度は遅いみたいだけど（キャッシュ無しで

**nobodyさん** · 2021/06/17(木) 22:30:37.91

>>650
cakeとの比較だと
・認証周りの機能があらかじめ用意されている
・テンプレートエンジンがあらかじめ用意されている
・フロントエンド周りの環境構築が楽ちん
・ファーストパーティとサードパーティに豊富な拡張パッケージが用意されている
・クリーンアーキテクチャ的な拡張がしやすい
・redisなどの外部システムとの連携の設定が簡単

ぐらいかな。

**nobodyさん** · 2021/06/17(木) 22:47:17.63

>>651
ご丁寧にありがとうございます。
Symfonyと比べるとどのような点が使いやすいですか？

**nobodyさん** · 2021/06/17(木) 22:59:54.02

>>651
ほとんどCakeにも用意されてないか？

**nobodyさん** · 2021/06/17(木) 23:17:38.61

自分で調べもせず楽に知ろうとする教えて君うざいよね

**nobodyさん** · 2021/06/17(木) 23:21:03.55

>>654
どうした大手勤務君
自分が答えられない質問に他の人が答えているのを見て嫉妬しちゃったの？

**nobodyさん** · 2021/06/17(木) 23:25:54.71

cakeは古臭く感じるんだよ
色々用意されていて自由度もそれなりにあるLaravelを使うと他のフレームワークを使う気になれなくなる
homesteadとか環境面も色々あるし便利だなと
個人的な感想だけどね

**nobodyさん** · 2021/06/17(木) 23:36:34.64

>>653
そうなの？なら>>651のうちcakePHPでも十分同等と言える点はどれ？

**nobodyさん** · 2021/06/17(木) 23:45:10.19

LaravelがなかったらCake使い続けてたと思う
Cakeは一般ユーザーとadminを認証し分けるのや別のテンプレートエンジン入れたりするのが面倒臭かった
誰かが作ったプラグインも色々あったがメンテされなくなったら終わりだし

**nobodyさん** · 2021/06/17(木) 23:47:02.69

LaravelのスレでCakeの話するの違うと思う

**nobodyさん** · 2021/06/18(金) 09:16:58.68

まぁ大昔は日本で流行っていた訳だし比較のために出すのは別に問題ない気がする

**nobodyさん** · 2021/06/18(金) 20:50:05.69

大手勤務君ってLaravelにすごい詳しいけどどうすればここまで詳しく詳しく詳しく

**nobodyさん** · 2021/06/18(金) 21:39:38.92

結局バリデーションはモデルでやったほうがベストプラクティスということで決着がついたの？

**nobodyさん** · 2021/06/18(金) 21:42:50.33

そんなこと一人しか言ってなかったぞ

**nobodyさん** · 2021/06/18(金) 21:43:43.75

>>662
きみ、相変わらずキモいね

**nobodyさん** · 2021/06/18(金) 21:45:04.79

Laravelでviewをbladeではなくtwigに変更するライブラリってありますか？
bladeは使っていて違和感を覚えるので変えたいです

**nobodyさん** · 2021/06/18(金) 21:46:18.07

>>662
違う
バッチ処理が必要なアプリ→モデルでバリデーションがベストプラクティス
バッチ処理が必要ないアプリ→FormRequestでバリデーションがベストプラクティス

アプリの構成によってベストプラクティスが変わるという結論だよ

**nobodyさん** · 2021/06/18(金) 21:51:41.54

すみません教えてください　laravelでプロジェクトを作成すると
プロジェクト直下にartisanというファイルがありこれを使ってコントローラ生成したりなど色々行うと思います。
本番環境にアプリを配置する場合このartisanというファイルは削除したほうがいいのでしょうか？
WEBブラウザからartisanファイルが実行されて変なことにならないか心配しています

**nobodyさん** · 2021/06/18(金) 21:55:34.25

>>667
そんなレベルでLaravel使うことのほうが心配だよ

**nobodyさん** · 2021/06/18(金) 21:56:23.91

荒らしはスルーで

**nobodyさん** · 2021/06/18(金) 21:59:25.19

すみません。別FWだと本番環境にモードを設定するコマンドが用意されており
そのコマンドを実行すると開発にしか使わないようなライブラリや開発専用コマンドなどのファイルを
自動削除してくれていたので今まで気にしたことはありませんでした。
laravelだとそのようなコマンドがないようだったので本番リリース時にどこまで削除すればいいのか
わからなくなって質問させていただきました。

**nobodyさん** · 2021/06/18(金) 22:03:06.71

普通はプロジェクトディレクトリ/publicがドキュメントルートなはずだから実行されないと思うけど
実際WEBサーバの脆弱性ついたらドキュメントルートより上にアクセスして実行できるのかな？

**nobodyさん** · 2021/06/18(金) 22:08:03.33

今開発しているアプリがテストデータ程度だと普通なんだけど本番データに近い件数入れたら
なんか一覧を表示する速度が遅いなって思ってたら数年ぶりにN+1を発生させてしまっていたぜ

N+1なんて回避して当然だから自分やらかしていることに気付かず調べてから判明するまで６時間費やした

**nobodyさん** · 2021/06/18(金) 23:07:00.42

eloquentのwithを知らない又は使ったことが無い人は案外いるのかな

**nobodyさん** · 2021/06/19(土) 00:33:52.61

お前らモハメドの話聞いてないのかよ

**nobodyさん** · 2021/06/19(土) 01:04:26.68

LaravelのEloquentにはupdateメソッドとsaveメソッドがありますが
どちらを使うのが一般的なんですか？

**nobodyさん** · 2021/06/19(土) 01:08:31.82

>>675
動作が違うので必要な場面で必要な方を使うのが一般的です

**nobodyさん** · 2021/06/19(土) 02:52:09.97

基本的にはモデルからfind()なりwhere()->first()なり１件取ってきてからsave()かと
複数行が対象とかで無い限りupdate()使ったりしない気がする

**nobodyさん** · 2021/06/19(土) 08:34:10.69

相変わらず、ワケワカラン実装してんなぁ…。
作ってる奴がアホなんだろうなぁ…。

**nobodyさん** · 2021/06/19(土) 09:09:10.30

>>678
ワケワカランてどういうところがそう思ったのか気になるなー。

**nobodyさん** · 2021/06/19(土) 12:41:17.93

saveを使う場合は
$user->fill($request->validated())->save()
というような感じで使えばいいですか？

**nobodyさん** · 2021/06/19(土) 13:01:08.11

初心者はまずドキュメントか本を読んで基礎を学べ

**nobodyさん** · 2021/06/19(土) 14:18:24.11

ずっとjavascriptマンやっていて再びphpに戻ってきたらなんかいろいろ苦しい

**nobodyさん** · 2021/06/19(土) 15:33:42.74

>>680
その使い方だとupdateでも同じでしょ？
自分はfillした後に何か処理挟むならsave、挟まないならupdateって使い分けしてる
あとコントローラー内限定だよね？その書き方

**nobodyさん** · 2021/06/19(土) 16:42:53.66

釣り針デカすぎ

**nobodyさん** · 2021/06/19(土) 16:52:11.13

>>684
>>683
「updateでも同じ」って部分を言ってるなら多分勘違いしてるぞ

**nobodyさん** · 2021/06/19(土) 19:37:14.74

>あとコントローラー内限定だよね？その書き方

はぁ？　場所によって書き方変わんの？
相変わらず、ワケワカラン実装してんなぁ…。
作ってる奴がアホなんだろうなぁ…。

**nobodyさん** · 2021/06/19(土) 19:40:36.23

>>686
お前はせめてPHP初心者卒業してからコメントしろよ
アホなんだからｗ

**nobodyさん** · 2021/06/19(土) 20:34:25.83

>>686
横だけど、requestオブジェクトからバリデートした値だけを受け取っている部分があるから、controller限定かどうか尋ねてるってことでしょ。Laravelのこと知らないなら黙ってたほうがいいよ。どうせお前bigintおじさんでしょ？

**nobodyさん** · 2021/06/19(土) 20:41:20.40

あえて煽る意味あるの？

**nobodyさん** · 2021/06/20(日) 02:25:33.79

Eloquentの更新だったらupdateを使うのが普通でしょ
あえてsaveを使う理由はない

**nobodyさん** · 2021/06/20(日) 03:29:17.83

>>690
そうなんだよね、結局updateの中身だってfillしてsaveしてるだけだから
あえて->save()分のコード量増やす意味ないと思う
それよりも震えるのはプロパティに値セットしてsaveしてる人ら

**nobodyさん** · 2021/06/20(日) 05:56:49.44

>>691
何故？ｗ
そっちが普通やろ
fill()とか常に使っている方が頭おかしい