【PHP】Laravel【フレームワーク】 Part.5
■ このスレッドは過去ログ倉庫に格納されています
テンプレ追加修正お願いします
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/ 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という概念を知らなかった初学者
どっちだ ■ このスレッドは過去ログ倉庫に格納されています
