【PHP】Laravel【フレームワーク】 Part.5
レス数が1000を超えています。これ以上書き込みはできません。
テンプレ追加修正お願いします
Laravel
ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
日本語
http://laravel.jp/
書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)
※前スレ
【PHP】Laravel【フレームワーク】 Part.4
https://medaka.5ch.net/test/read.cgi/php/1613209188/ 俺「ああ…すごく気持ちいいよ、富美男」
富美男が俺のものを、そのごわごわとした手で優しく包み込む。
程良い締め付けと心地良い温もりで、思わず口元が緩んでしまう。
梅沢富美男「バカ野郎が……こういうのはどうだ？チロチロ…」
俺「うぁ…くっ…！！」
富美男が悪戯に亀頭の先端をチロチロと弄ぶ。屈強そうな外見には似つかわしくない、丁寧で繊細な舌使い。
あまりの気持ち良さに、射精感がぐぐぐっと高まるのを感じる。
梅沢富美男「…可愛い顔しやがるじゃあねえかこの野郎…そろそろ仕上げだ。ジュルジュル…ゴプッ！グポポ…ジュルジュルルル！グッポ！ブブブ…！」
俺「ひぁああ…！富美男！富美男ぉお！ぐっ…！！」
富美男が俺の股下で激しく上下する。俺のものはてらてらと光沢を帯び、上下運動を繰り返す度に富美男の唾液と俺の精液が混じり合った、ひどく性的な粘液が滴り落ちる。
限界までいきり立った俺のものは、欲望の全てを富美男の口内に解き放つ。
俺「ああはあっ…！！はあっ！はあ…はあっはあ……！富美男…富美男良かったよ…」
梅沢富美男「…ゴクンッ！……はあっはあっ…てめぇこの野郎！こんなにも一杯出しやがってバカ野郎…腹ん中パンパンじゃねえか…！！…まだ出したりねえよな？」
俺「…富美男には全てお見通しか。敵わないよ、お前には…」
梅沢富美男「当然だバカ野郎…ここからが本当の夢芝居だ」
俺と富美男は、夜が明けるまで、何度もなんどもお互いを求め合った。 俺「ああ…すごく気持ちいいよ、富美男」
富美男が俺のものを、そのごわごわとした手で優しく包み込む。
程良い締め付けと心地良い温もりで、思わず口元が緩んでしまう。
梅沢富美男「バカ野郎が……こういうのはどうだ？チロチロ…」
俺「うぁ…くっ…！！」
富美男が悪戯に亀頭の先端をチロチロと弄ぶ。屈強そうな外見には似つかわしくない、丁寧で繊細な舌使い。
あまりの気持ち良さに、射精感がぐぐぐっと高まるのを感じる。
梅沢富美男「…可愛い顔しやがるじゃあねえかこの野郎…そろそろ仕上げだ。ジュルジュル…ゴプッ！グポポ…ジュルジュルルル！グッポ！ブブブ…！」
俺「ひぁああ…！富美男！富美男ぉお！ぐっ…！！」
富美男が俺の股下で激しく上下する。俺のものはてらてらと光沢を帯び、上下運動を繰り返す度に富美男の唾液と俺の精液が混じり合った、ひどく性的な粘液が滴り落ちる。
限界までいきり立った俺のものは、欲望の全てを富美男の口内に解き放つ。
俺「ああはあっ…！！はあっ！はあ…はあっはあ……！富美男…富美男良かったよ…」
梅沢富美男「…ゴクンッ！……はあっはあっ…てめぇこの野郎！こんなにも一杯出しやがってバカ野郎…腹ん中パンパンじゃねえか…！！…まだ出したりねえよな？」
俺「…富美男には全てお見通しか。敵わないよ、お前には…」
梅沢富美男「当然だバカ野郎…ここからが本当の夢芝居だ」
俺と富美男は、夜が明けるまで、何度もなんどもお互いを求め合った。 開発環境で質問です。
久しぶりにLAMPで開発することになりました。
昔はXAMPPを利用していましたが、
皆さん今はどのように進めていますか？
はやりはDockerでしょうか？ わりと何でも良いが、本番環境になるべく近い環境でやれ
XAMPPはガチの初心者以外は使うべきではない うちも今はDockerだけどWindowsのDocker Desktopが重くてかなわんから
別の何かに変える予定 sailかhomesteadなら割と簡単に環境作れるけど
本番がどういう構成かによっては必ずしも動く保証はないかな 俺は昔からhomesteadやな
楽でいいわ
sailも使った事あるけど別にDocker環境である必要は無いなぁ laravelを続けるのはいいけど、だったらlaravelとは違う別のフレームワーク作って欲しい
だってlaravelが終わるまで、次のフレームワーク開発に取り掛かれないって事でしょ？
laravelを使うのやめた人は、laravelが開発終了して、次の開発に取り掛かるまで待たなきゃいけないって事じゃん
そういう事になるから、長く開発続けりゃいいってもんじゃないんだよな・・・ 他にもフレームワークあるし別に使いたいもの使えば良いのでは？ 今はLaravelが強い
でも2000年代はCakephpが強かった
また変わる気がする 他のFWは進化が緩慢だからこそ後発に追い越されたわけだが、Laravelは利用者を置き去りにする勢いで今も進化を続けている。
むしろRailsより先んじてさえいる。
そう考えるとLaravelが廃れる時はイコールPHPそのものが廃れる時か、コミュニティが瓦解する時ぐらいだろうね、 メンテが大変だから適当なところで枯れてもらいたいが
クライアントだって後々金がかかるもの導入したくないだろう いや、Laravelはメンテ大変じゃないだろ。
Laravel Shift使えば1000円程度でバージョンアップのPR作れるんだし。まぁイレギュラーな作りにしてたら知らんけど。 bladeでpostするときにformの中に@csrfって書くのはわかるけど
<meta name="csrf-token" content="{{ csrf_token() }}">
この記述はどういう用途なんだ？ metaタグのcsrf-tokenってajaxで通信するようなシステムでない限りは
いらないんじゃなかったっけ？ >>25
axiosでxhr通信やるとき用にresource/js/bootstrap.js
に書いてあるから見てみ
querySelector('meta[name="csrf-token"]')
ってのが含まれてる部分 >>28
window.axios = require('axios');
window.axios.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest'
以外ないっぽいです >>31
resource/jsの下ずっと使いまわしてたから知らんかったスマンな 別板にスレが立って正解だったな
こっちが平和になった 加速
ワッチョイ付きの別スレは荒らしが立てたスレなので使用禁止 そうやってスレが分裂したスレこれまで何度も見た
大抵両方が過疎って終わる >>31
axiosが自動で処理するからいらないみたいなことコミット文に書いてるあるけど
本当に自動処理してくれているのか？ laravel-mixを置き換えるかもしれないやつでしょ。 laravel-mixが置き換えられるってことは
laravel-mixも置き換えられちゃうってこと？これからどうなるんだろう laravelは出た時の衝撃度がメチャ凄かったがあれがlaravelのピークやったな
今じゃめぼしい技術も無くなりEloquentやlaravel-mixに頼るだけのフレームワークに成り下がりよったわ
諸行無常とはよく言ったもんや、昔の遺産だけで食いつないでる老舗が売りのフレームワーク（）やん
昔のユーザーを老害呼ばわりしとったらlaravel自身が老害になりよった実にオチの効いた結末や また覚えるの面倒くさいからもう一生Laravelでええわ
簡単なものならすぐ作れるし、簡単なものしか作らんようにする PHPならそうだよな
色々出ても覚えるのが面倒くさい
それならLaravelの新機能とかを覚えたほうがいい >>46
それ単にお前が最新のLaravelの情報追えてないだけだぞ。恥ずかしい奴。 みんなlaravelが凄いかそうでないかで議論しているけどそこどうでもよくないか？
正直laravelは今のままで十分だと思うぞ
重要なのはlaravelが凄いか凄くないかだろう Laravelって名前の由来はなに？
そもそも最初に作り出した人って生きてるの？ サポートなんてあったの？
何をサポートしてくれるんや？ Laravelのサポートに決まってるだろｗｗ
Laravelのコミッター達がお前の家事をサポートしてくれると思っているのか？ いまでも付随サービス（バージョンアップなど）は有料だったし
その中に普通のサポートも金払えばやりますよということでは？ Laravel8.37から無名マイグレーションがサポートされたけどいまいちメリットがわからない
みんなメリットわかる？ >>59
このご時世って言うか、お前が知らないだけでLaravelは色んな有償サービス出してるし、公式イベントも有償。だから少ない人数ながら、それだけで食っていけるぐらいにしっかり儲けているぞ。
それ以外にgithubのスポンサー制度で億単位で儲けてる人も居るしな。livewireの開発者とか。 オープンソースFWって凄腕の暇人達が余興で作ってるのかと思ってたが当たるとちゃんと儲かるんだな
俺もクソクライアントのしょーもないシステム受注開発とかやめて、道具を作って儲ける方にシフトするかなあ >>64
やるなら英語圏をターゲットにしないとダメだぞ。日本語のみでもスポンサーなってくれる人はいるけど、まぁ少ないよね。海外はOSSの収支報告するためのプラットフォームもあるぐらいなので、それなりにビジネスになってるっぽい。
ただ英語圏ターゲットにしてもスター沢山ついてるhiroppy/fusumaにはスポンサーついてなかったりするので、海外のやり方を研究したほうが良いとは思う。redditで作ったもんを宣伝したりとか。 よっぽど革新的なもの作らないと中々ねぇ
かと言って良い物でも使ってもらえるかは分からんしな ある程度のロビー活動的なもんは必要だろうな
コミュ障には無理だろう 昔はsynfonyの金魚のフンだったのに
今は大きくなったな >>69
すまん。1桁間違えてたwww 1年で110kドルだったわわ。 メジャーなフレームワークだからlaravelを選択する人が多いと思うけど
メジャー以外の理由でlaravelが他フレームワークに勝ってる点ってどこだと思う？ >>71
そこが何気に重要だよ
調べたら大抵の情報はあるしね cakeなんて今更使う気にもなれない
それならフレームワーク無しでやる 別にCakeの天下が続いていればCakeでも俺はよかったけど
変なのさえ避ければFWなんてどれ使っても大して変わらん laravel使う意味自体、長いものに巻かれる以外に見いだせてない Cake2→Laravel5に乗り換えたから便利になったように感じたけど
最新のCakeなら機能増えて同等になってるかも知れんし、そのあたりは知らん
開発に忙しくて他のチェックまで手が回らん >>76
最近は顧客側がフレームワークだけ指定とかあるくらいだから
信頼性や普及度からして間違いないみたいな所はあるかもね >>78
顧客側も長芋に巻かれろくらいにしか思ってないよ >>73
早さはcakeに負けてるとか言っちゃうの、だいたいOPcache使ってない人なんだよなぁ。
https://kinsta.com/jp/blog/php-benchmarks/ >>81
これはphpのフレームワークの速度を比較してるんでなく、phpのバージョンごとの速度を比較してるベンチマークだよね ただOPcache使った場合、cakeのほうが速いと言えるほど明確な差は出ない。 >>77
どう便利になったの？乗り換え検討したまま何年も過ぎてるんだが >>86
composerベースになったのは便利だよね laravelのいいところってどこだって言ってる？
なんか、『laravelは基本的にdirectory構造を自由に設計できる』ってのがあったんだけど、
そしたらそれ、もう、フレームワークじゃなくてただのライブラリ利用だろ？ みたいな話になってくる。
フレームワークって元々、『どこ行ってもおんなじ仕組みなので学習コスト低いですよね？』みたいなところが利点だったと思うんだけど、
現場ごとに毎回その現場の流儀を学習する必要が出てくるんなら、
なんかお前、言ってる事違うだろ？ってならないの？ >>88
modelの話か？それならLaravel8でmodelsディレクトリに格納する事が決まったわけだが。 Laravelの良いところなんて実務で使ったことある奴なら簡単に挙げられるだろ。
・フルスタックフレームワークである
・認証周りがファーストパーティから提供されてる
・他システムとの連携が簡単にできる
・サードパーティパッケージが豊富である
・初心者でもある程度セキュアな実装ができる
・公式マニュアルの出来が良い
・テストするための環境を作り易い
・開発環境を作り易い .gitignoreを修正して.env、node_modules、vendorをコミットし
composer.lockやpackage-lock.jsonをコミットしない開発者が多いのがlaravelのデメリットだな
emailにユーザIDぶち込むアホやvendor直下修正してユーザID認証に変更する馬鹿開発者も多いな laravelが世界で一番使われているからといって安易に実務に導入するアホいるけど
世界で一番使われているフレームワークなんだから実務でもlaravelを使ったほうがいいと思う >>90
これだよね。一般的に使う機能が本体に組み込まれてるのがでかい。
最近はsanctumとかAPIに使える機能とかもあるし、安全で将来性のあるライブラリを探し回らなくて済む >>93
あと書き忘れたけど、バリデーション、文字列操作、配列操作、コレクション操作用の処理を標準で用意してくれているのもありがたいわ。 >>94
その辺が標準であることが最大のメリットだね
チーム間で無駄な調整が不要になる 問題なのはLaravel 8の本が出版されてないこと
メジャーバージョンごとに出してくれ >>86
Cakeだと何するにも有志の作ったプラグインを探して入れるのが当たり前だったが
Laravelだとデフォでなんでも入ってるのがいいと思った Laravelの場合公式のマニュアルが有用なので、本なんか要らないと思うぞ。 今年出る9がLTSだから、それに合わせて数冊本は出るだろうね でも機能的にはcodeigniter4に劣る気がする homesteadとか開発環境周りのものも色々あるしmixなんかもvueとか使うなら設定も簡単だしフレームワーク以外の部分も強力かと思う >>90
おれ、Laravel って使った事なくてさ、
Rails、Cake、CodeIgniter でも、簡単なプロジェクトなら別にどれでもいいんだよな。所謂『WEBアプリ』って言ってるレベルの物。
これが、『WEBシステム』になったときに Laravel プロジェクトだとどうなるのかな？ と思ってさ。
例えばWEB業務システムERPです、管理画面です、大メニューが10個、サブメニューが全部で50個、アプリケーションとしてのエントリポイントは総計で1000個超えます、
みたいになった時に、
Laravelプロジェクトのディレクトリ構造、どうなるんだろうな？ と思って。
それが『laravelは基本的にdirectory構造を自由に設計できるって聞いた』を上げた理由。
Rails、Cake、CodeIgniterあたりでやってると、確実に崩壊するんだよな。
そういう用途で使ったLaravelプロジェクト、見たことある奴居る？ ただまぁ、Laravel も 8 にもなって、流石にそろそろ安定してきただろうから、
いい機会なので使ってみようかとは思ってるんだけどな。
今、身動き取れない状態だから時間割りとあるし。
4とか5の頃から『しょっちゅう仕様変わる』って聞いてたから、
必要性が無い間は触らなくていいや、って、今に至ってる。
Vue.jsの最初のヴァージョンも、使い始めてやっと覚えたってところで、
2 になると仕様がごそっと変わります、とか言われて『えー！？』ってなってそれっきり。
実は、正しい使い方してれば jQuery が最強なんだよ。（データバインディングを考慮しない場合）
結局、実装してる奴が無知・無能だから大抵崩壊してるだけだからな、どのプロジェクト見ても。 >>107
それは単に、たくさんの機能を追加するうちにFWの想定してない例外的なフォルダー構成にせざるを得ないケースが出てきてるだけであって、規模と本質的に関係ないことじゃないか？ エントリポイント1000超えるシステムをモノリシックで運用するのが辛いみたいな話になるから、Laravelであっても他のFWと大して変わらんだろとしか。 公式のマニュアルが優秀って話があるが、
日本向けの公式マニュアルは情報が遅れてないか？
勉強しようと思って見たら、1バージョン過去のもので諦めた覚えがあるわ >>109
まぁ、そのとおりだな。
システム開発って結局、作ってるうちに、運用してるうちに、コロコロ仕様変わってくし、
システム作る事が目的じゃなくて作ったシステムで世の中を便利にしてく事が目的だから、当然、そうなるんだよな。
そん時に、結局、最初にどんだけ柔軟性を考慮して設計したかが全てです、ってなるなら、
やっぱ、Laravel も他のフレームワークと五十歩百歩じゃん、てなるんだよ。想定してるシステム規模がでかいと。 だから、みんな『良い』って言ってんだから、良い事は間違い無いんだろうけど、
世間の皆さんって、PHPでデカいシステム作る事あんまり無いからさ。大体そういうエンタープライズ用途は『Javaです』とか言って何十人規模でコードがゴミ溜まりみたいになってんじゃん。Javaって、何するにもめんどくさい言語だから。
もぅ、そういうの、辞めねぇ？って思ってんだけど、まぁ、無理なんだろうな。 >>114
PHP 8でOpecache拡張のJITコンパイラ搭載されてるから、速度面でも申し分なくなるじゃん。
そしたらLaravelがなんか、解決してくれたりすんのかな？ って思ったんだ。 速度面ではあくまでインタプリタだし昔に比べたら早くはなったけどLaravelは速度とかよりは開発のしやすさの方を重視していると思うので
どうしても高速でないと駄目とか言うなら選択肢には入らないのでは？
どっちにしてもDBに接続するならそこまで速度がどうのこうのは関係なさそうだけど >>118
いや。Twitter作りたい訳じゃないから、Javaの速度は、ほとんどの環境では流石に要らないよ。
一般的な用途なら、PHPのJITコンパイラで十分になるだろうって話。 >>117
やっぱ、そうなるか。
そうすっと、小さいWEBアプリ用と割り切って使うのが結局のところの正解になるんだろうな。 日本語マニュアルはページ内リンクもないし読みにくい
本家と同じデザインでレイアウトで文章だけ若くに差し替えるだけのほうがメンテナンスしやすそうな気もするし
本家に取り込んでもらえる気がするんだよな それなりの規模は作れると思うけどね
Laravelじゃないけどグラブルみたいな超絶にアクセスがあるゲームですらPHPで捌けているし
アプリケーションサーバーはロードバランサとかで分散できてもDBはそのへん中々大変だろうから
結局はPHPというよりインフラの設計とかそっちも重要かと お前らって英語わかんないの？
日本語だけで技術者なんて、やっていけないと思うんだけど ジャップランドはIT技術後進国
低レベルしかいないし、この先どうなんだろ >>120
どんなFWでも、その規模になると設計する側の腕次第だぞ。一方でLaravelの場合バージョンアップへの追従が大変という側面を忘れてはいけない。Laravel-shiftである程度楽はできるだろうけど。
大規模案件でパフォーマンスを要求されるようになるとそれはそれでツラミがあるけど、OPcache前提ならそこらのFWと大して変わらんだろ。
その上で最近ベータリリースされたlaravel-octaneがswooleやroadrunnerを簡単に導入できるパッケージなので、速度面はむしろ他より速くなる可能性もある。 Laravelで開発した有名サイトってどれ？
ランサーズとかBASEがCakeなのは知ってる どういう設計か確認したい。URLからでもだいたいわかるし > ランサーズがCakeなのは知ってる
しょっちゅうバグってCakeのエラー画面出るからな。
あれ、エラー画面変えられないんだっけ？
Apacheのエラー画面そのまま出てるのも脱力するけど、
Cakeのエラー画面も似たようなもんだな。 >>132
ごめん、ランサーズの事、間違えて悪く言った。
おれが指摘したかったのは teratail の方。
あっこ、システムエラー、多すぎ。
ランサーズはエラー画面出てるのは見たことないな。
秋好さん、結構がんばってんだなぁ…、と思うわ。 >>132
普通にエラー画面変えられるよ
デフォルトが出てくるのは、単に設定してないだけじゃないかな 本番環境でフレームワークのエラー出すとか考えられんだろ
phpのエラーも非表示にするし、一度もそんな所でミスったことないわ 本番環境と開発環境ってそれぞれにファイルアップロードしないといけない？ >>137
盛大な teratail ディス、ありがとうございますｗ
あっこ、技術者のコミュニティを謳ってるはずなのに、
運営が技術力全く無いですって、
ちょっとひど過ぎるわ。 laravelってマイグレーションでは複合主キー設定できるのに
Eloquent等のfindとかで複合主キー検索できないのは何ですか？
これはlaravel7や8だとできるようになってるんですか？ テラ何とかって質問自体異様にレベル低くてその割にまともな回答も付いてなくて
検索の邪魔になるだけのクソサイトだよな
ぐぐってもURL見て開かずに自然に避ける癖がついちまってる .envコミットするしないで議論に決着がつかなかったこのスレほどではないわｗｗ あれは単に愉快犯に荒らされてただけだろ
本気でコミットしようとしてる奴なんておらんよ .envをコミットするという発言に対して誰も論破できないのは草だった
それぐらい論破しろよ・・ 実際.envをコミットするという発言を論破することって不可能じゃないか？ 負けを認めない奴を論破するのは不可能
安倍や自民党見てるとよくわかるだろ .envはコミットしたほうがメリットデカいと思うけどな
node_modulesやvendorコミットしているやつは馬鹿だけど いや.envをコミットするやつはアホ
node_modulesやvendorのコミットはむしろ推奨
なぜならnpmやcomposerで外部からパッケージを取得できない環境でも
アプリを動かすことができるから 多様性を認めない昭和な人が多いインターネットですね >>149-151が荒らしの自演
これを延々繰り返してきた、またやるつもりか また.envをコミットするなとか言う老害現れたよ
そんなの現場次第だろ >>154
荒らしがわざわざワッチョイ付きでレスすると思うか？
.envコミットするとか言ってる奴らはどうせほとんど自演だろうな と思ったけど向こうのスレはかっそかそで荒らしすら居なかったわw .envをコミットしたほうが良いと自身で思い込んでる奴が居るってのはまだ分かる。
個人的に一番謎なのは、客や上司の指示で.envをコミットしてるけど、自身は.envをコミットしたく無いって奴ね。
前スレにもちょくちょく居たけどさ、頼まれたらなんでもするのか？ 複合主キーはあきらめてサロゲートするしかないのではないかね？ >>160
客が.envをコミットしろって言うケースがそもそも分からん
そんなこと客は関心無いと思うんだが >>162
どちらかというと関心ないからこそ.envをコミットしてくれって依頼があるのでは？
そうでもないと.envコミットに関心がないことになってしまうわけで 言われて思い出したけど、そうそう、
PHPのフレームワーク、ライブラリで“複合プライマリキー”に対応してるの、見たことない。
確かRailsのActive Recordもそうだよな？ 確か。
『これ設計した奴、何考えて作ってたんだろう？』といつも思ってた。
>>141
> できないよ。複合主キーサポートすべきだｔってissues作られたけど却下された
> https://github.com/laravel/framework/issues/5355
どうして却下しちゃうかなぁ…。 >>146
.envの件はどの環境でも同じ値使ってるから.envコミットしたほうが良いとか言ってたので、それならconfigのデフォルト値に書くべきって言われて反論できなくて終わったはず。 .envをコミットするメリットデメリットを説明して上司を納得させられないんだろ多分。日々の業務でいっぱいいっぱい >>156の上司もなんか意図があってコミットさせてるんでしょ 知らんけど 意図が全く無い行動をする人間の方が、今の日本では圧倒的多数派なんだよね…。 >>171
なにしろ「前例に従う」のが大好きだからね
違うことをして失敗したら、吊し上げられるし （相手が意味を説明出来ないからに決まんじゃん。。。） >>165
Hibernate由来のDoctrineも？ Laravelのissuesによるとそもそも複合主キーができちゃうようなテーブル設計をするほうが悪いから
サポートしないとのこと > そもそも複合主キーができちゃうようなテーブル設計をするほうが悪いから
なんすか、これ？
そんなわけないじゃないっすか。
まともなDB設計、した事ないんすか？ Laravel開発者は？
馬鹿しか居ないんすか？ 使う人間がフレームワークを選ぶというよりは、フレームワークが使う人間を選ぶんだよな 俺個人は複合主キー使わないけど>>178はおかしいと思う
なんでそんなの言い切れるんだ？ なんでコントローラファイルの置き場所が
app/Http/Controllerなんだろうか？
他のフレームワークみたいにapp/Controllerじゃないのには理由がある？ >>179
Laravelどころか基本的にORM開発者はみんな複合主キーはテーブル設計が悪いって結論に至ってるからサポートしないのが多いんだよね そういえばCakeもそうだったような
初めて使ったFWがCakeだったんだが、そういう不便さを我慢しても高速に開発するために使うのがFWってもんだと思ってた
「複合主キーはテーブル設計が悪い」という意味不明の信念があったとは知らなかった、DBちゃんと勉強した人間ならおかしいと思うよな ORM開発者は複合主キーではなくユニークキー使えよって感じだよね 主キーは主キーでUUIDでも使えば良いんじゃないの？
知らんけど 複合ユニークは使えるんだしそんなに問題になった事はないなぁ
サロゲートキー自体が好きでないという層はいるよね >>185
> Laravelどころか基本的にORM開発者はみんな複合主キーはテーブル設計が悪いって結論に至ってるからサポートしないのが多いんだよね
そんなの、嘘うそ。
ORM開発で必ず問題に成ってくるのが『JOINをどうするか』問題。
DAOもActiveRecordも、基本は １テーブル対１Class、つまり、ORMが『テーブルに対して』紐付いている。
その設計では基本的に『JOINが実質出来ない』。エンティティもテーブルに対して紐づく為に、が対応できなくなるから。
だから、DAOやActiveRecordのアプローチでORM開発してる奴らは『JOINさせたくない』ので、複合プライマリキーを認めたくない。
例えば商品の注文場合、最低限で考えても必ず
注文伝票のプライマリキー：order_id
注文商品のプライマリキー：order_id, item_id
となる。
これをしないデータベース設計なんか見たこと無い。
これを『テーブル設計が悪い』って言う奴が居るとしたら、そりゃもう、『おまえ、脳みそ腐ってるだろ？』としか言えない。 複合主キーでなくともJOINはできるだろｗ
JOINの件は複合主キーとは関係ないよ >>190
長ったらしく書いてるけど注文のテーブルだったら
ordersにid,注文関連の情報など
order_detailsにid,order_id,item_id,countなど
このorder_idとitem_idが複合ユニークにすればいいだけちゃうのか？ >>191,192
あのさぁ、お前達の読解力なんとかしてくれ。
> 複合主キーでなくともJOINはできるだろｗ
> JOINの件は複合主キーとは関係ないよ
その通り、JOINには直接は関係ない。
1. 普通のテーブル設計すると、テーブルに従属関係が出来るので、複合プライマリキーは必ず必要になる
2. テーブルに従属関係を作るのは、主テーブルのレコードに紐づく従属テーブルのレコードを関連付けてSELECTしたいから
3. 当然、JOINしたくなる
4. テーブルに紐付いているORMだと、SELECT結果がORMの設計理念から外れるため、JOINを実装しづらい。
これを逆算すると、1を禁止するのが一番良いという結論にたどり着く。
自分でActiveRecordパターンのORM作ってみれば、はっきりと分かる。
『あ、そもそものORM設計間違ってた』って。でも、後戻りは出来ない。
PHPは元々メンバ変数を動的に作成できて
例えば結果を \stdClassオブジェクトに対してマッピングすれば、無理やりJOINを実装しても破綻しないけど、
それは結局、場当たり対応以外の何物でもなくなる。
> このorder_idとitem_idが複合ユニークにすればいいだけちゃうのか？
それ、妥協案っていうんだよ普通。そうすれば確かに問題は起きないだろうな。
でもな、
お前の上げたその解決法の事“こそ”を、世間一般では『テーブル設計が悪い』って言うんだよ、普通。
RDBの思想に、明らかに反してるだろ。本末転倒なんだよ、お前の言ってる事。 別に嫌なら使わなければええやん
SQLアンチパターンに忠実な人はこんなの使えんだろうな >>194
だから使ってなかったんだって、Laravel自体。
自分でORM書いて使ってるから。
>>195
いや、頭悪いのどうみてもおまえだろ…。
ほんと、5chってこういう奴多いよな。自分のバカさ加減棚に上げてる奴。疲れてくるわ…。 >>196
使ってないのになんでわざわざLaravelスレに文句言いに来たの？ Laravel 8の再翻訳って終わったんだね
やる気すごすぎ ナチュラルキーにしても複合キーにしても、実装上のメリットなんてほぼ無いだろ。既存はともなく新規ならサロゲートキーで良いじゃん。 >>200
サロゲートキーが悪みたいなやつが文句言ってるんやろうな >>198
プログラム板のPHPのくだらない質問スレにRubyのことしか書けない、スレ違いの頭のおかしな人が居るんだけど
>>196からム板のキチガイと同じ匂いがする だーめだこりゃ。
Laravel使い、アホしか居ねぇじゃん。 やっぱりこいつか
マウント目的のクズ
相手にするだけ時間の無駄 >>203
アホの俺にナチュラルキーや複合キーを使うことによる実装上のメリットを教えてくれ。頼む！ それはDBスレでやってよ
NULL撲滅委員会の人たちとかと一緒にキャッキャやってくれ
ここはLaravelのスレなのでそんな話はいらん
まだ.envコミットするしないとかの方がマシw >>206
そいつ、思ってることがうまく表現できなくて、某サイトで「ウキー」って言って垢バンされまくってるチンパンジーだから、関わらないほうがいいぞ。 LaravelのRouteServiceProviderのHOME定数だけど
これって名前付きルート使えないのか？ サロゲートキーどうやって生成すんの？ って問題がある。
オートインクリメントとか言い出す奴はまぁ、脳みそ腐ってるわなぁ。
そういう奴って何にも考えてないからそうしてるので、普通にINTオーバーフローとかやらかす。
つーか、論理的に必要ないカラム要求すんな。 サロゲートキーをオートインクリメントで作るやつは脳みそが腐ってる？また荒らしかよ。やれやれ。 >>212
サロゲートキーを生成する処理に、idメソッドではなくincrementsメソッドを使ってるヤツにはその話通じないぞ。あれはLaravel7から追加されたはず。 >>215
いや6にもbigIncrementsがあるけど >>216
Laravel7からサロゲートキーを作るためにidメソッドとforeignIdメソッドが作られてbigintが強制されるようになったって話。
それまでは複数タイプのincrementsメソッドを好きに使えってスタンスだから、必ずしもbigIncrementsで作っているとは限らない。事実、認証スカフォールドで生成されるusersテーブルのidもint型。 それだけユーザーかかえるようなサービス作れたら幸せだし、そんなの些細な問題だわな
しかし、この人は話題が尽きたところで面白いネタぶっ込んでくるねw やれ「.envをコミットすべき」だの、
やれ「jsonレスポンスは危険だの」だの、
こういうのって荒らしがネタで書いてるのかと思ってたけど、今回の「サロゲートキーをautoincrementするのは脳みそ腐ってる」は前レスからの粘着具合を見ると真正っぽいな
まさかとは思うが同じ人物じゃないよな >>219
お前がどこまで理解して書いてるのか知らんけど、.envをコミットしたほうが良いプロジェクトもあるし、phpのjson_encode()はデフォルトだとRFCに準拠してない
.envに関しては前スレでもいろんな環境が聞けて、俺としては面白かったけど、お前は楽しめなかったみたいだな 面白い環境なんてあったか？
コミットしろと上から言われてる奴ぐらいしか覚えてないわ >>220は荒らしでしょ。.envをコミットする合理的な理由を説明したやつは皆無だったし、jsonの件はそもそも論点ズレてる(わざと？)。 >>220
面白い環境って言っても動物園感覚だっただろ
大喜利としての面白さは求めてねーよ オートインクリメント枯渇したことないけど本番環境の人ってどうしてるんだろう
あれって枯渇してしまったら終わりだよね BIGINTでも枯渇するならそれはそれである意味スゲぇな BIGINTが枯渇するレベルまで行くと遅延酷くてまともに使えないと思うぞ
枯渇以前の問題だな .envは環境を記述する箇所だから、それ自体をログとして保管する必要があるプロジェクトはコミットしてるって記述が複数あっただろ
面白いのは、極小プロジェクトとどでかいプロジェクト(というか企業？)の双方で需要があったってこと
・極小側は、納品物としてコミットしてしまいたい
・どでかい側は規約やルールに縛られてコミットが必要
プロジェクトの上流からいつ指示されてもおかしくない箇所だから、そのときに優先的に検証する対策があるのはすげぇ貴重だったわ INT でオーバーフローが懸念されたので BIGINT型に変更したのは Twitter くらいしか話を聞いた事は無いけど、
俺が言ってるのは、オートインクリメントでプライマリキー作るような奴はそもそもデータ型に対する理解なんか一切無い場合が殆どだから、
INT型の範囲がどの位あって、何年で溢れそうか？
みたいな計算一切せずに、何となくINT型にする馬鹿だらけだろう、って話。
で、問題が発生してなにが起こったのかすら分からず、連日徹夜で闇雲に調査してやっと気付いた時には大問題、みたいな、恒例のパターンになるだろ？って事。 >>229
その場合、コードの中に入れる合理的な理由を説明できたやつはいなかったよね。客がそう言ったから以上の話は出てきていない。 >>230
え？お前はbigint知らなかっただけでしょ？言い訳乙。 >>225
bigintは大抵のRDBMSで8バイト（922京以上）になってるけど、これを100年以内に使い切るには1日あたり252兆以上のレコードを挿入しなくてはならない そうずっと、何が問題かっつったら、値が有限な型をキーにするって発想が狂ってるので、
BIGINTなら溢れねぇからオッケーだろ？って奴は、そりゃ、脳みそシメジなんだろ。 >>233
ほら、すぐこういうチンパンジーが鳴き出す。 >>237
bigInt知ってたらそれを前提にしてオートインクリメントの批判をするよね？bigIntでオーバーフロー？？て突っ込まれてから、長文で言い訳始められてもなぁwww 必死だなぁ。なぜID真っ赤にして連投するんだろ。粛々と批判すれば良いだけなのに。 >>232
別にコミットする理由が合理的である必要ないだろ
でかい企業だと普通にありえるルールだし、その場合は「企業全体で合理的」であるだけで、各プロジェクト単位で合理的な場合なんて殆どない
対処方法が合理的かどうかは重要だけど、環境変数で読み込むファイルを切り替える方法は十分合理的だと思う
ドキュメント見る限り問題もなさそうだし、必要になったら最初に検証するとだろうなぁ AmazonやGoogleもインクリメント使っていてINTからBIGINTに変更したな >>230
別にbigintでAIの主キー持つテーブルなんて何にも珍しく無いんだが…
うちで作ってるBtoC向けのサービスも会員が操作したりすることでレコード作られるテーブルは全部bigintだよ
まぁintでも十分だと思うけど
仮に100年以内にint（4byte = 2^32）を使い切るには1日あたり5.8万レコード挿入する必要があるな >>241
まぁ、Laravel無いと何一つまともに作れないお猿さんは、Laravelの仕様を否定されたら自身の根幹が揺らいじゃいますもんね。
かわいそかわいそ。 >>248
あなたは技術レベル高いから自作のフレームワーク作ってそうだね >>248
お前は先日、ORM自作しててLaravel使ったこと無いって言ってたっけ？ >>248
もし俺の勘違いだったら申し訳ないけど、
君は前スレか前々スレあたりでベトナムのエンジニアに業務委託したらLaravelで作られたことに怒ってた人と同じ人？ >>245
合理的な理由が無いなら、やる必要もないって話。わざわざgitignoreされてるって会話もしたような？現に本番環境だけならconfigのデフォルト値に設定するだけで事足りるでしょ？ >>247
うそつけ。
ほら、こういう馬鹿が必ず湧いてくるとおもってたんだよ。
お前のDBのオートインクリメントは『マイナスの値』とるのか？
Unsignedにすれば良いだろ、とか寝言言い出すんだろうけど、
そしたらBIGINTどうすんだよ？アプリ側で受けられねえだろ？
みたいな、すげぇ適当な試算しか出来ねぇ奴ばっかだろうから『オートインクリメントをプライマリキーにする奴は脳みそ腐ってる』って言ってんだよ。
ちゃんと設計出来るなら、そいつがそうしたいっつってんだから、そいつの中ではそれが正解なんだろ。
俺がしてるのはそういう話じゃねぇよ。 >>254
> そしたらBIGINTどうすんだよ？アプリ側で受けられねえだろ？
すまん、この一文が何言ってるのかよく分からん >>234
今出先だから計算してねえけど、これもどうせUnsignedだろ？
アプリ側で受けられなぇだろ。
馬鹿か？ >>256
お前のPHPのint型、Unsigned指定出来んのか？ まあ、現場の人でないのは明らかだけど
上流にこういうこじらせた人いるとさらに大変なんだよなぁw >>257
いやsignedだよ、64bit=922京くらいはメジャーでしょ >>253
プロジェクトとして合理的かどうかはともかく、企業として合理的な場合があるんだよ
プロジェクト単体で見たときには理不尽に見えても、企業全体で見たときにガイドラインが揃っていることによる最低ラインが保証されていることは多くの場合メリットになる
で、大抵の場合はガイドラインの背景は、末端には知らされないので合理的でないように見える
「本番オペレーション時にはコマンドを声に出して読み、2名以上で確認しながら作業」とか
「HDD交換時は、データセンター内でデータ消去作業を実施した後搬出」
「事前にチェックリストを作成し、承認された作業以外は実施不可」
とかと同じだな
全部非合理に見えるだろ？
場合によってはめちゃくちゃ合理的なんだぜ てか、さっき俺、間違えたか？
int 21億って、signedだっけ？
したら、それについては勘違いしてたの、俺。 63ビットを詰め尽くすデータを想定しているシステムw
キチガイは実際にモノ作ってないのだろうな >>262
お前が提示した例の対極にあるのが.envコミットでしょ。ポカヨケにもなってる予防策を外してわざわざコミットするわけだから。どんな角度から見ても一切合理的では無いって断言しておく。 >>267
ポカヨケってクレデンシャルの流出の話を言ってる？
それは別で検討すべしって前スレで散々言われてるだろ >>260
>>233の説が正しいことが証明されたな >>269
え？ローカルの設定で上書きしちゃうケースを想定できないの？ >>271
それ想定しなきゃいけないレベルだと、コードレビュースカスカだろ
何言い出してんだ？ >>232
合理的かは知らんが、git cloneしてすぐ動くことが求められるから
.envもvendorもコミットしてるって奴がいたような >>272
え？お前は毎回コードレビューでローカルの.envをしてないかどうかまでチェックすんの？してたらリジェクトして再コミットさせるの？時間の無駄では？ >>274
ほんとお前何いってんだ？変更箇所チェックしないわけ無いだろ >>273
それもconfigに書いてりゃ済む話。環境の違いを吸収するのが.envの目的だから、git clone後にすぐ動くようにしたいなら、わざわざ.envで定義する必要は無いんだよなぁ。 >>275
え？人間が見なきゃいけない範囲を減らすって発想が無いの？マジ大丈夫か？ >>277
そのための工夫が、「ファイル名を分ける」だろ
対応として非常に合理的
あまりわかってないみたいだけど、「.envをコミットしなければならないプロジェクトがある」ってとこからスタートしろよ
話が噛み合わん >>278
そのプロジェクトは客や上司がそういうからって思考停止してるだけでしょ。合理的な理由があってそうしているわけではない。だから.envコミットに合理的な理由は存在しないて話になるわけ。 補足しておくと何らかの理由があってそうしていること自体は認めている。俺はやらんけど。
ここで言いたいのは、あくまでも合理的な理由は存在しないよねってだけ。そこで抗弁するのは見苦しいから辞めろ。 >>273
そこまで知識が無いやつがいてもなぁw
composerやらjsフレームワーク使ってたらnpmやyarnの事知らない奴とか要らないよw
.envも導入マニュアルとかをwikiとかで書いてあったりすることが多い気がするけどな >>279
殆どの場合、イレギュラーを許すよりガイドラインに沿った対応をさせたほうが全体として合理的
ガイドラインの矯正は、どうしても単独プロジェクトとしてみた場合は理不尽な箇所が出てくる
が、最低ラインが保証されてるってのは、それだけででかいメリットになる
「.envをコミットしなければならないプロジェクトがある」ってとこからスタートしろよ
話が噛み合わん
そこが解ければ、対処方法を実績として書いてくれてるやつのコメントが面白いってわかるようになる >>280
こいつコーディング規約とかも無視するんだろうなｗ >>273
これって本番環境も含めての話なのかな？
むしろリスクの方が高そうだが
すぐに動くことを求める意味が分からん
まあ、勝手にやれば良いとは思うが 複数のコントローラで共通の処理をどこかにまとめたいんですが
どこにまとめるのが良いでしょうか？ >>282
それは合理的ではなく単に合理性の欠けるガイドラインに従っているだけ。思考停止ってやつだね。なぜそうなっているかを具体的に調べて評価して、初めて合理的かどうかということが言えるわけ。 >>285
traitかhelper。役割に応じてどっちに書くか判断して。 >>286
その評価って、ここで議論して意味ある？
大抵の場合、根源はトラブル対応から記録を残すって対応が生まれてるんだろうけど、Laravelとは関係がない
関係があるのは「そういったルールが、デカイ企業だとそれなりにある」ってことで、それに対処する方法が前スレで提示されたってこと >>283
俺はそうしなきゃいけない理由自体は否定していないからな。もう一度よく読め。国語力低すぎるぞ。 >>284
普通はvendorやらnode_modules何かをgitに上げてたら容量がえぐい事になるし
ネタなんだろうとは思うｗ
>>285
どう共通かにもよるけど、親クラスを作ってそれを継承させる方法の方が良い場合もある
その親クラスは普通にControllersに置いててもいいかも >>289
インデントをタブでって言われたらブチ切れる人だろ？知ってるｗ >>288
それを言い出すとLaravelと関係無いイチプロジェクトの事情で.envをコミットしてます！て言われましても・・・てなるけどな。 >>292
だから言ってんじゃん
関係があるのは「そういったルールが、デカイ企業だとそれなりにある」ってことで、それに対処する方法が前スレで提示されたってこと
ナレッジの共有を否定するのはアホだろって話 >>293
誰もそこ否定してないって。.envコミットするのは合理的じゃないよね。でもやりたいやつはやれば？て話。あとナレッジって何？.envコミットしている側からナレッジなんて一切提供されてないだろ。 >>294
ってことは、君は
・.envをコミットしなければいけない環境があることは理解している
・.envをコミットしなければならない環境の合理性は理解できない
・前スレに提示されたナレッジは見えてない
って状態かな？ >>295
俺は「.envコミット派からはナレッジ提供されていない」と言ってる。そこ間違えないでくれよな。 >>273
どのみちcloneしてからmigrationやらdockerコンテナ作成したりするんだから、文字通り「cloneしてすぐ動く」ってのは誤りだと思うけどな
例えばdockerその他ツールのポートが競合してたりして、どうせ環境依存の変更は必要になるだろ >>297
まとめてくれてるやつまでいるのに目に入らないの？
君が言った「.env上書きしたらどうすんのよ？」に対しても「ファイル名を別にして管理する」っていうナレッジが提示されてるやん >>299
俺297とは別人だけどまとめてくれてるレスがどれか分からんかった
どのレスにまとまってる？ >>299
お前はアホなのか。それも環境ごとにファイル用意して管理て話だから、.envコミット否定派のナレッジなんだが。後、まとめてくれてるやつってどれ？ >>301
えｗ理解できてないの？
.envをコミットしなければならない環境で、どう管理するのが良いかってナレッジだぞ
コミットの否定なわけ無いでしょ 
Q. Should I have multiple .env files?
A. No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test.
Your config should vary between deploys, and you should not be sharing values between environments.
辞めたほうが良いよってdotenvの公式にも書かれてるけどね
どうしてもそうしたいなら好きにすればいいと思うけど、それはあなたのプロジェクト内の話であってデファクトみたいな顔すんのは違うんじゃねーの？ ド直球のバッドノウハウをドヤ顔で「ナレッジ」と主張するのは草 >>304
デファクトの話は今してないよ
.envをコミットしなきゃならないプロジェクトに置かれたときに、前スレに有用そうな情報を提示してくれている人がいるってことと、世の中にはコミットしなきゃならないプロジェクトがあるってことを延々と説明させられてる
有用そうな情報を提供してくれている人がいるのに、それをまるっと否定するやつが邪魔なだけ .envコミット否定派は、.envという.gitignoreされているものをわざわざコミット可能にするのは意味がないって言っているわけよ。理由は以下だ。
・環境ごとに異なるから
・クレデンシャル情報がコミットされるリスクがあるから
それに対して、.env.prdや.env.stgて別ファイルにして管理してますってのは.envコミット賛成派の意見なの？ .envをgitに入れてる事自体が一般的には異常なのにな
こういう奴らはsshのprivate keyとかも平気でgitに入れてそうで怖いわｗ >>308
そりゃそうでしょ
そもそも各環境の.envをコミットする必要がなければ、、.env.prdや.env.stgて別ファイルにして管理する必要もない >>308
賛成派っておかしくない？ここ一連の流れでは、「必要があるからコミットする」って説明しかしてないんだけど？ そんなわけあるか。事実、.env.exampleの存在を否定派は認めていたでしょ。否定してたのは.envてファイルそのもののコミットだよ。 >>312
君、やっぱり日本語の理解がおかしいぞ
ここまでのこのスレをもう一度読み直してみろよ
さっき提示したまとめレスでもいいけど まとめを貼り付けておくね
・.envは環境を定義するためのものなので環境ごとに異なる。各環境に直置きし、ソース管理に含めないのがお手軽
・定義すべき内容（テンプレート）は.env.exampleで共有すると良い（こちらはソース管理に含む）
とはいっても.envを管理対象に含めたいプロジェクトはそこそこある
以下の対応をすると良い
＊機密情報の取り扱いに関して
厳密には、.envを管理する/しないとは関係がないが、以下のように整理すると良い
・どのような立場の人から情報を守りたいのかを定義し（セキュリティポリシー）、その対応としての実装を行う（ガイドライン）
・公式ドキュメントには、「source control repository」からの流出が一例として載っているが、その想定は一般的ではないのでポリシー設計時には自システムに対応した脅威を整理すること
・ルールで縛られることも多い。例えば「データベースへの接続情報は、ミドルウェアの管理者が管理する事」とか「特定管理者以外に資格情報は開示しない」とか
・実装方法は、.envに記述する/環境変数を使用する/変数として管理しデプロイ時に上書き等々あるが、ポリシーとセットで語られるべき内容なので省略
＊.envファイルの管理方法
以下のような実装方法がある模様
・環境ごとのファイルを用意して、環境変数APP_ENVで切り替える（注：defining a server-level APP_ENV）
・各環境のローカルリポジトリとして管理
・共通の.envを用意して部分的に環境変数で上書き
・共通の.envが使用できるように、デプロイ先の環境をそろえる >>311
その必要なケースとは何？って聞いても
「客の依頼」とか「上司からの指示」しか答え返ってきてないけど
自身の主張は無いの？
「上司の指示でコミットするけど、自分はそれを合理的な指示だと思わない」
と
「上司の指示でコミットするし、自分もそれを合理的な指示だと思う」
の2パターンあるよね
前者の場合だと.envをコミットは否定されるから、結局客や上司の主張と合理性は関係ないよね。 おかしいのはお前だよ。老害認定する奴もそうだったけど、.env自体のコミットは意味ないって話だったのに、なんで、.env.stgや.env.prdが.envコミットすることと同義になるんだよ・・・。勝手にゴールポスト変更するなよ。 >>312
.env.exampleってただの設定例であって環境設定のそのものではない
.envや.env.stgなどは環境設定そのものであって持つ意味が全く異なる >>312
いや馬鹿すぎでしょ
「環境設定の例」と「実際の環境設定」は異なることを理解してないのか君 >>315
> 自身の主張は無いの？
それは、このスレで議論しても仕方ないって言ったはずだけど？
おおよそ不具合発生時の対応として発生したルールで、QCに関わる部分だから上意下達が普通
合理的かどうかは、開発部門全体が見れるポジションにいなければ判断できない
個社別の理由だからLaravelスレで開示されても困る 1中 composer.lock, package-lock.json をコミットしない
2右 vendor, node_modules をコミットする
3左 .envを別名で複数作る
4一 .envをコミットに入れる
5三 jsonをレスポンスするAPIは脆弱
6二 サロゲートキーをAIするのは頭が腐ってる
7遊 本番環境が開発環境
8捕 emailカラムにemailと関係無いユーザー識別子を入れる
9投 零細企業で勤務する >>316
まとめみろよｗ
ゴールポスト動かしといて逆ギレするってｗww >>321
これがこのスレにおける平均的ララベラーですね >>321はさぞ優秀なんだろうなぁｗ
零細企業で勤務するとか大半が当てはまるやろ
てか大手に居る方がクソが多い気がするわ >>318
同じだぞ。exampleはアプリケーションを開発環境で動かす際に必要な環境変数を定義しておく。もちろんクレデンシャル情報は除く。
.env.stgや.env.prdも同様。
違いがあるとすればそれを自動でロードするか手動で.env内にコピーして使うかの違いでしかない。 俺、今まで.envをコミットするのってネタだと思ってたんだけど、マジレス具合見てるとネタじゃなくて本気なんだと考えを改めるようになった リファクタしました
1中 composer.lock をコミットしない
2右 vendor をコミットする
3左 .envを別名で複数作る
4一 .envをコミットする
5三 jsonをレスポンスするAPIは脆弱
6二 サロゲートキーをAIするのは頭が腐ってる
7遊 本番環境が開発環境
8捕 emailカラムにemailと関係無いユーザー識別子を入れる
9投 年収450万円上未満 >>326
.envをコミットしなきゃならん環境なんてでかい会社だと普通にある >>328
なんでも記録取ろうとするからな
監督省庁がうるさい系だと小さい子会社てもコミットさせてそう 「でかい会社」ってのがどういう規模なのか知らんけど、
人数が多くなればなるほど機微情報をリポジトリに入れるリスクは増えるからありえないと思う、むしろ零細のほうがデメリットが少ない。
※ デメリットが減るというだけでメリットがあるわけではない。
>>330
記録が欲しいという観点だと開発用のリポジトリとは別の媒体で管理するけどね。
今俺が勤めてる会社はいわゆる中小企業だけど、親会社は大手でそこからの出向者も多く居る会社だけど、
本番や検証環境のクレデンシャルなんかは別の媒体で管理してて、閲覧可能なメンバーはデプロイ担当者とマネージャー系だけに限られてるよ。
リポジトリに機微情報入れるとか絶対にありえないよw >>331
機微情報の取り扱い観点で論じるのはずれてる。まとめ読んでみ
セキュリティポリシー次第だけど、.envをコミットするしないとは関係ない ミソとなるのは開発メンバー全員に本番環境のクレデンシャル晒すところだよね
確かに零細ならメンバー少ないしそこまで否定できないかも
大手ほどコミットするって話は本当に開発用リポジトリに対しての話なの？w
独立したリポジトリにコミットしてるとかなら話は別だしそれは否定することでも無いよ >>333
まとめ読めｗ
なんで、クレデンシャルが.envに記述されてる前提なんだよ
それは別で検討すべきって書いてあるだろ ナレッジとして使えるように整理しておいたわ。
論点1
クレデンシャル情報入りの.envをコードと同じリモートリポジトリで管理して良いか？
ありえない。理由は以下。
・プライベートであっても、リモートリポジトリは容易に設定ミスでパプリックになるリスクがあるから
・プライベートリポジトリはクラッカーの攻撃対象として常に脅威に晒されているから
・コードにアクセスできる人とクレデンシャル情報の人は基本的に一致しないから
管理上どうしても履歴管理したいなら、AWSなどが提供する専用サービスを使う、ローカルリポジトリまたは暗号化されたリモートリポジトリでコードと分けて管理するのが合理的。
履歴管理が不要なら、サーバー側の環境変数としてあらかじめ設定しておく。
論点2
クレデンシャル情報なしの.envをコードと同じリモートリポジトリで管理して良いか？
ありえない。なぜなら環境によって使用するパラメータが異なるから。
論点2-1
全環境同じパラメータを使う場合なら良いか？
ありだが間抜け。その場合はconfigファイルのデフォルト値に設定すれば良いので.env自体不要と考えるべき。
論点2-2
環境ごとのファイルを別途用意し、切り替えて使うなら良いか？
あり。 てか、年俸通知書を晒して一番高い奴が勝ちでよくね？ >>335
論点1は個社のポリシー/ガイドライン設計で変わる。語りたいなら脅威分析した上で語れ
論点2は「なぜなら環境によって使用するパラメータが異なるから。」が確定なのか？
ほんと狭い視野だな >>338
ゴミみたいなガイドラインでもそれに従えて話か？そんなエッジケース、論点でもなんでもないだろう。ナレッジって意味わかってるか？ >>338
そもそもdotenvは環境ごとに異なる値を吸収する為に作られてるライブラリなんだよ
その前提ガン無視かよw 環境ごとに異なるから.envに書いているのに、環境ごとに異なるとは限らないと主張するのは面白いな >>340
しかも論点2-1にそれへのアンサーも書いてあるんだよね。 .envはもうどうでもいいよ
サロゲートキーで発狂する話のほうがまだ面白いわ dotenvの解釈、足りてないぞ
設定をコードから分離する先としても機能する >>339
そもそも組織のガイドラインなんだからエッジケースの話してんだけど、理解できてる？
組織のガイドラインとLaravelのガイドライン、組織内で使用するにはどっちが優先されるか自明だろ >>346
ヤベーなお前。そんなエッジケースがここにいる他の奴らにどう役立つんだ？ナレッジの意味わかってるか？ >>340
dotenvの役割、半分しか理解できてないぞ
環境を記述するから差異も記述されるけどそれだけじゃない
環境設定をプログラミから外出しするための機能だって理解したほうがいい >>347
だから言ってんじゃん
「.envをコミットしなきゃいけないプロジェクトに参加した人」の役に立つんだよ >>344
これには同意
.envコミットの話は飽きたよ
だって何言っても「上司がー」「客がー」しか言わないんだもん >>349
そんな底辺で仕事しているやつ、お前ぐらいじゃね？ てか、年俸通知書を晒して一番高い奴が勝ちでよくね？
てか、年俸通知書を晒して一番高い奴が勝ちでよくね？
てか、年俸通知書を晒して一番高い奴が勝ちでよくね？ セキュリティガイドラインをわざわざ作ってる企業が、コードと同じセキュリティレベルでクレデンシャル情報を管理するという発想が謎すぎるんだが？？俺だったら、おかしいって言うけどね。 >>335
わろたｗごみじゃんｗｗｗあらしは消えろ >>351
まだ、底辺認定にこだわるのかよ
どーでもいいとこだぞ。それ >>355
底辺煽りしたの今回が初だけど、他のやつからも煽られてたのか？だとすると相当だぞ。 おまえ、このスレで底辺認定したがってるあらしがいるの見えてないの？
相当目が悪いぞ >>335
論点 1 ひでーな
これ、真剣に言ってたらビビるわ >>353
お前のコメントが謎だわ
どっちもそんなこと言ってない
どっから出てきたんだ？ >>348
なぜ環境設定をコードから分離するのか理解してるか？>>340は目的を説明してる。お前はその目的を達成するための手段を述べているだけ。話が噛み合ってない。 >>360
何から何を守るかの観点で語られるべき内容が、うっすい理由であげられてるからだろ
セキュリティ気にするやつなら、こんな入り方しない
なにかのガイドラインの引用ですらないじゃん
これ断言するような環境なら、そもそも内部にリモートリポジトリを管理するサーバを持ってるから、論点1の理由とかずれまくりｗ コミットする人はたぶん「env」の本来の意味も知らないで語ってると思う
イーエヌブイって呼んでると思う 実はこの流れ、全部オレが開発した会話AIなんだぜ
すごいだろ騙されたか？ >>364
何から何を守るかはサービスの中身や各社の事情に依存するから、不特定多数向けのナレッジとして書けないでしょ。これより踏み込みつつ一般化した具体的な指針が書けるって言うなら是非書いてくれ。 話をぶった切って申し訳ないが、
切り分けたヘッダー一覧とかサイドバー一覧とか各ページ共通で使うそれぞれの切り分けたbladeにそれぞれSQL内容出力かけてるんだが
逐一コントローラーに書いてreturnするのもしんどいので何かいい配置場所やパターンないかね？ >>368
画面共通で使うパーツ内のデータ受け渡しを、毎回コントローラーで書くのは嫌だって話？ >>367
徳丸先生ですらベストプラクティスがないって言ってる箇所なのに一般化した内容なんて素人がかける訳ないだろ
だから >>314 みたいに、「ポリシーとセットで語られるべき内容なので省略 」ってのが正しい
>>314 はよくまとまってると思うよ >>369
そうですねん
今調べててリポジトリ？とかいうのでプロバイダ登録とやらが良さそうだけども
こういう時こうするのがベターとかあれば伺いたい、、 >>371
オススメはViewComposerやね。 Laravel7以上ならViewコンポーネントクラス
L aravel8以上ならLivewire
あたりもオススメ。
他にmiddlewareや親コントローラーのコンストラクタに処理書いてview::share()する方法もあるけど、カオスになりがちだから非推奨。 お前らってLaravelでDB登録時のチャタリング防止処理するときってどういう風に実装している？ bladeの切り分け質問答えてくれた人ありがとね
Viewコンポーサ動かしてたけどええな
livewireは今から試すんだがこれjsとの共存怖そうやなLaravel的にはLaravelの範囲内でMVCしたい気持ちは解るが >>377
livewireはまだこの先どうなるか分からないからね。使い勝手は良いのだけど。だからまぁviewComposerかviewコンポーネントクラスが落とし所としては妥当かもしれない。 え？チャタリング防止ってしないもんなのか？
最近組み込みの世界から高級言語の世界に来たからわけわからなすぎる
もしかして高級言語ではチャタリングってないのか？ チャタリングは基本ないよ
チャタリングに近いところでしいて言うならフォームでボタン連打されたときの対策とかかな PDO::ATTR_EMULATE_PREPARES を TRUE にするとかも微々たる対策なのかなぁ Laravelのこういうところを直してほしいって要望お前らある？ create-projectした時点でUserモデルとマイグレーションファイルが数個用意されているけどそれを止めてほしい
create-projectした段階はモデルやマイグレーションが空の状態が望ましい 個別に消すのが面倒ってことかもね。まとめて消せるスクリプトがあるとか、laravel-installer使った時はその辺りのファイルを予め作らない指定ができると良いのかな？ 確かにプロジェクト生成時にかってにUserモデルがいてしかもそのUserを使った
Auth直下のコントローラたちがいるのはうざいな >>387
普通にlaravelインストールするだけだとauthディレクトリやその下にコントローラーなんて出来ないぞ。 >>388
composer create-project laravel/laravel:6.* sample
ってコマンド実行したらLoginControllerとか出てきたぞ >>388
Laravel7以上はいないけどLTSのLaravel6だと最初からAuthとかあるよ 6だけでるんだな。新規は5.5と8しかやってないから気づかなかったわ。 言われてみればAuthを使わないプロジェクトってやったことないな
なんだかんだで毎回使ってたわ 基礎的なCRUDとフォーム操作が学べれば良いんだけど
公式のリファレンスで勉強するべき？それとも本が良い？
公式はちょっととっつきにくい感じはした（PHP初心者です それが取っつきにくいなら取っつきやすいのを探すか諦めるかでしょ
本が取っつきやすいかどうかはその人の技量次第じゃね？
本屋で立ち読みするとかで自分で判断した方がいいよ なるほど本屋で探してみ舛添要一
ちなみにみなさんはどんな本で勉強したんですか >>396
基本は公式マニュアルみながら、実際のコードと突き合わせて勉強するのが良いと思うよ。OSSで色々出てるし。 もう少し手取り足取り教えてくれって人が多いんだよね
だから本を出す出版社があるし、そこそこ売れるから市場もある >>398
で、かったはいいものの、ろくに役に立たないと呆れて終わる… お前らまた.envコミット君に論破されたのかよｗ
.envをコミットするという明らかに間違ったことをなんで論破できないんだよｗ シーダーで本番データ入れる君もいなかった？
個人的にはそっちの方がツボった >>403
え？マスターデータならmigrationに書けば良いでしょ。なぜわざわざseederに書くの？ Laravel includes the ability to seed your database with test data using seed classes.
https://laravel.com/docs/8.x/seeding#introduction >>406
マスターの変更する度にマイグレーション作ってたら管理し辛いだろ >>408
テストデータと一緒に管理するって発想の方がよっぽどおかしいって気づけよ・・・。 ある道具はリスクなければ好きに使えばええやん
テストデータの挿入以外ではそこまで便利になるもんでもないと思うけど つーか、マニュアルでシーダーの役割説明しているのに、わざわざ本番データ入れるのが正しいて思ってる奴なんなの？.envくん並みだな。 シーダーにマスタデータ書く馬鹿まで居るのかこのスレはwww と思ったらマイグレーションにマスタデータ書く阿呆まで居るのかよこのスレwww シーダーとかマイグレーションでマスタデータ作るのは草
どっちもやべーし動物園かよここ seedでマスタ作るのはあんま違和感ないけどmigrateでマスタ作るのは斬新だな、変更あった時どうしてんだろ >>409
いやマスタ用とテスト用のSeedクラスで名前空間分けてるし一緒に管理してるという感覚無いわ migrationで本番データ入れるのは、teratailで推奨している奴いるぞ。
https://teratail.com/questions/179831
railsだとmigrationでやるのはNGでrakeタスク用意しろって言われる。 seedクラスの名前空間分けてるは草
やっぱ動物園だなここ >>420
なんで俺が動物に正解を教えなきゃなんねーんだよ
お前は自分の頭で考えないから動物なんだよ^^ >>417
それ本番だとどんなコマンドで実行してるの？ >>423
単にクラス名指定してるだけだけど
php artisan db:seed --class=MasterSeeder シーダーで本番データ登録している人マジでいるんだ・・・ >>425
それなら良さそうね。いきなりdb:seed --forceて言われたら引く。 >>426
ヤバイよねこのスレ
.envをコミットするやつとか居るし、前々スレではREST APIにjson使う奴もいてビビるわ マスターデータ投入のプラクティス:
1.migrationに書いて実行
2.マスターデータ専用のシーダークラスを用意して実行
3.commandsにマスターデータ投入の処理を用意して実行
railsを参考にすれば、3が今のところ一般的。 すげーな真面目にやり方の議論始まったよ
そもそも誰がどうやってシーダーファイル書くつもりなんだ 公式もシーサーはあくまでもテスト用だよって言ってるのに そもそもテストでもシーダーなんて使わないな
書くのが面倒すぎる いやいやいやｗｗｗ
お前ら実際に会社でシステム構築したことないだろｗ
普通にシーダーでマスタデータ登録するからｗ >>431
動物園！て喚くだけのカスにはなりたくないのでー >>433
前もそのコメント見たけど、factory使ってシーダーからダミーデータ作ったことない？普段どうやって開発してんの？テストコード実行するだけ？ Laravel動物園ワロタ
動物にフレームワーク与えたらムチャクチャすんだな、しかも何がおかしいか説明しても通じないという
相手してる人はご愁傷様 やるとしたらマスター登録用シーダー作るか
マスター登録用コマンド作るかだな マイグレーションファイルに書くのはないな >>436
テストデータはcsvでもらって、phpMyAdminでインポートする事が多い
これがベストプラクティスと言うつもりは全くなく、単なるうちの例だけど他に思い付かないし ・マスタ用にseederの名前空間分ける
・migrationで管理する
・カスタムコマンドでマスタ用のデータ
今の所出たのはこれだけ？
動物園と喚いてる人はどうやってるんだ？ そういえば１年ぐらい前に某サイトがphpMyAdminが公開された状態になってたな >>440
あー、なるほど。最初からテストデータを誰かが用意してくれているなら良いかもね。
俺はそれを自分で作るのが面倒なのと、csvで管理するときの仕組み考えるのが面倒なので、最初から仕組みがあるシーダーで投入している。 >>437
いや、お前は何がおかしいか自分の言葉で説明できずに動物園て喚いてるだけだから、このスレの中では一番動物的だぞ。議論できるよう早く人間になれると良いね。 >>444
残念ながら俺を煽っても大して相手しないぞ
誰か親切で暇な人に構ってもらってね ログインにユーザのIDを利用したいからvendor直下のファイルを修正しているって
きいたときは凄いびっくりした覚えがある 初期データをどこで登録しようが勝手やんかと思うのだが
なんで発狂してるやつがいるんや？ >>445
いや、あの時は老害煽りを動物園煽りで返してたから、別人では？アホが2人居るってこと。自作自演の可能性もゼロではないけど。 オーバーライドで解決しない問題があるのであればvendorのファイルを修正するのもありだとおもうけどなぁ・・ >>450
その場合forkして、そっち変更してcomposer installできるようにしとく。 vendor直下のファイル修正するな・・・・ マジでお前ら使い方間違えすぎだから >>450
まず解決しないことは無いけども、仮にそんな場面あればさすがにプルリクするわ vendorの修正は流石にcomposer管理下のものだしやるにしても>>451だけど
修正しなきゃ行けないような場合はそもそもそのライブラリの利用をしないという風になるかな 自環境のみで再現するレアなバグがあって修正せざるを得ない場合とかないの？
問題はその一点だけで、他に代替ライブラリもないような場合なら直して使うだろ >>455
動くけどメンテは停止しているライブラリだと、Laravelのバージョン上げるときに、composer.jsonの依存パッケージが他のパッケージと競合してインストールできないみたいなことがある。
その場合はforkしてcomposer.jsonのバージョンのとこいじるみたいなケースは稀によくあるな。もちろん代替があれば嬉しいけど、載せ替えるのも結構手間だったりするし。 プル陸してどうすんだよ、待つのか？
メンテされてなかったら？
こっちは仕事でやってんだから納期まで納品しなくてはならないのに、赤の他人に絡んでられないだろ vendorいじる奴がネタじゃなく本気で存在することに驚き そもそもメンテされてないライブラリ使うか？普通
スター3桁未満で最後のコミットが2 years agoとかよく見るけどよっぽどシンプルで枯れ技術とかでないと使いたくないわ >>464
issuesやらプルリク溜まってて、最後のコミットがかなり前のOSSの特徴って
「昔は使う人がそれなりに居たけど、メンテされなくなってからほとんど使われてない」って奴だよね
こういうのって昔メジャーだった分、誰かが代替品作っててコミュニティもそっちに移行してて、問題も解決されてることが多い
issuesもプルリクも溜まってなくてスターも少ないOSSは代替品すら無いし、こういうのに依存するのはプロダクトとしてまずいよね
そのくらいだとどうせ小規模だろうし自作して済むことがほとんどだと思う REST API にjson使うのは危ない
→ ヤバい
.envをコミットする
→ ヤバい
サロゲートキーをAIするのは頭腐ってる
→ ヤバい
seederでマスタデータを入れる
→ どうでもいい
vendorを直接編集する
→ かなりヤバい、vendorコミットとセットかよw REST API作るならOAuth2認証付けるだろうしhttpsでjsonで問題無い すまんREST APIはレスポンス応答などをjsonでやるものが標準と思っていたが
もしかしてREST APIにjson使うのは危険なんですか？ 見様見真似でLaravel使ってるだけの層にとって、vendor以下の内容なんて自分で選ぶわけでも把握してるわけでもないよね
ちゃんとメンテされてる、プルリクにすぐ対応してくれるってLaravelによって保証でもされてるの？ vendorを編集するくらいのリテラシーだと編集した部分のテストも無さそうで地獄だな
百歩譲って該当クラスの全メソッド全分岐のテスト書いて、なぜ変更が必要なのかドキュメントに具体的に書いてあればまだ理解はできる おっす！ 酒飲みながらComposerでLaravelインストールしてみた。インストールは楽でいいな。
で、とりあえず話題の.env見てみたけど…、なんだこれ？
こんな作りならそりゃまぁ『コミットすんな』だろうなぁ。
というかさぁ、まだコードよく読んでないからどうやって.env読み込んでんだかしらないんだけどさぁ…、
こりゃまた、下等な作りになってんなぁ…。
クラスで提供して環境変数見て自動で振り分けりゃいいのに…。 書いてあんじゃん。
```
アプリケーションを使用する開発者／サーバごとに異なる環境設定が必要になる可能性があるため、.envファイルをアプリケーションのソース管理へコミットしないでください。
```
https://readouble.com/laravel/8.x/ja/installation.html /vendor/laravel/framework/src 覗いてみたけど、
酷いな、これ。どうしてこんな設計になっちゃうんだ？ 意味わからん…。
チュートリアルやりながら１ヶ月くらいかけてのんびり観察してみるわ。 つーか、今日はあと１個だけ言わして。
既にイラッとしてんだけどさ、
Laravelって、なんでこんな中二病こじらせたようなクラス名ばっかつけてんの？
何の事だか分かんないじゃん。
おまえ、子供にキラキラネーム付ける毒親かよ！？ Laravelのソース何か見ても理解できる訳が無いやろｗ
まずは動くもの作ってから中身を気にしろｗ >>473
下等ってwww
お前のほうがむしろ古臭い考え方だぞ。環境に依存した設定は本来コードから切り離すべきってのが今の主流。dotenvはそれに沿った仕組みだよ。 Laravel本体でそんな厨二病なクラス名ってあったか？思いつかないわ。 マウント取りたいだけだから具体的じゃなくても本人は満足してるんだろ 結局.envはコミットしない、jsonはAPIで使わないほうがいいって結論でいいの？ それであってる.envコミットは論外だしjsonもAPIでは使っていけないフォーマットというのが業界標準の約束事 自分で考えて正しいと思う方にしよう
判断できないなら判断できるで学習しましょ .envコミットしてはいけないというのは理由はわかるんですが
jsonをAPIで使ってはいけない理由ってなんですか？ >>488
そっちはオカルトだから相手にする必要ないよ .envコミットするのを論破することができない俺らも悪い気がする・・・ おっす！ 腹痛くて起きた。酒飲みすぎ、ダメ。
>>480
> Laravelのソース何か見ても理解できる訳が無いやろｗ
>>482
> お前のほうがむしろ古臭い考え方だぞ。環境に依存した設定は本来コードから切り離すべきってのが今の主流。dotenvはそれに沿った仕組みだよ。
なわけねぇだろ。見りゃわかるよ。だから『下等な作り』っつってんじゃん。
あのな、書いたとおりまだ.envどうやって読み込んでんだかコード見てねぇから詳細はしらんけど、
設定は$_ENVスーパーグローバルにつっこまれてて、env("hogehage") とか下駄関数使って取得するんだな。
https://readouble.com/laravel/8.x/ja/configuration.html
なんすか？ これ、みたいな。
まず、『今どきグローバル関数っすか？』みたいな。
関数定義場所はhelpers.php、『ヘルパー』なのな、これ。中見るとEnvクラスの静的メソッドのラッパになってる。
『なんでこんな事になってんだい？』と思ったら、恐らく、旧バージョンとの互換なんだろうな。
で、$_ENVって、『連想配列』な。つまり、『変数』な。
あのさぁ、PHP本体のスーパグローバル、汚染する？ 普通？
それでさぁ、『環境』に関する定義、を『変数』に突っ込む？『定数』にしねぇ？ 普通。
変わったら困るし、変えられたら尚困るじゃん。
定数の方が明らかにアクセス速度も早いしさぁ。
もう、しょっぱなから全然ダメ、Laravel。 >>492
そんな仕組みになってない
せめてドキュメントにあることぐらい理解してから煽れアホ で、
> 環境に依存した設定は本来コードから切り離すべきってのが今の主流。
だけど、今の主流っていうか、遥か太古からそうだよ。
そういう話じゃなくて、すげぇ簡単に適当にコード書くと、
class Env {
public static function set(){
$env_file = "/file/to/environments/.env_" . self::which_env();
if(! file_exists($env_file) ){
throw new \Exception("ねーよ");
}
self::register($env_file);
}
private static function which_env(){
$toriaezu_saba = $_SERVER["SERVER_NAME"];
switch(true){
case $toriaezu_saba = "本番環境": return "product";
case $toriaezu_saba = "おれ.の.IP.アドレス": return "oredayo";
default: return "develop";
}
}
}
みたいにして、（いいか？ 繰り返し言うけど、上のコードは今適当に書いただけだからな？）
/file/to/environments/
├.env_product
├.env_oredayo
├.env_omaedayo
│ ：
└.env_product
な感じにしとけば、コミットしようがしまいが関係ないじゃん、って話。
だから『Laravelは下等な作りになってんなぁ』って言ってんの。 >>492
本当にやべーなコイツ。環境変数で受け取るって主流のやり方を全否定してやがる。12factor.appぐらい読めよ。環境によって異なる設定をお前はコード内で定義すんの？環境増えたらどうすんの？コード内で分岐増やすのか？
あとenvヘルパはLaravel固有のファサードによるアクセスを簡易にできるようにラップしたものだぞ。古いバージョンとの互換性とか見当違いも良いとこ。ファサード批判なら分かるがヘルパ関数否定するのは意味不明。
さらに定数にしろって話も、何も分かってないの丸分かり。L aravelの場合、環境ごとに自由に値を切り替えられるようそういう作りになっているが、速さについてもconfig:cacheによって担保されている。
単にお前が無知で全然ダメってだけ。 >>493
書いてあんじゃん。引用したじゃん。おまえ、馬鹿じゃん。
で『どこがどう認識違ってる』って言えばいいだけじゃん。
やっぱおまえ、馬鹿じゃん。 >>496
> .速さについてもconfig:cacheによって担保されている。
だーめだ、このポンコツ頭。
おまえの言ってる『速さ』って、一体何の速さの話だ？ >>496
> 環境によって異なる設定をお前はコード内で定義すんの？環境増えたらどうすんの？【コード内で分岐増やすのか？】⇠
脳みそくさってんなぁ…。
ここも、設定ファイルに切り出すに決まってんだろ。
で、それを読み込んで『自動分岐』
おれ、書いたよな？ （いいか？ 繰り返し言うけど、上のコードは今適当に書いただけだからな？）って。
おまえ、本当にプログラマか？ アマグラマだろ。 >>496
> あとenvヘルパはLaravel固有のファサードによるアクセスを簡易にできるようにラップしたものだぞ。古いバージョンとの互換性とか見当違いも良いとこ。
しらねぇよ、そんなもん。言ったじゃん、昨日初めてLaravel入れてみたって。
でさ、そんな事どうでもいいって事すら、理解出来ん？
おれが問題だっつってんのは、
『今どきグローバル関数っすか？』みたいな。
env()とかconfig()とかの事な。
グローバルスコープ名前空間で定義すんなよ、ってのが、
今のPHPに限らず『あらゆる言語』での『常識』。
だから『PHPerはダメだ』って言われんだよ。 特に >>496 の脳みそが腐ってんのは、
おれが何故上のコードを書いたかというと、
『.env をリポジトリにコミットする馬鹿がいるから』って前提条件があるって事を、
完全に忘れてんのな。
もう『お前、ニワトリだろ？』みたいな話。 https://readouble.com/laravel/8.x/ja/configuration.html
> 機密性の高い資格情報が公開されるため、侵入者がソース管理リポジトリにアクセスした場合のセキュリティリスクになります。
言ってる事、わからなくもないけどさぁ…、
それ、別のところのセキュリティを心配しろよ…、みたいな。
それは .env をリポジトリに含めるかどうかって話とは、全く関係ないだろ、みたいな。
レベル低い会社だと『セキュリティの為、変数名と関数名は連番にしてくださいい』みたいな会社が『平成の後半に入るくらい』までは、
あったらしいけどさぁ…、
『おまえ、着目点、おかしいだろ？』みたいな。 laravelの.env関連がオブジェクト思考な作りになってないって言いたいだけか。
話が長い。まわりくどい。無駄に人格否定しすぎで批判君の話を聞こうと思う人を減らして批判君は損してるね。
批判するために批判するのが目的でないなら、批判君の理想の作りに変更してlaravelに採用してもらってみなさい おれ様w仕事何してるの？w
どうせ無職ニートなんだろうけどw >>501
君が言う問題を要約すると「関数をグローバルに使えるか」が焦点なの？
その仕様が糞かどうか以前に、それがphpの言語仕様だからLaravelはあんまり関係無いな。cakephpにもグローバルに使える関数は存在する。
phpは元々オブジェクト指向の言語ではないし、そこを気にするならLaravel以前にphpが糞ってことで使うのを辞めたほうがいいよ。 >>501
間違いを指摘されて「俺は初心者だから仕方ない」「そこは論点じゃない」
w > env()とかconfig()とかの事な。
グローバルスコープ名前空間で定義すんなよ、ってのが、
> 今のPHPに限らず『あらゆる言語』での『常識』。
それが良い悪いはともかく、
多くの動的型付け言語、いわゆるスクリプト言語ではグローバルな名前空間で関数定義可能だけどね
つーかもはやlaravel関係ないし javascriptやPHPの歴史を知らずクソとかいう奴と同レベルだな .envの仕組みはLaravelオリジナルじゃなくてphpdotenvってライブラリから提供されるものだからLaravel関係ないぞ
提案があるならこっちのissuesに書いてくれば？
https://github.com/vlucas/phpdotenv > で、$_ENVって、『連想配列』な。つまり、『変数』な。
あのさぁ、PHP本体のスーパグローバル、汚染する？ 普通？
$ENVに詰め込んでるのはLaravel関係ないぞ
てか君、文体からして>>210と同じ人でしょ ほんとだサロゲートキーおじさんがLaravel使ったこと無かったのと、「だーめだこりゃ」の口癖が一致してる。
恥ずかしくなって逃げたと思ったけど帰ってきたんだね。
そろそろ63bitのbigintをオートインクリメントで埋めることは叶いそうかい？w サロゲートキーおじさんは$_ENVを汚染するなおじさんに転職したのか
呼びにくいからサロゲートキーおじさんのままでいいよ あ、コイツあれだ。前にORM自作しててLaravel使ってないとか言ってたやつだわ。>>511が正解だな。 アンチオートインクリメントおじさんまとめ
・Laravel使ってないのになぜかLaravelスレで偏った主張を繰り広げる
・サロゲートキーにオートインクリメントを使うのはアホ。なぜならint型なのでオーバーフローするから。
・bigintを知らない。その証拠に922兆をunsignedと決めつける謎の主張をして周りを混乱させてる
・Laravelと直接関係ないdotenvの仕組み(symfonyで取り込まれた)を根拠にLaravelは下等だとのたまう
・環境ごとに分岐するクソみたいなサンプルコードを書いたあと、あれは適当に書いただけで本当は自動分岐だからて言い訳する
・グローバル関数使ってる言語やFWはありえないらしい
・環境変数に値を設定するとPHP本体のスーパーグローバルが汚染されるという謎の主張を繰り広げる >>515
単位を京と書くところ間違って兆にしてたわ。訂正。 まぁ、あんまり922京をunsigned(64bit)と間違えたことを指摘すると揚げ足とってるみたいだからそこは触れないにしても、
仮にそれを半分のsigened(63bit)にしたって461京あるんだが、
それを100年間かけて枯渇させるには1日あたり126兆件のレコードを挿入する必要あるんだよね。
・利用者世界規模のエンタープライズシステムを作ってる
・bigintという概念を知らなかった初学者
どっちだ >>480
laravel/uiのソースくらいから読むと色々勉強になるがね >>519
126兆件/日＝30万件/秒だぞ
仮にそれだけの利用機会があっても現代のマシンでは性能が足りないな >>519
まぁ普通はそこで揚げ足とりなんてしないけど、彼の場合unsignedだと決めつけてそれを根拠に更に謎理論を展開した挙句人格攻撃までしてたからね。慈悲は無い。 まったく、お前らみたいな低レベルは話の焦点が理解できんみたいだから会話にならんな。 『慈悲は無い』って、バカかと。
お前に無いのは『知能』だろと。 『Laravelのソース何か見ても理解できる訳が無い』レヴェルの集まりだからな。
話が合うわけがない。 このヴァカ、まだ日本語読めずになんかホザいてるし。
525nobodyさん2021/04/30(金) 10:00:06.40ID:???
bigint知らない人がなんか言ってるw そう思うなら、スレから消えたら良いだけなのに、負け犬の遠吠えみたいに書き込むあたり実に浅ましいなぁwww こいつがリアルで何をやっているのかw
開発者ですら無さそうだが どうした、元気ないな
一杯構ってもらえてよかったじゃないか >>531
はいはい、低レベらーなララベらー元気っすね。 サロゲートキーをAIするとオーバーフローするから危ないだろ！！
→ bigintの概念を知らなかった
$_ENV上書きするのバカすぎｗｗｗ
→ Laravelじゃなくてphpdotenvの仕様なのでスレチ
今どきグローバル関数っすか？
→ これだけ具体的にどんな問題があるのか分からないから教えて欲しい 正直な所、32bit unsigned intでも溢れるような案件って
そんなにあるようには思えないが実際はどうなんだろうね？
idをbigintにしないといけないような案件なら、週か月のバッチ処理で古いデータを
移動させたりするような運用が無いと、マジでディスクがいくらあっても足りなさそう
ログみたいに大量に出力されるもの前提ならそのままDBに突っ込むのでは無く
fluentd等を使って他の場所で処理させた方が良さそうだしなぁ >正直な所、32bit unsigned intでも溢れるような案件って
>そんなにあるようには思えないが実際はどうなんだろうね？
そんなには、ねぇよ。
何回言ったらおまえらの低脳でも理解できんのかわかんねぇけど、
おれが言ってんのは
プライマリキーに『有限な値の型』を使う発想が理解出来ん、
って事。
で、数年で普通にint超えるレコード登録される可能性のあるテーブルに
int AUTO_INCREMENT してる案件あった、
馬鹿ってさ、どこにでもいるんだよ。
.envをコミットする馬鹿もいるだろ？
だから、馬鹿が馬鹿な事出来ない設計をする必要があるんだって話。
分かった？ 馬鹿君。 >>536
じゃあお前はvarcharとか使ってるのかよｗ
その方があり得んわｗｗｗｗｗ
流石低能ｗ
どんな型でも有限なんだよｗ
お前のディスクは無限大なのだよｗ
ガイジはホント開発すらしたことないから物事が何も理解出来てないようだｗ >>537
> じゃあお前はvarcharとか使ってるのかよｗ
> その方があり得んわｗｗｗｗｗ
なんで？
> どんな型でも有限なんだよｗ
例えばvarchar（32）が許容するユニーク数幾つになるか、お前、計算できる？
ほんと、こんな馬鹿しかいねぇんだよな、ララベらー…。 >>539
unsigned int（32bit）ですらいくらあるか知ってるの？w
お前ごときがそれ埋まる程のデータ使うとか有り得んやろw
プライマリーキーに文字列wとか普通に考えたらディスクは食うわ遅くわでそんな設計しないわw
あ、ナチュラルキーしか駄目なガイジだったかw
商品コードをそのままプライマリーキーにしたいニダ？w
死んどけw >>540
> unsigned int（32bit）ですらいくらあるか知ってるの？w
桁が違うって事すら分からない馬鹿は黙ってた方がいいよ？
まじでおまえ、計算出来ないだろ？
- 例えばvarchar（32）が許容するユニーク数幾つになるか、お前、計算できる？ >>540
> 商品コードをそのままプライマリーキーにしたいニダ？w
> 死んどけw
なんで？
おまえってさ、『実務』って、知ってる？ このageてる荒らしはluckerまたはgoku59またはteratail_dayoと言ってteratailで何度もBANされてる問題児
超低レベルなくせに上から物言って論破されるのが趣味のやつ IDだしてくれる分にはありがたいからそんなこと言うなよ >>544
なんだ？ この馬鹿。
自分から『わたしは頭おかしいです！』って宣言する奴、居るか？ 普通。
ほんと、ララベらーって馬鹿ばっかだな。 これか。
キチガイじゃん、こいつ >>544
940 名前：仕様書無しさん 2021/04/30(金) 20:03:35.46
【至急】luがLaravelスレに来てうざいです。引き取ってください それで、>>544 は、なんでそんなに発狂しちゃったん？
これか？
本物の知恵遅れだろ、お前 >>544
541 名前：nobodyさん 2021/04/30(金) 20:18:13.45 ID:???
>>540
> unsigned int（32bit）ですらいくらあるか知ってるの？w
桁が違うって事すら分からない馬鹿は黙ってた方がいいよ？
まじでおまえ、計算出来ないだろ？
- 例えばvarchar（32）が許容するユニーク数幾つになるか、お前、計算できる？ >>545
IDにしてもキャラ付けにしても自作自演のための小道具だよ
こいつキャラ付けずに別人のふりして自演擁護するけど時々失敗してバレるから というか、これ
940 名前：仕様書無しさん 2021/04/30(金) 20:03:35.46
【至急】luがLaravelスレに来てうざいです。引き取ってください
…って、『マドハンドFは なかまを よんだ！』
みたいな話なの？
頭おかしいだろ、こいつ >>544 >>549
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ クソ小物 ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
草原出来るわｗ だからいい加減話理解しろよ
俺が言いたいのはプライマリキーに有限な値の型を使っているのが理解できないってこと
お前らプライマリキーが限界値に達したらユーザにどう説明するの？
システム止めてくださいって惨めに土下座しながらお願いするのか？ > だからいい加減話理解しろよ
ぐるぐるパンチレベルで草 >>555
プライマリキーの前にIDをつけるってどういうこと？ >>555
こいつ新しいこと覚えるのに時間かかるから無理ｗｗｗ お前らって2038年問題ってどのように対策している？ みんなに論破されたから今度は自分のことを偽物扱いしようとしていて草 >>558
PHPはCarbon使ってたら問題ない気がする
DBはdatetimeにしてる >>562
はいはい、低レベらーなララベらーキチガイっすね。 無能全レスおじさんに成り下がったか
人間こうなったら終わり >>565
下がってない
もう何年も同じところで低空飛行してる ていうかteratail_dayoは多分m.ts10806に相手してほしくてここで暴れてるんだよな？
mtsがいたとしても相手にしないと思うぞ https://codepen.io/sadsfff/pen/oNBryGr
すいませんphpスレでも聞いたんですが、
return $first_img;
<span class="thumbnail2"> この部分が連結できません。調べてもわからず、RSSで画像を引っ張ってきたときに画像がないものにダミー画像を使いたいのですが、何をどう調べればよいか教えてください。 >>534
> $_ENV上書きするのバカすぎｗｗｗ
> → Laravelじゃなくてphpdotenvの仕様なのでスレチ
そんなん、採用しなけりゃ良いだけじゃん。
Laravel開発陣営は、有り物採用しないとマトモな実装も出来ませんって話なの？
本物の馬鹿なの？ ララベらーって。 環境ごとのパラメータは、環境変数にセットすべきて話は理解しているはずなのに、「$_ENV上書きするのバカすぎｗｗｗ」て言ってるのはなぜ？
お前はどうしたいの？ >>572
こいつはそもそも環境変数にセットすべきということは理解してない
>>495を見れば分かる
これならdotenv採用するわな
環境ラベル付けや環境の増減によってコードを変更する必要あるし 多分実務経験が無いか、フリーランスの1人エンジニア、もしくは開発メンバーが極端に少ない会社に勤務しているんだろうね。
OSの環境変数に値設定することを全否定してるみたいだけど、
AWSのパラメータストアやAzureのKeyVault使いたいとき、つまりIassS側で設定する時どうするんだろ？
そもそも俺が経験して来た多くの現場ではdotenvはローカルの開発環境向けに使わないし、IaaS側はIaaS側のインタフェースから（AWSのパラメータストアとか、AzureのApp ServceのConfiguration）で環境変数を設定してきたよ。
>>571
報告する場所が間違ってる
お前が報告するべき場所はこっち
https://github.com/vlucas/phpdotenv/issues >>573
え？そういうこと？？やべーな。10年以上前のスタイルで開発してるってことか・・・ >>574
失礼、訂正
"しか"が抜けていた
× dotenvはローカルの開発環境向けに使わないし
○ dotenvはローカルの開発環境向けにしか使わないし あと殆どのパッケージは、なんらかのありものを使って開発してると思うんだけど、全世界のOSS作成者disってるの？ > あと殆どのパッケージは、なんらかのありものを使って開発してると思うんだけど、全世界のOSS作成者disってるの？
論点すり替える馬鹿。便利なら使う。便利じゃ無ければ作る。
>>577 は思考停止した本物の知恵遅れ >>572-575
宇宙から電波受信して妄想語りあう病院通いの馬鹿共。 > OSの環境変数に値設定することを全否定してるみたいだけど、
誰が言ったんだよ、その寝言？
脳みそ腐ってんな、こいつ。
まじでばかって３ぎょういじょうのにほんごよめねぇのな。 話伝えられないタイプの人ね。大規模現場では弾かれる人。 こんなのが現場に居たら、それだけで士気下がりそうだな。誰とも仕事できないし、自分の頭の悪さを自覚せず周りのせいにばっかしてそう。 まあ確かにlaravel9では.env廃止してyamlの設定ファイルにする見たいだから
環境変数やめようって方向性はあるのかもしれん >>581-583
妄想爆裂して妄言語りあう病院通いの馬鹿共。 必ず３発ずつレスするヴァカｗｗｗｗｗ ちょーうけるんですけどぉｗｗｗｗｗｗｗｗｗ ここまで律儀に煽りに反応している奴ってのも何だかなぁ。他に構ってくれる人居ないのか？可哀想。
ところで>>572の質問には答えることができないのだろうか？人格攻撃で返されてビックリした。 > ここまで律儀に煽りに反応している奴ってのも何だかなぁ。他に構ってくれる人居ないのか？可哀想。
なんだ？この自己紹介馬鹿 ふむ。やはり>>572には回答できないのか。残念。 アホすぎて相手にされなかったという事すら分からない馬鹿の自己主張 >>593 まごう事なき本物のバカの妄言。これが筋が通っていると信じ続ける知恵遅れの >>593
572nobodyさん2021/05/02(日) 08:32:15.85ID:???
環境ごとのパラメータは、環境変数にセットすべきて話は理解しているはずなのに、「$_ENV上書きするのバカすぎｗｗｗ」て言ってるのはなぜ？
お前はどうしたいの？ > 6時間後に更に追加でレスするの面白いな
すげぇな。らっきょが転がっても笑うだろ、お前。 Laravel使いって、意識高い、レベルも高いPHPerが多いと思っていたんだけど、
どうやら拙者の思い違いだったようでござるよ Laravel 9に向けて本出してくださいね
お願いしますよ
今どき6の本出すのは池沼ですから 今年発刊されたのが6.x対応とか書かれたの見た時はおいおいって思ったな マジかよｗ
てか公式サイトあれば本要らんやろ あれ見れば大体わかる Laravelのマニュアルを理解できないレベルだと、そもそも言語自体の初心者だったりMVCパターンすら知らないだろうから、そういう層をターゲットにしてるのかな？
MVC+PHP+Laravelをパッケージで覚えるみたいな。
個人的にはそれぞれバラで理解するほうが効率的だと思うが。 海外でもLaravelはバージョンアップのサイクルは早いから、本を書き上げたときには次のバージョンに移ってて無理て言われるぐらいだぞ。大人しく、公式マニュアルで勉強しとこうぜ。 書き上がってから変更点を直せばいいんではないの？もう刷っちゃってたら変更点のdiffをサイトで公開するとか その理屈で言うなら、Laravel6を本で勉強した後に最新との差分は公式見て勉強するアプローチで良いのでは。いずれにせよ公式マニュアル優秀すぎるんだよな。
それより俺はLivewireの本が欲しい。親子関係のコンポーネント作った時の実装分からなさすぎてツライ。 9がLTSだから秋以降に何冊かは出るだろうな
今から6とか8の本を出すのはさすがにセンスがない 本なんか出してももう売れる時代じゃ無いのにな
公式見てわからん奴は開発しなくていいしw >>609
Laravelのバージョンの考え方が今年の2月ぐらいに見直しになったからね。
それまでは8のサポート期間は2021年9月までだったんだけど、3月のバージョン9リリースを見送ることになったタイミングで1年延長された。 LTS末期までお前ら自身が生きてられるか不明なのに心配しなくていいだろ リリース後もバージョンアップに追従したりみんなしてるの？
こちらは開発終わればそもそも終了なのでその後の事は全く知らんけど そんなの契約内容次第だが
自社製品だったり、業務委託でも保守契約結んでたりすればアップデートもするし、そうでなければしないだけのこと 本業は自社サなので当然バージョンアップもする。趣味のサービスも勉強ついでにバージョンアップする。副業のサービスのみ微妙。毎月の保守費の中で対応できそうならやる感じ。 保守するかどうかはクライアント次第なのでエンジニアが底辺かどうかは関係ないのでは 614が底辺かどうか知らないけど、常識レベルの質問するあたり新人って感じはする 底辺煽りはイキり散らしている奴相手のときだけにしとけ。普通に質問している奴には、ちゃんと回答してあげたら良い。 >>612
pbs.twimg.comは手軽に持ってこれるからTwitterでそれらしい画像探してきたんよ すみません教えてください。
laravel-mixでjsファイルやcssファイルをコンパイルするというのはわかりましたが
phpファイルはどうやってコンパイルすればいいのでしょうか >>623
.jsと.scssと.phpを一緒のディレクトリにぶっ込んでnpm run prodって叩けばいい phpをコンパイルしてネイティブに変換するプロジェクトがあった気がするけど名前が思い出せない Laravelってなんでルートの書き方変えたの？
IDE使ってると補完聞いて便利ぐらいしか思いつかないけど
なんか技術的な理由でもあるのか？ >>627
php8でJITを有効にすればある意味コンパイルしているようなものではあるけど
まだ使ったことが無いので使用感は分からないが laravel 10ぐらいでromaに移行すると思いますか？ >>628
前の実装だとクロージャールートがキャッシングできなかった。それを改善するために今回の変更が行われたんじゃないかな。
6/30のツイートでそのような主旨の発言をしているし、その5日前には当該箇所を修正してコミットしている。 クロージャーキャッシングってなんだよ
次から次へと新しい言葉でてくるし何のことかさっぱり
なんでおめえらさんたちそんなに詳しいんだ クロージャーキャッシングじゃなくてクロージャーのルートをキャッシュすることだし、
クロージャーすら分からんのはお前が無知すぎるだけ。 >>633
これはさすがにレス乞食だと思うからスルーで良いと思うよ 今年リリースされるLaravel9はどういう変更点があるのかな 噂だとBladeではなくTwigに変わるらしいけど本当なんだろうか ガセでしょ。envやめてyamlにするってガセ書き込んでる奴もいたし。リポジトリもツイートもほぼ毎日見てるけど、どっちの話一切見かけたことないわ。 5年後、laravel-mixからromaに切り替わってると予想 それなら知ってる。ただそれ持ち出すなら、まずlaravel-viteのほうが先だと思うよ。 テンプレエンジンはどう考えてもTwigにした方がいいだろ。
当時既にSmartyクソだってなってTwigがかなり流行っていたのに
なんでBladeとか独自路線行ったのか意味分からん。 twigもbladeも単体で使えるし、今のlaravelでもtwigをインストールすれば使える
そもそもphpのテンプレートエンジンとか使わんからどうでもいい
jsonさえ出力してくれればいいよ >>644
twigはbladeと比べて具体的にどこらへんが良いの？ >>646
それを説明できる奴なら黙ってblade使ってる説 BladeにはTwitterのaddFilterとかaddFunctionみたいなのないっしょ。 CodeIgniter4触ってみたけどなかなかいいですねぇ >>648
bootで独自ディレクティブ定義すれば同じことできると思うんだけど、それだと何か不満あるの？ 昔はフレームワーク無しでtwigだけ使ってたから懐かしい >>650
3が薄っぺらかったんだけど4で盛り盛りになったの？ お前らがSymfonyやCakeやCodeIgniterなどではなくLaravelを選択した理由ってある？
単純に世界中で人気だからとかではなくてなんか技術的な部分で 多分このスレには技術選定する立場の人間はほぼ居ない 脳みそ停止してるからあまり難しいこと聞いても無反応だよ フレームワーク無しやCakePHP,FuelPHPなどで色々組んでいたけど
Laravelがある程度名前が知られるようになった5年くらい前に切り替えた覚えが
それ以降は他のフレームワークには浮気していないな >>657
お前がそうだからって、周りもそうと決めつけるのは良くない。 >>657
んなわけねーだろ
このスレは零細と個人事業主がメイン層だから否応なしに技術選定する奴がたくさんいる
それなりに人数揃えてる企業に勤めてる奴はこのスレだとレアなんだよ >>663
それな
このスレには、やれスクラムマスターだのプロジェクトリーダーだのがLaravelを選んでそれに従ってる、なんて言う軟弱者はほぼ居ない。
「プロジェクトのプログラマは俺だけだ、だから技術選定も俺がする」って言う孤高の戦士がメインだから。 >>663
それなりにでかい企業だけど、事業部制だとサービスの規模次第では普通にやらされるぞ。技術選定。 >>664
> 「プロジェクトのプログラマは俺だけだ、だから技術選定も俺がする」って言う【孤高の戦士】がメインだから。
自分で言うかね？ ダッセ Laravel遅い遅いっていわれるけど実際実感したことないな
不特定多数の人からLaravelで作ったホームレスページにアクセスされたら遅くなるの？ >>667
それ主張してる人、単にOPcache使ってない説が濃厚なんだよね。 >>653
4は薄いLaravelって感じになってる
artisanコマンドに似たsparkコマンドってのが用意されていて
そのコマンドでコントローラとかモデルとかマイグレーションなどいろいろ生成して実装する Fuelさんはもう復活しないのかな
書籍はめちゃくちゃ評判よかったのに 速いとか遅いとか、ただの体感だからなぁ…。
こんなページでサーバからのレスポンス何秒で返ります、とか書いてくれれば比較のしようもあるんだけどね…。
ちな、Laravel使ってないオレのサイトのブログ風ページのレスポンス大体0.067秒くらい。
これ、メモリキャッシュ使わないでファイルI/Oオーバーヘッド有りの状態。 阿部寛のHPをLaravelで構築するとどうなりますか？ >>669
> artisanコマンドに似たsparkコマンドってのが用意されていて
もう、徹底的に引火にこだわってんのなｗ
あれITで引火にこだわると炎上プロジェクト連想されてすげぇ不吉なんだよね。PHPなら尚更。 Cake4の本が出てくれればいいのに、出ないよなぁ
Laravelのスレで嘆いても仕方ないことだけど そういえばLaravel最新のマイナーバージョンアップで、ついにページネーション時のlimit offsetていうクソ実装やめたな。 >>678
ページネーションする時にLaravelはlimitとoffsetを組み合わせてDB問い合わせしてるんだが、これはインデックスが効かないので件数の多いテーブルに問い合わせする時に著しいパフォーマンス低下を招く。
それを今回idとlimitを組み合わせて問い合わせる方式に変更したってわけ。 >>679
limitはできるけどoffsetはできなくなったということですか？ >>679
idとlimit組み合わせてoffsetができるの？ えー。ページネーション自分で実装したことないのかよ。取得したレコードの最後のidをキーにしてlimitと組み合わせて取得するって実装は古来より行われてきてたでしょ。offsetなんてそもそも要らん。 >ページネーションする時にLaravelはlimitとoffsetを組み合わせてDB問い合わせしてるんだが、
ここまでは、分かる。
> これはインデックスが効かないので
何これ？ なんでlimitやoffsetにindexが関係してくるの？
だってselect hoge from hage where a='b'←ここでしょ？ indexが関係するの
意味がわからないんだけど…。 >>684
issue読んだ？そこにも書いてあることだけど、少なくともMySQLは、offset+limitの位置までレコードフルスキャンして、そこからoffsetまでのレコードを捨てるという挙動になる。
だから大量データをページングしようとした場合、ページを進むごとにパフォーマンスが悪化していく。
当たり前の話だと思ってたけど、案外知らん人も居るのか。 ポスグレも同じような仕様だったと思う
最近のは知らんが 全DBそういう仕様だった気がする
DB実装している人たちもこの実装はおかしいと思わなかったのかな >>685
相変わらず、何言ってるか分かんない。
issueのって、idの番号に意味がある場合の話でしょ？つまりidの順番がそのままselect結果の順番になって良い場合のみの話。
ページネーションだから例えばブログ記事を例にするけど、idの順番って記事の登録順って事になる。
でも、最近更新された記事順なら全く意味なくなるでしょ。
id:1の記事をつい最近更新したけどwhere id > 10 〜 offset 10やられたらselect対象から外れちゃうもん。
そんなキー使っても意味ないでしょ。
>>687 も何言ってるか分かんない。
おかしいもなにも、こんなの当たり前じゃん。
極めて特定のケースというか、むしろDBの用途としてはほぼ使わないケースを例に上げておかしいと思わなかったのかなって、何？
>>688 に至ってはもう…。
どんなキー使うかは全く関係ないじゃん。
あなた達、何言ってるの…？ まじで分からん。
まだ俺が誤解してんのかなぁ…？ >>689
お前が何を分かってないのかがよくからんね。もう少し論点整理してくれ。みんなも困ってるじゃん。
ところで全然関係ないけど、bigintの92京はsignedだって知ってる？前にそんなことも知らずにここで人を小馬鹿にして暴れてたやつとお前の態度すごくよく似てるので同一人物かな？て。 >>687
別に変ではない。ページネーション付きのリスト表示つっても多くて数百とかならそこまで劣化しないだろうし、where条件が複雑になって辛いってのもある。
ただそうは言ってもoffset使いたくないて思うケースもあるのは事実で、↓みたいに国内でそこそこ有名なLaravelの使い手もoffset使わない実装を解説してたりする。
https://qiita.com/mpyw/items/b94b7d69146777f7a407 Laravelの公式の方々がやってることを意味分からんって言うなら
もうLaravelなんか使わずに自分で納得できるフレームワーク作りなよw
なんでこのスレに来てるのか謎 >>690
はぁ？ 何処が分からないって言ってる？ 日本語読める？ ページネーションの概念も現状の実装、DBの仕様や実装も含めて何も理解せずに、
「オレの考えが正義」の発想だから>>684や>>689みたいなことになるんだろうな
とにかく何かめちゃくちゃ勘違いしてることだけはたしかだが、
その態度がでかいから叩かれるw 俺様が使ってやっているんだから、ありがたく思え！
当然俺様の要望も全てのんで、実装しろ！
ってことかな？ アンチサロゲートキーおじさん、相変わらず健在なのか。いい加減、他所に行けば良いのに。 最近でもvue.jsとかreact使わないアプリ開発している人多いのか？
bladeでゴリゴリ画面作ってた昔が懐かしい お、本人再降臨か
句点ついてるし分かりやすくて笑えるw
もう言いたいことはなくなったのかな？
また面白いこと言ってこのスレ賑わしてくれよw Laravel9って今のところどういう変更点が予定されているの？ >>702
9はこれからだよ。リポジトリ見てるとそこそこ9に回されてるPRはあるけど目を引くものは無いかな。だいたい7月にデカイPRが入る。
というか8のマイナーバージョンアップで入ってきた機能も相当あるので、9を気にする前に8をキャッチアップしたほうが良いかもしれん。 Laravelでバッチ処理書いてみたけどやたら遅くないか？
CodeIgniterだと5分で終わる処理がLaravelだと1分かかる アクセスログ見たら、.env狙い撃ちしてるのあった。 このフレームワーク、ずっと完成しない気がしてきた…。 >>708
何でそう思うの？Laravel8の毎週の機能追加みてたら分かるけど、破壊的変更しない限り、8のマイナーバージョンにガンガン取り込まれていってる。だから9での変更点なんてそんなに無いと思うよ。
そして破壊的変更をそんないくつもマージするようなことは過去無かったので、8→9の変更点は少ないと予想している。 エアロスミスがLaravelのチュートリアルやりはじめたらしい Laravelで聴きたいことがあるんですが複合主キーってどうすればいいですか？
モデルのprimaryKey変数にどのように設定すればいいかがわかりません。 >>713
このスレで複合主キーの話題はNGなんだ
他のスレで質問したほうがいい ググればやり方くらい出てくるやろ
ただし動作の保証はしないけど そもそも複合主キーを使用する時点でDBとしての設計が間違っているから設計の見直しをしたほうがいい マジレスやめれ。前から荒れた話題が収まった頃に初心者のふりして同じ質問してくる芸風の、それこそバカの一つ覚えみたいな荒らし居たでしょ。相手にするだけ時間の無駄。 複合主キーそういえば対応していないな
他PHPフレームワークも対応しているのみたことがない
JavaだとSpring Frameworkが複合主キー対応しているけど >>719
逆だろ 初心者が質問したらそれを揚げ足取る連中が表れてスレを荒らすから
初心者の質問に誰も回答せず 結果再度初心者が荒らしがいなくなったころに
再度同じ質問をしなければいけない状態になっている >>721
こんなクソみたいなスレに、わざわざ質問しにくる初心者が居ると本気で思ってる？しかも荒れたら、間を置いて再度質問する？本気かよ。ピュアホワイトかよ。 実際Laravelについて気軽に質問できるのってこのスレじゃないか？
他にも質問できる技術サイトはあるけど初心者には敷居が高いだろう 複合主キーってどうすればできますか？という質問は
.envをコミットするしないで議論していたことに比べたらすごい真面目な質問だろ まぁ推奨しないから設計を見直したほうがいいというのが結論やろうな
複合ユニークは普通に設定できるしそっちにすれば良いかと お前ら複合主キーの質問が来ただけで発狂したのかなよ・・・・
さすがに技術レベル低すぎでは？ まあペチパーのリテラシーなんてこんなもんよ
これがRailsだったらイケメンがサラリとアドバイスするのに laravelで複合主キーのサポートしてくださいってissuesに上がってもよさそうだけど
みんな複合主キーサポートはそこまで望んでいないのかな >>727
ある議論で荒れて収まったと思ったら、同じ質問をするやつが現れるってことが何回も起きてるからね。>>719に書いた通り。 >>732
そもそも複合主キーのどこに荒れる要素あるんだよｗｗ >>733
>>140からの流れ見てもらえればわかるけど、サローゲートキーにオートインクリメント絶許マンが現れて荒れたんだ・・・。 複合主キーも設定できないなんて、Laravelってポンコツなんですね。
ガッカリしました。 質問なんですが、/var/www/htdocsをドキュメントルートとして
/var/www/projectでlaravelをインストールした場合、
http://sample.comでフロント側を動かし
http://sample.com/mngで管理画面を動かしたいです。
そのような場合、htdocsにmngというシンボリックリンクを張って、
（ln -s /var/www/project/public mng）
あと、フロント側はどうすればいいのでしょうか？
この方針だとまずい場合、どうするのが一般的でしょうか。 フロントは何で動いてるの？Laravel使うのはあくまで管理画面？ フロントもLaravel、管理画面もLaravel？プロジェクトはフロントと管理画面で別ってことかな？同じなら、別にシンボリックリンク要らんからね。 １つのプロジェクトでルーティングや処理を分けたいと思ってます。
同じプロくジェクトならシンボリックリンク不要でしょうか…？
ドキュメントルートの配下にプロジェクトを置くということでしょうか？
どういうディレクトリ構成にすればいいのか分かりません。。 というか、CMS付きのホームページをLaravelで作る場合、
どうやるのが一般的なんでしょうかね？ 同じドメインで1プロジェクトなら特に何も考えなくても良いのでは？
ルーティングでどうにでもなるでしょ？ これまでは
/var/www/htdocsにmngというプロジェクトでLaravelをインストール
↓
/mng/.htaccessに
RewriteCond %{REQUEST_URI} (\.\w+$) [NC]
RewriteRule ^(.*)$ public/$1
でリライトして管理画面を作ってました。
http://sample.com/mng
へアクセスして、
Route::get('/', function () {
return redirect('/login');
});
というルーティングでログイン画面へ、といった具合です。
「何も考えなくても」ということなので、私が何でもない所で悩んでいるような気は
するんですが、できれば具体例で「こうすればOK」というのを教えて欲しいです。。 あ、ちなみに最初のシンボリックリンクのくだりは、上記の方法で行き詰ったので
方法を変えたがまた行き詰った…という経緯です。 普通はドキュメントルート指定して、あとはroute/web.phpで、ユーザー用のURLと管理用のURLを定義するだけだと思うけど。なぜ上のような設定にしたのか意図がわからぬ。 特に意図してやったというわけではなく、URLで/mngにアクセスした際に
/mng/public/index.phpを実行させるためにこうしないと、と思っただけです…
「ドキュメントルート指定して、あとはroute/web.phpで、
ユーザー用のURLと管理用のURLを定義」の部分を具体的に教えて欲しいですm(_ _)m
http://sample.comでフロントのトップページ
http://sample.com/mngで管理画面のトップページ
としたい場合、
・プロジェクト名
・ドキュメントルート
・web.phpをどう記載するか
を教えて欲しいです。。
ルーティングのアクションは適当な例示で構いません。
質問ばかりですいません… これまでで管理画面（社内向けシステム的なもの）しか作ったことなかったので
ある意味上記の方法で悩むことはありませんでしが、根本的にやり方は良くなかった
のでしょうかね。そんな気がすごくしてきました。 そんなところで詰まってたら永遠に完成しないと思うぞ
ルーティングの基礎の基礎なんだから、ちゃんとドキュメントみてしっかり考えようや
https://readouble.com/laravel/8.x/ja/routing.html ドキュメントルート直下にmngという名前でLaravelをインストールして、
mng配下の中身をルート直下に移動→.htaccessで
RewriteCond %{REQUEST_URI} (\.\w+$) [NC]
RewriteRule ^(.*)$ public/$1
とすることで
Route::get('/', function () {
return view('welcome');
});
Route::get('/mng', function () {
echo 'test';
});
とすることで、フロントと管理画面を分けられそうです。
これが一般的な方法でしょうか…？ viewはpublic似ないのに何故そんなよくわからないことをするの？ 起点となるのは/public/index.phpなので、publicをURLから省くための
何らかの処理がいると思うんですが。。 シンボリックリンクとルーティングだけで普通にできないかね？
まあ、何したいかもよく分からんし、それで動くならそれでええやん ルーティング難しいよなぁ
htaccessが絡むと余計にわからなくなる 何度もすいませんが、その場合ドキュメントルートを/publicに指定するということでしょうか？
シンボリックリンクはどこからどこへ張ればいいのでしょうか。 >>737
Alias使った方が良いんじゃないの？
考え方としては別ドメインと同じなのでLaravelを2つインストールする。
https://www.javadrive.jp/apache/ini/index12.html 俺がヒマだったら予約システムぐらい、Laravelでさくっと作ってやるのに 日本のITオンチっぷりがシャレになってない感じだから、自分の技術力で何とかしてやりたいと思うことはある すいません。こちらいかがでしょうか…？
>>755 うちにもcomposer使えない環境へのデプロイ必要な案件来てしまった
しょうがないからvendorコミットしたわ 俺みたいな古い人間は、composer使うと抜けがあるのではないかと心配してしまう composerが使えない環境って
社内LANみたいな感じで外部と一切つながってないって事？
まぁ、社内システムなら社内のネットワークだけで閉じるというのはありそうだけど >>766
その通りです。社内のネットワークしか繋がっていない環境です。 >>750
そもそもドキュメントルート直下にインストールすることを想定したフレームワークではない
管理画面もフロントだと思うんだけどこのあたりしっかり説明してもらわないと
求めている回答が付かないと思います >>771
あなただけじゃないと思うけど、php自体やその他の更新頻度を見ると、現実的に仕方ないかなぁとも思う >>770
広い意味では管理画面もフロントですが、私の言うフロントは
公開側という画面と言う意味です。
たしかに、公式のドキュメントにもそのように記載されている
のは承知していますが、管理画面とフロント側をどのように
分ければいいのかが分かりません。
公式の推奨に従ってhtdocs（Webルート）と同階層にインストール
したとして、
http://sample.com/mng
というアクセスでLaravelアプリケーションを動かそうと思うと
htdocsに「mng」というシンボリックリンクを張ればいいと思いますが、
（ln -s /var/www/project/public mng）
http://sample.com
というアクセスで同じ「project」というアプリケーションを
動かすにはどうすればいいのでしょうか？
そこさえクリアできれば、あとはルーティングでどうにでもできると
思うのですが。。 teratailだと切れた常連エンジニアに説教食らいそう。 rewriteのルール(ドキュメントルートの.htaccess)はLaravelのデフォルトのままで良くて
そもそもシンボリックリンクなんて使う必要も無く単にルーティングで分ければ良いだけでは？
rewriteもフレームワークを使わず直接phpを動かす場合はURLのパスの部分がそのまま
ドキュメントルートからのサブフォルダの階層にはなるが 出来の悪いコロナ予約システムにLaravel使ってる噂 むしろ何で分からんのや。マーソて受託した会社の採用ページみたり、ソースみりゃ分かる。 inputタグの属性でcakePHPてはっきりわかんだね。 NGワードひっかかってURLが貼れないわ
見様見真似でcakephp使ってるらしいな
https://i.imgur.com/nLDH7s5.png
2019年に書かれたブログ記事 マーソの話題はスレチなのでcakePHPスレでやって >>773
だからAlias使えばいいじゃん。Apacheじゃないの？ 案の定、NginxでもAlias使えるし。
人の話、ちゃんと聞きなよ。上の方で一回言ったよ？ 入力された電話番号が正しいものかどうかって判定するには実際どうすればいいんだ？
入力された電話番号にショートメールで認証番号を送信して
それを再度入力しないと登録が完了させないようにするとかになるのかな >>791
SMSを使って確認する方法も微妙に穴があるけど、それぐらいしかないのも事実 新しくlaravel始めることになりました。
COBOLからの乗り換えなんで爺さんには大変です。 自分の環境だとGNOME40になってからEloquentが動かなくなった
GNOME40とEloquentはまったく関係がないはずなんだけど・・・・・ >>795
海外だと勘定系がLaravelはあるんだぜ・・・ >>774
>>770の方法でやろうと思う理由ですが、Laravelを2回インストールしたくないからです。
回答が遅くなりました。 勘定系をPHPのシステムでって、端数丸め対応が大変そうだな。 6月からLaravel勉強しようと思ってるんだけど、
ちょうど6月に販売される本って高いね。4000円超える・・・
みなさんはやっぱりオンラインマニュアルで覚えたんですか？ >>801
あなたの今の知識次第だと思いますよ
PHPとインフラ/ミドルウェアに対しての知識が十分であれば、公式が最も適したドキュメントになります ググる時間がもったいない
本1冊を一気通貫でやるのが最短
4000円なんて技術者１〜２時間の人件費でしょ？
本で節約できる金額考えたらおつりがくるよ Laravelの本のターゲット
・MVCが初めて
・PHPが初めて
・Laravelが初めて
・お金をケチらない
一個でも外れてるなら買わないでドキュメント読んだほうが良いと思うよ
というか全分当てはまってる状態でLaravel始めても尚更訳分からんと思うからやっぱり個別に覚えたほうが良いと思うけど >>804
全部外れてるけど、「ドキュメントがわかりづらい・理解できない」ですよね・・・ >>801の本の詳細説明みてからコメントしてる奴おりゅ？
あの本はLaravel8の解説書ではなく、Laravel8に対応した「ぼくのかんがえたさいきょうのせっけい」を読まされるだけじゃね？ADRとか言ってる時点で論外。中級者以上なら参考になるかもしれないが。
それよか、ちょうどドットインストールがLaravel8の入門公開してたからそっち見たほうが良いと思う。 >>806
そうなんですか・・・危うく買ってしまうところでした
今の時期は本屋にも行きにくいし、中身確認できないですからねぇ Laravelに関しては本と公式だと完全に公式の勝ち
まだ出てない本は知らんけど、余程じゃないと勝てんぞ Laravelの公式リファレンスはある程度の技量がないと読み解けないと思う
職人のためのフレームワークだからそれでなんの問題もないけどね
あれを読み解けないなら本を買うのは普通にありだと思うよ
分かりやすいわかりにくいはあるけど、だいたいは公式リファレンスよりかみ砕いて書いてある
ただ、今月出るやつは2回目の改訂だと思うが、ADRとか書いてあるし、
書いてる人がアンチFacadeだしで初心者向けではない感はある 昔よくあった掲示板の作り方のように
何か作りながら機能説明してくれる方がわかりやすいと思う >>811
時間があったらそういうのを１から作るというのを解説したブログとかを書いてみたいんだけどね
今ならyoutubeで解説したら見てくれる人はいそうだけど
そんなの作ってる時間ないな Youtubeは逆に難しいと思うぞ
動画を再生したり停止したりって動作が面倒すぎる 自社パッケージをLaravelで作っているがバージョンアップ多いので辛そう。
LTSで作って次のLTSでバージョンアップっていうのが王道なのかな？
メンテナンスとか保守とかが辛くなってきそうだ。
ライセンス問題が解決したCodeigniter使った方が良いのかなって思い始めてる。 確かにバージョンアップ頻発するとつらいね
そういう点でうちはCakeのままのがあるわ >>806
ドットインストールのお兄さんの声ってイケメンだよね >>814
王道は「バージョンアップなどしない」だぞ
テストやらのコスト考えると3年やそこらでメジャーバージョンアップとか却下 Laravelはlaravel-shiftて有償のバージョンアップ支援するサービスがあるので、それ使えって話で終わる。LTS→LTSなら7000円ぐらいでできるはず。 お前らの蔵なら作ったらほったらかしが基本だろ？
10年前に作ったCake1のシステム、CentOS6のPHP5で元気に稼働中 いや普通にバージョンアップ計画立てるが。趣味のサービスでさえ、6→8にしようと進めてる。 >>820
でもその毛髪をカウントするWEBアプリってバージョンアップする意味あるの？ 普通はわざわざLaravelのバージョン上げることもないよね
よっぽど重要なシステムなら運用中もそれなりに人材いるだろうけど大抵は運用中はそもそも開発した会社は完全にノータッチの事も多いだろうしね >>821
ハゲのお前には、バージョンアップのメリットは理解できないかもしれんな。 >>822
Laravel、今年だけですでに3回も深刻な脆弱性みつかってるから。
ignition由来のやつはまぁいいけど、バインド変数のマッピングの脆弱性は6より前のバージョンだと修正されずに放置はされてるはず。
作って納品して終わりみたいな人達はバージョンアップに縁は無いんだろうけど、運用している奴らはバージョンアップしないと自分のこと首を絞めることに。 脆弱性って言っても、コロナ予約システム並みじゃなければ
そうそうデータが盗まれるとかはないんじゃね？ >>817
なるほどです。
>>818
shiftの存在は知っているけど、その後にshiftでマイグレーションされたパッケージを全機能とかチェックするテスト工数は省けないわけで。 >>814
PHP、Laravel、自社アプリすべて常にバージョンアップを続けてる
多少の不具合は許される環境だから出来ることだと思うが
少しでも手を休めたら逆につらい そらそんな必要ないからな
客が納得して納品したら終わりや 今までの経験だと自社サービス開発、受託開発問わず、ほぼ確実にエンハンス開発はあるんだけど、このスレでは納品して一切触らないケースがほとんどなの？ 一切触らないケースが多いな
中小零細だと継続依頼ってなかなかないぞ >>831
受託開発した後に納品先に切られて別の開発会社に乗り換えられてる説 >>831
触らないケースが多いね
顧客がバージョンアップや新機能追加などの開発費出す余裕がないから エンハンス開発が無い = 作ったシステムがビジネスとして成功しなかった
だからね、ビジネスとして軌道に乗るなら改良もするが、軌道に乗らないきゃ改良なんてしない どの世界でも当然の話しなんだが、金出さないと成功しないからな
初期投資だけで成功すると思ったら大間違いだ >>831
そもそも完成するまでの依頼でその後依頼された事なんて無いからね
メンテなんて安い所に頼めばいいとでも思ってそうだけど
他人のコードを理解する方がよっぽど高度なのにね・・・ >>838
それ、冗談抜きでめちゃくちゃあるよな
あれだけ作る前にやりとりしてたのはなんだったのかと言いたくなる >>838
社内システムとかクローズドなシステムの開発が割と多いからそもそも納品した後で稼働しているか確認する術も無いけどね >>840
>>841
うちもB2Bばかりなんだけど客の担当がノリノリでも、現場が新しいもの使いたがらなくてなかなか移行できない…みたいに見える、想像だけど
納品後も客が管理者IDとPASS変えないから入れちゃうのでたまに見ると、データ増えてない あ、そう言えば納品してサヨナラじゃなかった今思い出した
SSL証明書の更新だけは毎年依頼されるｗ >>842
え、それちゃんと許可貰って覗いてんのか？ >>842
納品したシステムに勝手に入ってデータ監視とか終わってるなLaravelはｗ >>846
laravelは関係ないけど842の頭はヤバいな クエリビルダしか使わない場合、モデルは書かなくても良いでしょうか？ >>848
普通はLaravelのドキュメントに書かれているような
DB::table('tests')->where(条件)->get()
みたいなやり方よりはTestモデルを定義して
Test::where(条件)->get()
みたいに書く方が良い気がするんだけどね
テーブルが複数名でプライマリーキーがidならモデルのクラス作っておけばいいだけだし
（実際にはguardedなどは定義した方がいいけどひとまず置いておいて）
モデルを全く定義しないプロジェクトなんてやったこと無いから分からないがｗ DB::table('tests')->where(可変)->where(固定)->where(固定)->orderBy(固定)->get()
みたいなのがコントローラに延々並んでいるよりはモデル作って
Test::getSomething(可変)
みたいにした方がスッキリするんちゃう >>848
書かなくて良い。でもそんなシステム触りたくないわ。バッチなら良いけど。 >>842
それ大丈夫なの？
依頼があって見てるわけじゃなくて自ら勝手に見てるんでしょ？ >>842
それ許可なくログインはアウトだろ・・・・ > Test::getSomething(可変)
> みたいにした方がスッキリするんちゃう
やってる事が昭和だな。 >>856
どうゆうこと？>>850はローカルクエリスコープの話してるんだなって思って読んでたけど。 すいません。>>737 の質問をした者です。
自己解決できたので一応。
Route::get('/', function () {
return view('welcome');
});
の「'/'」の部分を、サーバーのルートからのファイルパスだと
間違って認識していたのが原因だったみたいです。
htdocsと同階層にLaravelをインストールして、
/htdocs/public/index.phpでパスだけ変更、
サーバーのルートを/htdocs/publicに設定することで
あとはルーティングでどうにでもできそうです。
>>746
で仰ってた意味がやっと分かりました。
色々すみませんでした。 >>857
いやスコープならscopeから始まる名称じゃないと駄目じゃない？
getから始まってるってことは昭和な書き方だよ 確かにローカルスコープを使うにはscopeから始まる名前にしなさいと
Laravelのドキュメントには書いてあるけど 実際はscopeから始まらなくても使えるんだよ 前スレのこういうレスがあったので
パフォーマンスを重視するならクエリビルダを使うってことでモデル不要なのかなと思いました
35 名前：nobodyさん [sage]： 2021/02/27(土) 09:16:39.22 ID:???
リレーションシップで取得可能かつクエリもパフォーマンスに影響が出ないものならeloquent。それ以外はクエリビルダ。 scopeの件理解した、なるほどそういうのがあるのか
でもやりたいことは単にgetという想定なのでメソッドはgetでいいと思う >>859
いやいや、そりゃモデル内で定義するときはscopeGetSomething()だけど、
呼び出すときはTest::getSomething()でしょ。
ただ命名のことを問題にしてるってことは理解した。
それについてはget()まで含むクエリスコープなら、getから始まる名前つけるのは悪くないと思った。 >>863
それ書いたの俺だけど、意図としては原則Eloquent使って、例えば数万件のデータをバッチでfetchするときはクエリビルダ使うってこと。
詳細画面や一覧画面とか表示する分には、クエリビルダのほうが速いって言っても誤差の範囲だから使う理由はない。 故人的にはgetSomethingよりもfindSomethingのほうが好きだな
Test::getSomething()->get()
Test::findSomething()->get()
となるかの違いでしかないけど >>868
1件あたりのデータの取得時間の差はμsレベルだぞ。単にmodelオブジェクトにhydrateするかしないかって話だから。
その上でどれぐらいの同時アクセスを想定してる？そのレベルの誤差を気にする前に、サーバーのスケールアウトを考えるべきだと思うけど？ >>867
故人www生きろ！
てツッコミは置いといて。
それだと条件クエリをビルドしているだけだから、getもfindも論外だと思うな。加えてLaravelではfindは主キーを使って検索するってコンテキストになってるから、getより筋が悪いまである。 >>867
>Test::getSomething()->get()
getSomething()の中でgetもやるから->get()はいらないんだよ、なんならget後の加工までやるぞ
findの方は知らん getSomething()の中でget発行したらダメでは？
あくまでもローカルスコープはクエリの組み立てまでにとどめるべき いやだからLaravelのスコープとは関係ないんだってば
単に便利なgetメソッドを関数として書くだけ、目的はコントローラ内の記述を減らすこと > 単に便利なgetメソッドを関数として書くだけ、『目的はコントローラ内の記述を減らすこと』
こういうのをControllerに書かざるを得ないという仕様な時点で狂ってる。
CakePHPとかと一緒。 >>874
そんな制約はLaravelに無いよ
勝手にそんなアホな実装してる奴がいるだけ アプリのソースをどういう構成にするかは作る側が決めることだよね コントローラにすべての処理を書くのを批判する奴がたまに居るけど
どこに書こうが一緒やん
大規模になればDIでコンストラクタでサービスのインスタンスを受け取る手法もありとは思うが
そもそも殆がDIする必要もないしな >>840
予算の都合だよ
これ以上知るとバカらしくてやってられなくなるぞ >>879
これ実際どんな弊害があるのかな？
モデルに関する処理は長々とコントローラに書かずにモデルに書いて、共通処理は別の場所に書けば、コントローラで処理を書いてもそこまで長々と書くこともない気がする
それをサービスに追い出したところでサービス側がコントローラと同じようになるだけだしあんまり意味がない気がしてならない 共通化できそうなところは共通化して使いまわさないと改修時にコピペ箇所の改修漏れが発生しやすい 複数のコントローラで利用したい処理を1ファイルにまとめたいのですが
CakePHPのヘルパーに相当する機能は何でしょうか。 >>882
継承かトレイトかライブラリ化、用途に合わせて選べ >>882
Laravelは「継承よりコンポジション」てモダンな考え方に基づくから、traitを使うことが多い。 ただ共通化て言葉は、ベテランのエンジニアがよく警鐘を鳴らしているものだから、本当にその共通化が必要なものかはよく考えた方が良い。 ファットコントローラーの害が感覚的にわからないならプログラマとして必要なセンスがない
Cで言うと全部main関数に処理書いちゃってmainがバカでかくなってる初心者みたいなもん その説明では納得しないでしょ。ファットコントローラーがダメな理由は、コントローラーの責務を無視して処理を追加した結果だから。
責務を無視してしまうとMVCの構造が壊れてしまうので、MVCがメンタルモデルとして定着しているエンジニアは、そのコードを読んだり改修することが極めて困難になる。 つかそういう事は10年前1万回議論されて結論出てるんだから
ググレカスって話だよな >>883,884
トレイトを使う場合、のディレクトリに保存するのでしょうか？ >>890
正解は無いんだけど、俺の場合controller用なら、Controllersディレクトリ配下にConcernsてディレクトリ作ってそこに格納する。
このやり方はRails由来だね。ただLaravelの人気パッケージでも取り入れられている手法でもあるので、お勧めしておく。 そういや
php artisan make:trait
ってコマンド結局まだ実装されてないんだっけ？ ファットコントローラーって名前が嫌だからコントローラーは太らさないようにしてる 別に最初はコントローラーファットでよくない？
途中のリファクタリングの過程でファットでなくすりゃいいだけだし 俺はControllersにTraitsってディレクトリ作って入れてたな >>892
そんな議論て過去にあったの？traitてPHP側で実装されたものじゃん？ 自作でartisanコマンド追加してる人は結構いるってくらい 誰一人としてファットコントローラーがダメな理由を納得出来るレベルで言えないのだから
結局外に追い出した所でそこのコードは同じことになるのだしなぁｗ
意味ない論議なんだよ お、煽りおじさんがきたぞ
いい天気なんだからぬこの散歩でも行って来いよ コードを書けば行数が増えるのは当たり前で、大きくなるのが嫌だからどうにかしようというのは、そもそもが違うよね。
行数増えて困ってる人というのはIDE使ってないの？何なの？ 下手な逆張りしてケンカを煽ろうとしても無駄だぞ
盛り上げたかったらもうちょっとマシな話題持って来いや ファットコントローラ解消してもファットモデルになるだけ 結局どこかには処理を書くのだから別に外に追い出した所でそれがベストですって
言う説明をしていたらそれこそ初心者レベルかと
同じ処理を何度も書かないとか基本的な事を守れていたらいいと思う
そこをコピペとかでやってたりするのは明らかに初心者だろうが >>904
じゃあファットコントローラーは何故ダメなの？ ダメな理由が全く納得いかないものしか無いやんｗ
頭悪いからダメと言うしかないの？ｗｗｗ 真面目にここにいる奴仕事で作ってるの？ｗ
お前のコントローラーは実装が数行しか無いの？ｗ
趣味の奴はでしゃばるなと思うわｗ クラスごとに適切な役割分担をしようって話でファットコントローラーだからとかファットモデルだから全部駄目って単純な話じゃないでしょ
モデルだけで不十分ならRepositoryパターンやValueObjectパターンや他のデザインパターンも入れれば良いし、コントローラーとモデルだけで話が完結する話じゃないじゃん >>909
ファットコントローラーはダメという単純な話だよ
ダメじゃないケースはないから >>902
いや普通ミドルウェアとかトレイトに持たせるやろ >>911
コントローラーってRouteに対して固有の処理になるから固有の処理ならしゃーないけど
共通化できる処理ならできるだけ括り出して外に持たせるべきじゃない？ >>912
ミドルウェアとかトレイトならファットになってもいいの？ >>898
>>888で納得できない？もっと掘り下げて説明してほしいなら、どの辺が納得できないか教えてくれると助かる。 コントローラーってのは処理の流れをコントロールするものなんだよ
データの加工みたいなゴチャゴチャした処理をする場所ではない
これだけのことなんだがわからんか？ >>914
処理単位でそれぞれ分けるならファットにならないぞ >>909
ファットコントローラーはとにかくダメだって言ってる奴いるけど、そいつは無視して良い。
何故ダメかは>>888に詳しく書いたから読んでみてくれ。結局のところファットコントローラーてのは、単なる設計ミスの産物だからダメなのであって、もしコントローラーの責務に見合った処理を書いた結果、なおファットコントローラーになってるなら、別に問題無い。 >>918
>>909はよくわかってるやつじゃん。釈迦に説法だった。 馬鹿しか居ないのかなんなのか知らんけど、
『ファットコントローラー』っていうのは状態であって、手法じゃねぇの。
Controllerに書くべき物で溢れてるなら、いいんじゃねぇの？ファットでも。
問題なのは、本来はModelに書くべき処理を全部Controllerに書いている状態の事。
Railsとか使ってMVS分かった気になってるヴァカはModel=DBにアクセスする物…
みたいな腐った誤謬を持ってるけど、
本来ビジネスロジックを書く場所がModelなので、
それがControllerに書いてあったら、
おまえ、ﾌﾟｷﾞｬｰ
なの。わかったか？ヴァカ共 MV"S"ってなんだよ？タイプミスったわ。
よし、ここからSの定義が何なのか議論始めるぞ。 てか、上で俺含めその説明してるでしょ。むしろ、理解してる奴の方が多いぐらいじゃね？ Controllerに書くべき物がそんなに溢れることってある？
余程でかいシステム作ってるのか JavaのSpringFrameworkだと
Controller、Model、View、Repository、Serviceに分かれるな ModelにDaoとRepository両方書いてる奴は居そうだな お前らのソースコードってすごいカルボナーラになってそうだな ああそうかDBアクセスのクエリとかModelに書いてしまえばコントローラーからはメソッド呼び出しだけで済むのか >>925
EloquentてORM使ってんのにDAOて単語が出てくる理由がサッパリなんだが説明してくれる？
その上でRepositoryてDDDのデータ操作レイヤーの話だと思うんだけど、お前はModelに書くことに否定的な立場なの？
上でも出てるローカルクエリスコープは、このデータ操作をビジネスロジックとして表現するための機能だから、俺の認識だとModelに書くのは至極当たり前に感じるんだが。 公式ドキュメントでもクエリビルダのレクチャーはコントローラー内に書いてあるがな DaoもDtoもEntityもRepositoryも全部Modelの役目だよ >>931
Eloquentとクエリビルダの違い理解してない人？ この馬鹿は一体何を言い出したのだ、お前たちよ。
932nobodyさん2021/05/23(日) 17:43:16.84ID:???
DaoもDtoもEntityもRepositoryも全部Modelの役目だよ そういや次スレﾜｯﾁｮｲのあるこっちでいいんじゃね？
【PHP】Laravel【フレームワーク】 Part.5
https://mevius.5ch.net/test/read.cgi/tech/1618480141/ >>932本人じゃないからわからんけど、 MVCを前提にした場合、controllerの役割とviewの役割は具体的に明示されているから、それ以外の全てがmodelにぶち込まれるってことを表現してるんじゃないか？
だから馬鹿とは思わなかったけどな。逆になぜ馬鹿と言い切れるのかその根拠を知りたい。 他のテーブルとのjoin操作までModelに入れるのはなんか違う気がするんだけどその辺どうしてるの？ >>937
人の話聞いてんのかな？ ModelはDBにアクセスする物じゃねぇんだから、
Modelとテーブルが１対１なわけねーーーーーーーだらーーーーーーーーーー！
937nobodyさん2021/05/23(日) 18:01:50.48ID:???
他のテーブルとのjoin操作までModelに入れるのはなんか違う気がするんだけどその辺どうしてるの？ >>937
そもそもEloquent使ってたらjoinなんて使わないでしょ。クエリビルダ使いたいなら、DBファサードになるからmodelは呼び出されず、必然controllerで書くだろうさ。それが嫌なら層を増やすべきだけど、MVC話の文脈とズレていくだろうからそこはスルー。 >>939
お前、Laravelまともに使ったことないでしょ。EloquentModelの特殊性を全く理解できてないように見える。もしかしてアンチサロゲートキーおじさん？ >>933
ラッピングされてるだけで一緒のものやぞ
$any_table = AnyTable::where(...)->where(...)->where(...)->select(...)->oderBy(...)->get();
$any_table = DB::('any_tables')->where(...)->where(...)->where(...)->select(...)->oderBy(...)->get(); EloquentModelつーかActiveRecordて概念を全く理解していないというのが正解か。 >>942
ラッピングしているというのはそうだけど、それ以外は全然違う。まずクエリビルダはModelを介さないのでデータ操作を隠蔽できずcontrollerに操作を書くことになる。さらに結果はmodelへのhydrateの工程がないためDBから受け取ったデータは標準クラスになる。当然castできないから、ぜんぶstring型という悲劇。 別にControllerにDB処理書いてもいいと思うけどな
Laravelのドキュメントも思いっきり書いてるし >>945
まあ大多数の人はそうしてると思うけどね
ただモデル側に書いた方がシンプルなコードにできるってだけでそれでマウント取るのはホント意味わからん LaravelどころかMVCを全く理解してない奴がゴロゴロいるんかこのスレ
だめだこりゃ MVC理解していないのってお前らの大半やろ
Modelに関する処理をModelに置けば
Controllerは何やっても問題無いやろ
それを何の根拠も無くファットコントローラーｗとか言っているのだからｗ
それ外に追い出したらコントローラーの記述が減ってるだけやろｗ ところでお前らLivewireかinertia使ってる？ >>949
落ち着け。それでログ読め。ファットコントローラーを頭ごなしに否定しているのは1人だけだぞ。 Webサービスでの画面遷移について質問があります。
画面Ａ →(POST)→ 画面Ｂ →(POST)→ 画面Ｃ
と、遷移させたいとします。
で、画面Ｃで受信したPOSTデータにエラーがあったら画面Ｂに戻りたい。
このとき画面Ｂでは、画面Ａから先にPOSTされたデータと、画面Ｂで先に入力した値を再表示させたい。
そこで質問ですが、
・画面Ｂや画面Ｃでは、受信したPOSTデータをセッションに保存するように作るのでしょうか？
・画面Ｃから画面Ｂに戻るには、redirect()を使うべきか、それとも $this->画面Bのメソッド(); を呼ぶのがいいのでしょうか？
教えてください。
お願いします。 そういう場合は、画面Bから画面CにPOSTするんじゃなくて、
画面Bから画面BにPOSTして、エラーが無かったら画面Cにリダイレクト >>952
ファットコントローラー否定派は俺以外に少なくとも1人いる。
MVCはMがアプリケーションでVとCは単なるUIなんだよ。Mにビジネスロジックは全部書く。UIがWebだろうがコマンドラインだろうが独立して動けるようにMを書く。
なのでバリデーションやDBアクセスはMに書くべきで、Cには認証やらGET/POSTの処理やらクッキーアクセスetcを書く。
それが本来のMVCだが、Laravelのドキュメントが違ってるなら、厳密なMVCを目指してはいないのだろう。別にMVCだけが正解なわけでもないから。 まー、955が正解だわな。
949みたいなオレオレMVC論を唱える奴がいるところが、ららべらーの次元の低さを如実に表してるな。 >>955
いや、「頭ごなし」に否定してる人はってことね。MVCちゃんと理解して設計してねって話をしてる人が大半だと思ってて、ファットコントローラーはその設計に失敗した結果だからダメって言ってると思うんだよね。
俺が書いたのは>>888や>>918ね。 バリデーションがMって違和感があるんだけどそんなもん？ >>958
LaravelはControllerかその手前のFormRequest、 RailsやCakePHPはModelでやってた気がする。 俺はCakeを触ってたからバリデーションをControllerでやってるLaravelのドキュメントに違和感ある >>957
MVCちゃんと理解して設計したら、ファットコントローラーにはならないというのがMVCの思想なんだけど、違うか？ >>961
そんなことはMVCのオリジナルの論文には書かれてなかったと思う。
元々は、ユーザーのメンタルモデルに沿った形でアプリケーションを再利用しやすいよう分割しようってだけの話だったかと。一体何を読んでその理解に至ったんだ・・・。
↓オリジナル
https://www.semanticscholar.org/paper/The-Model-View-Controller-(MVC)-Its-Past-and-Reenskaug/ff2ada602c96499c0f8a634e26c2c58ef8ec490f >>962
何を読んでって、Skinny Controller, Fat Modelってあちこちで言われてきたじゃん
と思ったらこれってRailsの話で結構古い記事なんだな、今の人は知らん＆また違うのかも知れんな >>962
オリジナルって何だ？MVCの概念自体は1970年代からあるものでその論文？はそれを研究してまとめたものじゃないの？
コンピューターサイエンスにおけるMVCにファットコントローラーの話は出て来ないかも知れないが、
ここではWebフレームワークにおけるMVCの話をしてるんだと思う 捨て垢でもいいのでQiitaに持論をまとめてほしいです Skinny Controller, Fat Modelでぐぐるとキータすぐ出てくるやん
今まで散々議論されてる話題だし >>964
・MVCそのものにはFat Controllerなんて概念は含まれていない
・Rails以降WebアプリケーションでMVCが使われ出して、正しくない実装によるFat Controllerが問題視されるようになった
てことなんかな
でその後果たしてFat Modelって本当に正しいんだろうか？という議論が起こり、EntityやらRepositoryやらに分割したり、
Webアプリの実装に特化したLaravelではRequestにバリデーション機能を持たせるようになったりしてると >>968
MVCていうとJavaはstrutsとかもっと前からあるし、PHPならMojaviとか。Railsはもっと後発。初期のMVCフレームワークは、原則に従った結果としてcontrollerの役割が肥大化する傾向が指摘されていた。
railsあたりで色々変わったんだよね。入力値の検査をなぜかmodelでやるようになったり。
Laravelはrailsリスペクトなのに、例えば入力値の検査は オリジナルのMVCの原則に従ってたりする。
なのでMVCの原則通り設計してもファットコントローラーはあり得る。あとはフレームワークのベストプラクティスに従うかどうかに依存している。だから>>918のような言い方にしないと人によっては反発されてしまう。 > LaravelではRequestにバリデーション機能を持たせるようになった
Controllerにバリデーション機能を盛り込む
Modelにバリデーション機能を盛り込む
Requestにバリデーション機能を盛り込む
全部やってる事一緒じゃん。
なんで、バリデーションを行う専門のアーキテクチャを実装しねぇのか頭かち割って苺シロップかけてた方がいい。 LaravelにはFormRequestていう専用のクラスにバリデーション関係を切り出せる。>>968が言ってるのはおそらくそういうこと。
だから「全部やってること一緒じゃん。なんで、バリデーションを行う専門のアーキテクチャを実装しねぇのか頭かち割って〜」て発言の真意が、ちょっとよく分からない。 >>971
結局それはRequestにバリデーション機能を盛り込むってことだろ？ >>972
はて。話が通じていないような？Requestにバリデーション機能を持たせるって言葉をどう解釈したのか知りたいなぁ。 横だが俺も>>970が何言ってるのかわからない
そしてそれは>>970のせいだと思う バリデーションはモデルに書くようにしないとCLIで必要になった時困るぞ
その必要が絶対無ければFormRequestでできるのは便利だとは思うが… Laravel動かすならapacheの方がいいでしょうか？
ほぼ動的コンテンツになる気がするのですがnginxでLaravel使ってる人も多いようで迷います 素人はapacheにしときなされ。nginxの場合それだけでは動かないからphp-fpmあたりも組み合わせなきゃいけない。 >>978
どちらかというと今までnginxばっかり触っていてapacheは初めてです 今どきQiita見りゃnginxの設定くらい余裕やろ じゃあnginxで良いじゃん。どこからapache出てきたの・・・ >>981
nginxは基本的に静的コンテンツに強いサーバで本来phpのような動的コンテンツを動かすようなサーバではないです
動的コンテンツは基本apacheなので自分もapacheにしようと思ったのですが調べたらLaravelで作られたサービスは
nginx上で動作させていることが多いと分かったので疑問に思って質問しました。 マジレスするとLaravelはnginxにあわせて最適化されたフレームワークなので
政敵コンテンツが特異なnginxであってもLaravelならnginxを使ったほうがいい フレームワークにApache向けとかnginx向けとかあるの？何が違うの？ 大体ApacheなんてApacheの方が使いなれてる、xamppで手軽に環境が整う、どうしても.httaccess使う必要があるくらいの理由以外で選ぶ必要がない 表向きはnginxバックエンドでapacheの中でlaravelをうごかせばOK 特殊な事情がないかぎりは
今どきApacheを積極的に使う理由は何一つないと思うが >>988
> 今どきApacheを積極的に使う理由は何一つないと思うが
何故？ 設定が簡単で.htaccessも使えるからApache使ってるわ Apacheの方が情報量多いし馴染みがあるからなぁ
XAMPPなんかでローカルでも使えるし このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 39日 8時間 23分 12秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
