【PHP】Laravel【フレームワーク】 Part.8
レス数が1000を超えています。これ以上書き込みはできません。
コントローラーで共通の処理を別ファイルにまとめるのはトレイトを使うのはlaravelの流儀ではないと思うんですが先輩方のご意見を伺いたいです。
サービスを使うのが流儀だと思いました。 別に使って良いと思うが
流儀なんていちいち考えてたらキリがないよ コントローラーの共通の処理があるなら、コントローラーの基底クラスに実装するのがOOPとしての当たり前の考え方だが、
Laravelerは馬鹿すぎて、OOPの基本のキすら分かっていないためにtraitなどと宣わり始める。
マジで、Larqaveler動物園。 ドキュメントにトレイトを使ってくれって書いてないもので。。。 自分でかいてるアプリなら自分の好きにやりなよ
他人がどうこうとかいちいち気にするな
チームでやってるならリーダーにちゃんと聞いてそれに従え そのへんの自由度が、railsやcakeとかと違うところだよな。
この場合こうして書くべきという、宗教じみた思想がフレームワークに欠けてる。
あぁ、.netもそんな感じだよな。 何やってもいいなら、もう、フレームワークの価値ないじゃん。
単純にライブラリにバラして好きに使ってってやった方が良い。 他人に迷惑かけない限りは好きに使えよ
価値がないと思うなら使わなければいいだけだ >>12
それ同じ事で悩んだ
まさか基底クラスを汚したくないから、結局サービスにしたけど
カーネルに書くと言う手もあったかな
でも静的な便利クラスを作ってインポートすりゃあ良いんじゃないかな、チームだと嫌がられるかも知れないが。 CakePHPのHelperみたいなのがほしいんよ 別に適当に共通関数置き場を用意してそこに置けばいい
ファサードにしたいなら出来るけどわざわざ遅くなるような物にすることも無いしなぁ 8本むずすぎて全部読む気になれんわ
辞書代わりに必要なとこだけ読むか 青い本はまだバージョン5系なんだよね
買えないわ
これだけ普及してるのに本少な過ぎ 出しても買うやつ居ないし
マニュアルで十分なやつがほとんど Livewireちょっと使ってみたけど細かい所が完璧に動かないし、フォーラムで質問しても回答がない
まだちょっと早いか… >>32
次のバージョンでお蔵入りして欲しいわ
俺は絶対使わない livewire使うくらいならvueかreactそのまま使えば良くね？
なぜガラパゴスな作りにしてしまったんだ laravelの認証ってemailとpasswordが必須なのが面倒くさい Laravelのみではソーシャルログインとかできないの？ >>34
何も分かってないなお前。livewireはvueやreactを置き換えるものじゃないぞ。あくまでAPIを作らずに非同期通信をするためのライブラリ。
なぜ、livewireと連携可能なjsがalpinejsなの？て指摘なら理解できるんだけどね。 >>15
コレは煽りなのかな？
例えcakePHPはコントローラーの共通処理はコンポーネントクラスに書くし、railsやLaravelはconcernsディレクトリを設けてそこにtraitなりで共通処理を書くのが今どきの書き方。
このご時世に基底クラスに共通処理ぶち込むのは、不勉強なおっさんプログラマぐらいでしょ。 >>37
でもvendorフォルダの下のファイルって書き換えたらまずくないですか？ >>41
直接触ったりコミットしたりはまずあり得ないが、
composer.json使ってパッケージをオーバーライドすればそこそこ安全ではある 認証関連のレスがネタなのかガチなのか釣りなのか判別不可能 >>35
Auth::attempt()で認証したいものを渡せばいいだけでは？
別にemailやpasswordである必要は無い筈 >>48
そのメソッド、読めば分かると思うけどemailとpassword決め打ちですよ >>50
いやいや
うちのプロジェクトだとloginidとpasswordでやってるし >>51
ありえない
emailって名前のカラムなのに実態はメールアドレスではないとしたら誰もが混乱する
それならvendor以下を編集するよ
うちでは当たり前だし >>52
あなたのところの当たり前を常識だと思わないでください 認証で使う情報をどのように変更するかって議論は別に荒らしじゃないだろ 新入りか？同じ話題を自演で延々繰り返してる荒らしが住み着いてんだよこのスレ ネットに全ての情報があるのは良いけど、まとまった本が欲しい所。あの分厚いやつしかないのかね 認証周り変更するならfactory使うんじゃないの？
小手先でやろうとしたらemailとpasswordしか使えないみたいな結論になってもしゃーないけど >>55
その話はとっくに結論出てるし、vendorネタに持っていこうとするあたりループ君でしょ。 Laravel勉強してるんですが実際に使われてるwebシステムで参考にできるオープンソースあったら教えてほしいです 荒らしさんとかルーパー君が入れないレベルの話をすればいいんだよ！ >>61
それくらいググれよ
laravel example で検索したら色々出てきたわ >>60
こっちは初めてこのスレにきたんだからそういわれましても >>63
すいません検索ワードが分からないです。なんて検索したら良いですか？
>>64
ありがとうございます。
日本語のサイトは無いですか？ lockフォルダ以外で、どうやってatominするの？ jetstreamやらuiやらbreezeやらたくさんあるけどメンテナンス大変そう Jetstreamは結局クソという結論でいいのか？ 使った奴の感想もっと聞きたいんだが誰も使ってないから話にならないという >>75
使ってるぞ。特に文句無い。ローカライズがちょっと面倒なのと、マイグレーションファイルに使ってないカラムが入ってくるのはウザイけど。 >>76
最初使った時はスゲーって思ったからローカライズ用リポジトリ作ったりしたんだけど
ちゃんと使いこなせなかったみたいでだんだん使わなくなってリポジトリ更新止めちゃった 正直Jetstreamは使わないほうがいいと思う
そんなのよりもVue.jsとかで作ったほうがいいVue.jsのほうが技術文章なども多いし
もし外注に依頼するときも頼みやすいと思う Jetstream扱える外注少なそうだし >>78
あのー、jetstreamてinertia選んだ場合は、vueだと思うんだけど？分かってる？ >>82
いや単純にjetstreamて聞いてlivewire思い浮かべる程度の理解度なんだろうと思う。 あ、俺は>>73だけど俺がクソだと言いたかったのはLivewireだ、理解してたのに間違えてしまった
Jetstreamは使えば楽そうだから使いたいんだがLivewireではなくInertia使えばマシなのかな >>84
結局バックエンドとの連携を自前で作り込むかどうかだと思う。inertiaの役割ってのは、LaravelのAPIとaxiosが担ってた部分を肩代わりすることだし。 Laravelで最強のチュートリアルって何になるの？
以前このスレではこのサイトを進める人が多かったけど2021年現在はどのサイトになる？
https://www.hypertextcandy.com/vue-laravel-tutorial-introduction/ SPAでもないしMVVMでもない、普通にフォームをsubmitして確認ページへの遷移を挟んで送信する従来のMVCでも
jetstream使っていいんかな >>86
この手のチュートリアルやった初心者は
面接でlaravelとvue使った事ありますって言っていいのか？ >>86
使ってるモノが微妙にバージョン古くない？ >>86
検索に引っかからないようにSEO落としてやるよ >>94
逆SEOってこの間の法律改正で犯罪扱いになったんじゃないっけ？ >>94
よく堂々と逆SEOしますなんて発言できるな >>96
laravelとvueに関する知識は一切獲得できないけど、良質なチュートリアルってそういうもんなの？ Laravelのdotenvは環境切り替えに便利ではあるけど
dotenvがあるとconfig/app.phpの存在価値ってないよね
じゃあconfig/app.phpを削除したほうが良くないか？ 環境によって変わるものは.env
変わらないものはphpに書くんじゃないの？ また.envはコミットしないとかイキってるバカが湧いてきた .envに書くならデータベースの設定などはconfig/app.phpに入れる必要ないよね
.envに分離するべきだ >>106
confg/app.phpにデータベース設定書いてあるの？ 本番用の.envはコミットするけどテスト用とか開発用とかの.envはコミットしないよ >>109
.envって結構phpでは使われるから覚えていたほうがいいぞ APP_NAMEとか.envとapp.php両方に書いてあるからね
app.php編集したのにタイトル変わらねえとかあるある >>111
ちゃんとドキュメント読んでる？
そもそもdotenvとconfにあるファイルって用途が違うってわかってんのかね なんでLaravelはveuばっか使うんだよ
ReactにしないのはやっぱLaravelが初心者向けだから？ >>114
どう考えてもLaravelは上級者向けだよ
大手でもたくさん採用されてるし vueなんて日本でしか使われていないし主流はReact
まあLaravelも日本でしか使われていないが >>118
それお前の妄想だよね？なんかデータあんの？俺の認識だと日本はRailsが主流のガラパゴス。世界的にはLaravelのほうが主流。googleトレンドやjetbrain社の調査結果が根拠。 Railsの案件なんて実際相談も来たことねーわ
一部の意識高いうるさい奴らしか使ってない印象、開発もMacでするみたいな >>124
もちろんLaravelを使う人は「意識高い」よ
「意識高い系」じゃなくて「意識高い」だから気をつけてね >>125
言ってる意味がわからないです。ようするに意識高い系ってことですよね 意識高い系と意識高いの違いわからないの？
前者は口だけの痛い人って意味だぞ >>124
Laravelを使う人は意識高い系です >>127
じゃあLaravel使ってるだけの人は意識高い系で間違いではないだろ Laravel使う奴はむしろ意識低い奴だと思うが
流行ってるから使ってるとか、指定されたから使ってるような奴ばっかりだろ 保守のためにCakePHPを使うことはあるけど
新規プロジェクトではLaravel一択しか洗濯しないと思ってるよPHPでは >>131
いや流行ってるから使ってますって理由だけだったら意識高い系だろ 今だとLaravelしかない。
なんでこんな変なフレームワークしか選べない状況になってしまったのか…。 変だと思うならsymfony使えば良いだけでしょ。laravelをdisりながらそれ使うとか矛盾してるぞ。 Laravelはもう下火だしな
今はExpressのほうが圧倒的に使われている お、意識高い系がバカなこと言ってるな。nodejs使ってるとこなんてスタートアップでもプレイドぐらいしか知らんわ。せめてデータで示せよ。 実際Symfony6がリリースされたらLaravel駆逐されそう >>139
具体的に6は何が良くなってんの？symfonyてメジャーパージョンアップつっても劇的に何かが改善されるイメージ無いんだが？ >>140
このサイトのデータって外部から分かる範囲のデータのみで比較してないか？
当然nodejsのスコア高くなると思うんだけど >>142
外部からわからないものをどうやって調査しろと言うのか？ 少なくとも日本ではExpressがLaravelより使われてるという感じはぜんぜんないね
ノンブロッキングやシングルスレッドの挙動に癖がありすぎて
大きめのプロジェクトで使うには勇気がいる >>143
そういう性質のデータなのに>>137で
> Laravelはもう下火だしな
> 今はExpressのほうが圧倒的に使われている
って言い切ってるのがおかしいって言いたいんだけど >>145
それはどのフレームワークでも同じ話で、見えてる範囲と見えてない範囲でシェアが近いという前提なら、Expressが使われてると言っていいと思うよ。
逆に見えてない中にLaravelが異常に多いとでも言えるのかな？ >>146
expressはX-Powered-Byで識別できるケースもあるんで、他のフレームワークより検出しやすい >>145
データの正しい見方を勉強してからレスしなさい
お前だけレベルが低すぎてデータ見ても頓珍漢なこと言ってるぞ Reactのセットアップって1行でしょ？
たまたまvueがデフォルトになってるって理由で使わないけない理由は1ミリもないと思う >>140
それって技術スタックを推測するツールを使ったデータ？すでに指摘がある通りlaravelに関しては判定できないケースが結構あるよ。
俺が信頼しているjetbrain社のエンジニア向けの無作為抽出アンケートでは、普段使っているjsフレームワークは？という問に対して、expressと答えたのは2019、2020年が40%、43%だったのに対して、2021年は24%に落ち込んでる。
一方のlaravelは2019、2020年が50%だったのに対して、2021年は67%になってるね。
お前の主張と真逆の結果になってるよ。 他のフレームワークに寄生するLaravelが人気なんだもんな
仕方なく使ってるけど
ramenも軽量とはいいずらい >>150
jetbrain社っていうところで既にバイアスあり。 >>151
OSSのパッケージインストールしたことない人？大抵のライブラリは他のライブラリに依存していると思うんだけど？そういうのを寄生と表現するのは初めて聞いたわ。
それとramenてのも初めて聞くね？文脈からするとフレームワークかな？もしかしてlumenから派生したもの？ >>154
多分、開発者エコシステムの現状というアンケート結果を見てるのだろうけど、
·phpとjavascriptは分けて集計されてるから、67％という数字だけで単純比較できない
·フレームワーク使用の割合を足して100%超えるのはどういうことだろう？
·アンケート対象に偏りがある。重み係数が非公表。
もう少し情報処理能力を磨いたほうがいい、 まあ特定言語向けの製品作ってるところのアンケートは信用できないわな >>155
日本語ちゃんと理解できる？俺は前年度の同フレームマークの比較しかしてないんだが？勝手にexpessとlaravelを比較しているような印象操作はやめてくれるか？
あとアンケート対象に偏りがあるとする根拠は？ちゃんとメソドロジーのとこ確認した上で主張しているかい？それともお前の妄想に基づく主張？ >>156
あー、メソドロジーのとこ読んでないで妄想で批判してるだけってことだね。理解。 てか>>140は他のひとたちからも否定的な見解が出てるのに、>>140に固執する理由が謎だし、>>155のように重み係数の公開まで要求しているくせに、それよりはるかに透明性に欠けてそうな>>140を信頼している理屈がわからん。 >>157
このアンケート見て、expressが単純にシェアを急激に下げてると判断してるとすると、お前やばいぞ んなもんどっちでもいいだろw
ここはLaravelスレなんだからExpress推したいなら他のスレでやりなよ >>138がデータで示せって言ったからデータで示したんじゃないの？
で、実際にデータで示したら「そんなの知らねえよ他所でやれ」
つまり降参、論破完了ってことでいいのかな？ >>161
論破された途端今度は「スレ違いだから他でやれ」ですか・・・
電車とか好きそうですね（ ＾ω＾） >>161
Laravelerくんさぁ、他でやれって言う前に言うことあるよね？
お礼と謝罪も言えないのか？ >>162
いや俺、データ要求した奴とは別人だし
どっちにしろLaravelと関係ない話題なんだから他のスレでやれよ >>160
LaravelはPHPのフレームワークの中ではシェアを伸ばしているのに、下火っていうやつの主張に反論しているだけ。expessに関しても圧倒的と言う割には、jsの技術者の中では使ってる割合は減ってきてる。
しかも>>140のデータの信憑性には他からも指摘が入ってるのにスルーだし、>>155のような厳密性を求めてるくせに>>140は信じるということにも矛盾を感じるね。 >>163
>>164
俺はこの件に関しては今まで何も書き込んでねーよ
とにかくスレ違いだからよそでやれや >>162
勝手にターゲットを他の人間に移して論破論破てひろゆきかよwww >>167
Laravelのシェアについての話だから別にスレ違いではないと思うけど この過疎板でこれだけスレ進んでるからLaravelは日本でダントツだと思う expressとかnode.jsの専用スレって存在するの？ ※ ↑彼はLaravelerなのでスレタイ検索するという発想すらありません、暖かく見守りましょう ※ 検索したらexpressスレ簡単に見つかるけど、
3年以上書き込みなしだからねぇw 久々にきたらめちゃくちゃスレのPartが進んでいてびっくりした
Laravelで何かすごい機能とかがリリースされて盛り上がったのか？ >>184
技術に関することで論破されてLaravelerが発狂して荒らしたの間違いだろ？ >>183
荒らしたいループくんに見事に釣られまくったやつがいてスレ消費しただけ
どっちもまともにLaravel知らんから、過去スレ見る価値もない でlaravelとExpressはどっこいどっこい？ >>188
もう俺の負けでいいから他スレでその話題はやってくれ >>186
だからなんでわざわざ話題をループさせるんだよ お前ループ君か？ >>188
どう考えてもLaravelのほうが優秀 >>197
>>190もループ君だぞ。釣られんなよアホ。 ごめん、話ぶった切って悪いんだけど、俺、凄いことに気づいちゃった！
もしかしてLaravelって、複合プライマリキーをマトモに扱えない？ 古い書籍（5系）をブックオフで見つけたから買ったんだが、
バージョン指定せずにインストールしたら、
最初のweb.phpの設定で躓いてワロタｗ
5→8ってだいぶ違うんだな すみません。>>201です。ググってもわからないので教えて下さい。
cssやjsの場所が8ならresourcesにあるのですが、
ビューで{{asset('css/app.css')}}としても
publicの方を読み込みに行っています。
だからファイルがリンクできず、NotFoundになります。
これは単純にresourcesからpublicにコピペして使うのでしょうか？ 逆になぜわざわざ5の中古本買ったんだよ
そこが疑問なんだが バージョン指定して5.8をインストールしたら、
普通に/public/css/app.cssがあり、bootstrapのソースが書いてありました。
バージョン8にはないので、アップグレードの間に仕様が変わったということですね
>>205
8の本は4000円するので、さすがに何も知らない状態で買うのは辛いと思いまして >>204
assetじゃなくてpublic_path いやちがった
resourceの中にあるcssをコンパイルしてpublic_htmlの中に履けば使える
そこはドキュメントルートの外にあるファイルだから読み込めなくて当然
laravel mixで調べろ 時間の無駄になるし、とっとと8の本を買った方が言いよ 5でなんとかCRUDの基礎を学んだわ
あとはバリデーションとかテストをどうするかだが
そういうのは別の本で学ぶことにするよ >>211
正確悪ぅ！ これだからLaravelerはキモいんだよ！ Laravelで複合主キーを使う方法について教えてください
マイグレーションファイルで複合主キーのテーブルを作ることはできたのですが
モデルクラスのprimarykeysにどうやって複合主キーを指定すればいいのかがわからないです >>215
ループくんはいつになったら消えてくれますか？ 非公式のトレイトがどこかで紹介されていたけど
複合ユニークにして回避するほうが無難 blade書く時に、HTMLを直接書いてますか？
それともHTMLヘルパー的なものを使っていますか？ >>219
複合ユニークにしたほうが無難なんですねご回答いただきありがとうございます。 よく考えたらマイグレーションでは複合主キーサポートしているのにEloquentはサポートしていないっておかしいよな
なんでこんな中途半端な状態になっているんだろうか 郵便番号や駅データなどの大量レコードを用意したいとき、
マイグレーションでは無理ですよね？
SQLファイルからの一括インサートが無難な気がしてるのですが それが無難だと思いますよ
Laravelのマイグレーション自体に初期データ入れるとか機能ないし シーダーの話だと思うけど
基本は開発用として用意されてはいるから
本番のマスタなどの初期データはSQLかCSVなどのデータで投入するのが一般的ではあるかな
本番でシーダー使うと警告メッセージが出るから一発で動作はしないんだけどね >>224-225
シーダーの話です。
初期データはシーダーで用意するイメージが有りましたが、
SQLかCSVの方がいいんですね シーダーで大量のデータ入れるのって大変じゃない？
CSVか何かからシーダーファイル生成するツールとかあるの？（簡単に作れそうではあるが シーダーっても大した機能ないから、直接SQL叩くのとほぼ変わらんよ
本番環境で注意してくれるとか、そんなもんくらいじゃね？ ドキュメントではシーダーで出来るよって書いてあるけどね 別に本番でもシーダーで初期値設定することが悪い訳では無いとは思う
やるなら専用のクラスを作った方が良さそうだけどね Laravelのドキュメントにはシーダーは「テスト用」とはっきり書かれているが
本番で使ってはいけない理由も、使うべき理由も特にないように思う >>230
馬鹿発見
公式でもやめろって言われてるのにまだやってる馬鹿いるんだな シーダーはテストデータ詰めるときとかは色々使いようがあるが、
本番データ入れるのに使うメリットがほとんどないもん それな、使うべき理由がない
手間が減るわけでもないし >>232
でその理由は？
特に理由が無いのに何も考えずに辞めろってｗ
シーダーで登録して何か問題あるの？ｗ プログラム板にLaravel初心者のキチガイがいてたぶんこちらに来ると思うから相手よろしく どうせいつものアンチオートインクリメントおじさんだろ よくわからないんだけどシーダーで登録するとどういうデメリットがあるの？
公式ドキュメントもいまいちそこらへんが書いてないからどういう不都合があるのかを知りたい また前スレか前々スレの話題かよ。ループくん？
初期データをどのように投入するかは前回スレで話題になって数日後というタイミングで、Taylorが自分なりのやり方をTwitterで披露してたから、それを参考にしたらいいと思うぞ。 モデルのオブジェクトでAttribute と Original で値が違う場合がある？
しかもある1つのカラムのみAttributeが空文字になっているという謎の現象。 >>243
orginalはDBから取り出した直後の値。attributeは外部またはシステムによって書き換えられた値が入る。それだけの話だから謎でも何でもないと思うが。 なぁ、ファサードって、何なん？
静的アクセスしたいならstaticな実装すればいいだけやん？
なんでファサードなんか必要なん？
何のメリットがあるん？ 俺も気になってた
staticな実装で良くねって思ってる 単に簡潔に書けると言うくらいかと
そもそも、ファサードで最終的に呼ばれるメソッドはstaticじゃないけど テストする場合、テスト側からファサードに登録しているクラスをモッククラスに置き換えられるのは大きなメリットじゃね？
逆に言うとテストしないやつにとってファサードのメリットは、newしないでインスタンスのメソッドを利用できるから記述量がちょっと減ってラッキー！ぐらいの話かもしれない。
てか、比較するなら静的メソッドじゃなくてインスタンスメソッドだと思うんだが。単にコールするときのsyntaxが静的メソッドと同じってだけで静的メソッドとファサードを比較するのは乱暴かな。 >>249
別にその用途ならDIでやれるしなぁ
わざわざファサード使わなくても良くね？ >>250
依存が少ないならそれでも良いと思うぞ。コンストラクタインジェクションで長々とクラス列挙されたら嫌じゃん？ >>249
>テストする場合、テスト側からファサードに登録しているクラスをモッククラスに置き換えられるのは大きなメリットじゃね？
まぁ、その説明は確かに分らんでもないけど、そのくらいしか使いどころが無いのかい？ >>252
普段使いではそんぐらいでしょ。レアケースで良いなら、ファサードで呼び出してたサードパーティパッケージがイケてなくて、オーバーライドが必要な時に便利みたいな話はある(実際過去1度だけそういうケースがあった)。 Laravelはそろそろcreate-projectした段階でusersテーブルのマイグレーションやモデルが用意されているのを辞めてほしい そこまで用意して来るならジャンゴみたいに綺麗な管理画面作ったくれると良いんだが >>254
いらなきゃ消せばいいだけだし
普通はそのまま使うし認証部分は大きく変えたりしないし >>256
Novaがあるでしょ。まぁ有償だけども。 usersテーブルの認証機能を使わないなら何のためにLaravelを使うのか そこまで毛嫌いするもんでもない
使いたくなければ使わなければ良いだけ
Facade警察の人に感化されたの？ usersテーブル以外で認証させる方法を教えてください >>262
テストしない人間にとってはそうだろうね。どうせDIも似たような感覚でしょ？ >>264
laravelだとvendorフォルダのファイルを修正しないとできないから諦めろ え？それじゃ、usersテーブル以外は認証できないってこと？ >>267
だからvendorを修正すればできるって
日本語分からない？ >>267
vendorフォルダの下のファイルを編集すればusersテーブル以外でも認証することができる
ただしあまりお勧めはしないがな >>266-269
クソ雑魚ナメクジは人に教えるのやめてくれ。何がvendor配下だよ。そんなゴミみたいな方法を勧めるとかありえないぞ。 認証先のテーブルをusersから変えたい場合は、config/auth.phpのprovidersに認証に使いたいテーブル登録すれば良いだけ。 俺も>>271の認識だわ。>>268-269こいつ煽ってる割には知識が浅いな >>272
それな。日本語分からないの？て笑ってしまうわ。 >>271
config/auth.php直接編集はダメじゃないか？
config/auth_local.phpファイルを作ってそっちを編集したほうがいい 元あるファイルを修正するのではなくそれをオーバーライドした
XXX_local.phpを作るのはPHPのフレームワークでは常識のテクニックだろ・・・ >>277
煽るぐらい自信満々に回答したのに、バカにされたからって話を変な方に持ってくのはやめとけ。恥の上塗りだぞ。 サービスプロバイダでmergeConfigFromメソッドとか使ったことないんかね・・・
vendor内書き換えたいとか思わないくらい色々便利な機能あるのにもったいない Taylor Otwellはよく講演でvendor直下直接修正しているけどあれ何で何だろう
vendor直下なんて書き換えないというのがお約束というのはわかっているはずだが >>281
講演見たことないから正確にはわからんけど
俺の場合パッケージ開発の場合vendor以下を作業領域にするよ >>281
> あれ何で何だろう
Laravelが「変」だから、vendorを修正しないと対応出来ない。 >>285
自分の知識が浅いのをLaravelのせいにするなよwww どうしても触るにしてもcomposer.json使ってオーバーライドするくらいにした方がいい
直接触るのはさすがにない >>281
ざっと探したんだけどvendor修正してる動画ないなぁ
viewとか言語ファイルなんかをvendor:publishすると
resources/view/vendor/パッケージ名
以下に配置されるんだけど、それ修正してるとか？
きっと意味があってそうしてて普通に開発するよりもメリットがあるからそうしてるはずで
その恩恵を受けられないのは損だから動画とかあるならマジで教えてほしい
それで開発時間5%短縮できるならやらない理由ないし サービスプロバイダやクラスのオーバーライドを理解しているなら、日常的にvendor配下をいじる必要性なんてゼロだって分かりそうだけど。 >>289
そう、パッケージ開発以外でvendor以下を触るなんてありえないってのが俺の認識なんだけど
明らかに自分より能力の高い人物でlaravelの開発者がやってるなら
それなりの理由があってメリットがあるはずだから知りたいんだよね >>290
まぁ>>288の前半部の仮説が正しいのかなって思ってる。 確かにまじでvendorフォルダ直接修正しているね
しかも「composerのバージョン２を使っている方以外はマネしないでください」という意味不明な発言もしている
俺の認識だと別にcomposerのバージョンに関わらずvendorは修正しないのが原則だと思ったんだけど
composerのバージョン２だと何かメリットがあるのか？ 自分で作ったものなら意味も分かってる訳だし動作確認とかで修正するのもありなんじゃね？
ただ一般的にはいじらないだろうが >>295
何もそんな言い方しなくても・・・
公開されてる動画で確認したのかなと思ったのでそうであればURLが欲しいって意味だったんで
公開されてないデータであれば大丈夫です >>292
俺も294と同じくtaylorがvendorいじってるところを確認できる動画のurl知りたいわ。 url出せないなら、どのメディアやSNS見りゃ良いのか教えてくれると助かる。 >>298
別に俺は話の真偽を確かめたいから言ってるんじゃないのよ
Laravelをガチでやるって決めたから
知らない手法があるのが嫌なだけ、だからいつくらいの動画かだけでも教えて欲しい
「Taylor Otwellはよく講演でvendor直下直接修正している」って>>281で書かれてるから
v7以降の話だよね？
最後の手段は英検初段の実力をフルに使って本人に直接聞いてみるから
本当はlivewireのdiscordで怖い目にあったから英語で会話したくないけど >>301
草Taylorにdiscordでボコボコにされたのかよｗ 仕事でLaravel使ってる人って、公式サポート切れた後どうしてるの？ >>304
その分の費用請求するの？バージョンアップの間隔短いから納得しない気がするんだが いやうち自社サービスだから請求なんて概念無いけど
つかそんなの客との契約次第だろ
どんな契約してんだよ >>303
バージョンアップするだけ。内製だからな。外注の場合は金払ってバージョンアップするでしょ。他のFWはそうだったし。
あと、Laravelが殊更バージョンアップの周期短いのは事実だけど、サポート期間はそうではない。
LTSならバグフィックスは2年、セキュリティフィックスのサポート切れまで3年ある。これはPHPのサポート期間と同等。PHPは2年間のアクティブサポート、そこから1年間のセキュリティサポート。 バージョンアップって機能が追加される訳でもないから、費用かかるの嫌がるってのもわかる
フリーでやってた時本当に嫌だった 外注だと一度運用にのせたらFWバージョンアップなんて無理だわな
どうせそのうちリプレイスになるから放置ですよ FWに限らず、別の作り方するだけでリスクが高くなるからな
ポータルサイトなんかもずっと古い技術のサイト多いだろ FormRequestのattributesに
age => '年齢'みたいな感じでユーザにわかりやすい名称に変更可能だけど
多言語化するときってどうするんだ？age => __('age')みたいな感じにして
messages.phpでage => '年齢'って定義するのか？ >>311
FormRequestはコントローラの関数の引数にいるんですよね？
public function store(HogeHogeRequest $request)みたいな感じで
だとしたら多分できないと思われます。
うろ覚えですがHogeHogeRequestの処理が行われる時点ではまだmessages.phpは読み込まれていないので
HogeHogeRequestのattributesで__('age')が'age'として解釈されてしまい
画面上にそのままageとして表示されると思われます >>311
エラーメッセージのカラム名翻訳の話だよね？
いくつかやり方あったはず、検証してないから間違ってたら申し訳ないけど
1. validation.phpに
'attributes' => [
'short_comment' => 'ひとこと'
],
って指定する方法
Custom Validation Attributesってコメントに書いてあるはず
2. resources/lang/{locale}.jsonに
"attributes":{
"translation":"多言語化"
}
って指定する方法 >>311
すでに回答している内容と被るけども、langディレクトリ直下にja.jsonてファイル作って、"hoge":"ほげ"とか定義しておくと、__('hoge')てなってる箇所が、ほげ で出力される。
ただしこの方法は、view上の出力を置き換える場合に使うものであって、vallidationメッセージの多言語化はlang/jaの下のphpファイルで達成するのが望ましい。
ちなみに、jetstreamはちょっとだめなとこがあって、後者だと一部のバリデーションメッセージが英語のままになってしまい、ja.jsonで変換かけてあげないとダメだったりする。 >>314
何でlang直下の多言語化ファイルがphpじゃなくてjsonなんだろうって謎が解けたわ
今日もまた一つ賢くなってしまったありがとう いまいち本番環境へのデプロイがイメージわかないんだけど
node_modulesやvendorフォルダってそのまま本番環境にコピーしていいの？
それとも本番環境でnpmやcomposer等のinstallコマンドを実行しないとだめなの？ >>313
1のやり方だと多言語化できなくない？
それだと日本語オンリーになる >>317
どうしてそう思ったんだろう
resources/lang/en/validation.php
を変更してるって事なのかな
だとしたらenってディレクトリ名のenってどういう意味か考えたらすぐわかると思う
resources/lang/{locale}/validation.php
こう考えたら日本語オンリーにはならないよね >>316
環境によるから何とも言えないけど
基本的にvendorとかnode_module辺りはコピーしないでやってる 今までlaravelできますって言われてちゃんと使えてる人にあった事ないんだけど
みんな自己評価高すぎじゃない？ >>316
どういうデプロイの仕組みを使うにせよ、composer installやnpm run productionを実行してから本番と同期とるような処理を書いてる。 >>320
俺もその認識。たぶんconfig/app.phpのローカライズ用の設定変更などせずに開発してるんじゃね？ 別にvendorファイルをコピーしても害はない気がする vendor以下をコピーして受けられるメリットがあんまりないのよね
環境がWindowsかMacかLinuxで少しだけbinに入るファイルが違ってくるし 自分が居なくなっても別の人に保守してもらうことを考えたらWindowsは選択肢として有り composerやnpmは環境次第で高確率でトラブるから使わないようにしてる
レン鯖だとそもそも使えないしな WindowsとMac使わないって開発環境もLinuxって事なの？
そうでないならどこのvendorをコピーする想定なんだろうか 開発環境はWindows上のLinuxだろDockerか何かの
Windows用のVendorが必要になることなんてないが composerやnpm使ってデメリットになることはほとんどないな 【悲報】Laravel9でまたModelsディレクトリが消失してしまう モデルの置き場を強制されることを嫌う奴が開発陣にいるの？
決まっている方が使いやすいと思うし従来のでも結局Models作って
そこに置くからどっちでもいいんだけどｗ リポジトリには来てないけどな。情報源はどこだろう？公式のdiscordでもなさそうだし。 皆さんはlaravelを使っていると思いますが
この機能が欲しいとかここ直してほしいとかそういう要望って何かありますか？ Eloquentの100ループ問題を早く修正してほしい Eloquentって使ったことないなそういえば いつもクエリビルダ使ってるけど
Eloquentって何かメリットあるのかな >>336
bladeをWordPressみたいにWeb上で更新できるようにしたい
ローカルでいちいちエディタ使わないといけないのが面倒だ laravelはsymfonyと比べると使いづらい >>340
自分もあったら良いなと思ってたんですよね
自作するとしてエディタは何がいいと思いますか？ それならFTPなどの同期でも利用すればローカルのbladeファイルを保存したらアップロードされたりするしそれで良さそうな
まぁ本来ならgitで管理して最低でもサーバーでgit pullするとかだろうけど 使う場面が想定できんな
だったらWordPressでええやん、ってなる
bladeの処理をエディタの部分だけ切り離すのも大変そうだし
作るにしてもちょっと割に合わない 詳細な要件は不明だけど、今どきはgithubリポジトリでピリオド打鍵したらすぐwebエディタ起動するじゃん？それでbladeファイル編集して、保存時にgithubアクションでデプロイする仕組みにしとけば、希望は叶うんじゃないの？プレビューしたいとかなら、話は変わってくるかもだが。 >>345-347
やりたい事はかなりシンプルで
デザイナー？HTMLコーダー？の人から上がってきた
HTMLをbladeファイルにする作業から逃げたいってだけなんだよね
結構github何それ？って人とかいてそういう人にどうやって直接触ってもらおうか悩んでるのよね
ヘッドレスCMSとかも考えたんだけど不評でさ デザイナレベルならGitHubたたき込んだ方が早い
メインブランチには触らせないようにしとけばいいし
てか、Larabelで更新させたらbladeの履歴管理はどうなるん？ >>348
そういう奴はjigsaw使え。それ使って作らせたらbladeファイルで納品させられるぞ。
https://jigsaw.tighten.co >>349
直接触れるんだから更新履歴とか知った事か
そっちで管理してねって感じ
それが嫌ならgit覚えて下さいかな file_get_contentsでbladeの中身を取得して、それを書き換えるってことはできないの？ まあ、どうにせよ需要がニッチで開発する人はいなさそうだ WordPressに実装されてるって、素人にも編集させるためだろ？
なのにニッチ（需要が少ない）と決めつけて良いのか？ WordPressでできないからLaravelで一から作ろうとしてるんだろ そろそろLaravel始めてみようと思うんだがそれぞれ一言ずつください そんなに需要があると思ってるなら自分で作って公開すれば良いと思いますわ
みんな喜んで使ってくれたら嬉しいでしょ >>359
複合主キーはLaravel(Eloquent)では扱えない >>363
それならLaravelも十分使えると思うよ
昔は日本だとCakeばかりだったけど最近はLaravelばかりという気がするし PHPのできないHTMLコーダーにビュー作らせるためにbladeとかtwigみたいなテンプレートエンジンがあるんだろ？
それもできないからCMS作るって斬新だな 普通はwebデザイナーにHTMLを作って貰ってそれをプログラマが
bladeにするみたいな感じが普通じゃね？
そりゃデザイナがbladeまで作れたら楽だけどそんなところ少ないんじゃね デザイナーはモック作ってお前らがphpでマークアップするんだろ
何で他人にやらせてるんだよ
どうせ、cssをまともに作れなくてデザイナーが指定したとおりに作れないんだろうが 別会社が作ったHTMLを組み込む場合は自分でbladeにするけど、社内で全部作る場合はデザイナーがblade書くよ
ただし@なんちゃらの部分はこっちで付け加える、修正時はそこをいじらないようにしてもらう たとえばデザイナーに修正させるときはどうするんだよ？
いちいちプログラマがマークアップしなおすか？ いじるなって言ってもミスは防げないだろって意図か？
うちはコーダーにもGit使わせてるからバグってたらマージさせないだけだぞ プログラマーが作るhtmlとcssはマジでゴミクソだからな
生まれつき目ん玉腐ってるからデザインを再現できない
崩れるしバラバラ
色や線すら理解できない
普段どんな世界見てるんだろなこいつら 俺が書くHTMLのソースはきれいだと、よくデザイナーに褒められるぞ。
丁寧に書くよう心がければ、結果に現れるということ。 俺の周りはデザイナー作のマークアップのほうがひどいわ。セマンティック何それ？コンテンツモデル何それ？autoprefixer何それ？みたいなの多い。
おまけにタイトルや見出しにカーニングも入れないバーティカルリズムも考慮してくれない。illustratorやphotoshop使える=デザイナて感じだから、マークアップやらせるのがそもそも無理があるんやろなぁ。 Reactをいじっているところだけど、
こうなるともはや、デザイナのHTML,CSSをBladeにするのは誰か？みたいな話は論外になって
全部フロントエンジニアの仕事になるるるな。
デザイナにコンポーネントとか理解できるわけなくなくない？ >>381
自称フロントエンジニアはただのプロップスマン
デザイナーにステート管理とstyleComponentとjsxを任せるしかない >>382
理想はそうしたいけどそうなると今までのデザイナーの担当範囲を相当超えちゃうでしょ
もはやデザインができるプログラマーみたいにならない？ そもそもデザイナーがコーディングなんて担当しないだろ
デザイナーとフロントエンドエンジニアとバックエンドエンジニアはそれぞれ存在する Laravel6でAppServiceProviderのboot()に↓を記述してDBアクセスしてもログが出力されないんだけど原因思い当たるエスパーいますか。
\DB::listen(function ($query) {
\Log::debug('====================');
}); >>386
ちなみに何がログ出力されない原因だったんですか？ >>383
プログラマーができないんだから仕方ないじゃん
今まででまともにできるプログラマーを見たことがない
>>384
デザイナーはhtmlとcssができてプログラマーはできないからやらせるしかないよな
モックからマークアップに起こせるプログラマーもいないし >>387
クエリログを出力していない別のログファイルを見てました、、、 Laravelerって簡単なWEBページ作成すらできないのかよ・・・・ LaravelってCakePHPでいうテーマ機能って無いんだな ページ作成できるできないで言ったらできるぞ
作ったものが何故か不評なだけ、俺には見やすくて使いやすいんだけど Laravelの認証ってLaravelだけで完結してるの？
Firebaseとか使う必要ないのですか？ Firebase使わんとならんとかなら使いようがないだろうねw そもそもなんだけど、auth0とかFirebaseとかなんで外部の認証サービス使うんですか？
Laravelとかのフレームワーク＋DBで完結できないんですかね？ 釣りでしょどうせ。初学者がLaravelセットアップして最初にやることが認証パッゲージの導入でしょうに。 完結できるならそれでいいんですが、なぜLaravelでFirebaseなどの有料認証サービスを使う開発があるんですか？
外部の認証サービスを使うメリットってどんなものがありますか？ 簡単な話だよ。外部の認証サービス使えば、内部に認証情報を保存しないから、セキュリティ面での不安が少なくなる >>400
うーん、だけどFirebaseでIDトークンって厳密には漏洩リスクがあるから最大1時間で可能なら要件によってもっと短く設定しますよね
どっちもリスクあるから好きなように使えってこと？ 作り方次第では？
漏洩のリスクって何を想定してるのかによるが 認証って、どのレベルまでのを想定してはなしてんのよ？ Laravel用のSmartyってあるんだな。しかも8にも対応してる わざわざsmarty使う必要は無さそうだけどcakeからの移行なら使いやすいのかな？
変えるならtwigの方が好みだな Smartyは、EC-CUBEで嫌々ながら使っている
ワタシには、なにが便利なのかがさっぱりわからんあるよ >>403
メアドとパスワードの認証レベル
他にはGoogleとかのプロバイダ認証も使うかってこと？ なんでServiceProviderみたいなめんどくさい事してんだろ…。
なんでServiceContainerに登録しないと使えないとか考えちゃったんだろ…。
本当に何したいのかよくわからん実装だな。 Laravel作った人ってさ、静的クラス使ったら死ぬ病なのかな？ 必要もないのにインスタンスなんか作るから遅くなるんだよ…。 ああ…、もしかして、use書きたくないマンなのか…。 なんとなくServiceProviderの仕様、分かりました。
次はQueryBuilderでも見るか…。 DBファサードのget()結果は\stdClassのコレクション限定なん？
PDOなら任意のクラスにマッピングできるっしょ…。 …pluck()、また、どうしてそんな実装考えついちゃった？ってのが出てきた…。 …chunk()、は、分からないでもないけど、そんなのが必要なケース、出会った事無いなぁ…。
where句で抽出できるでしょ？ 普通。 うーん…、これ、外側のchunk()でのwrap実装、要るか？
DB::table('users')->where('active', false)
->chunkById(100, function ($users) {
foreach ($users as $user) {
DB::table('users')
->where('id', $user->id)
->update(['active' => true]);
}
});
https://readouble.com/laravel/8.x/ja/queries.html 「レコードの主キーに基づいて結果を自動的にページ分割します。」って、どういう意味よ？ あれ？ ちょっとまって？
１）->where('finalized', 1) が、WHERE finalized = 1 でしょ？
２）->where('status', '<>', 1) が、WHERE status <> 1 でしょ？
WHERE text = '<>' ってどうするの？
->where('text', '=', '<>') なの？ 破綻してない？ ```
DB::rawメソッドを使用する代わりに以降のメソッドを使用して、クエリのさまざまな部分に素のSQL式を挿入することもできます。素の式を使用するクエリでは、SQLインジェクションの脆弱性からの保護をLaravelは保証しないことに注意してください。
```
でーたー！ 何にも便利になっていないラッピング処理！！！ 土方が入ってくる現場ではQueryBuilderは採用できないな、これは。
何すっか分かんない奴いるから変な事出来ないようにフレームワークで規制してんのに。
DB::raw( でgrepっすか…。 ```
このメソッドは、２番目の引数にバインディングのオプションの配列を取ります。
```
ちょーっとまってー！ PDOは名前付き placeholder あるよねぇ！？
なんで ? 使ってその場で渡してんの！？ ```
->orderByRaw('updated_at - created_at DESC')
```
あ、ORDER BY update_at - created_at DESC なんて出来るんだ。知らなかった。勉強になった。
使う事無いけど。 あえて用意してる機能に文句ばっかり言ってるけどeloquent使わんの？ JSON型のサポートがあるのか…。使った事無いなぁ…。 >>427
Eloquerntはある程度知ってるから、今日の Learning からは除外。 whereNull／whereNotNull は、まぁ、分かるけど、
orWhereNull／orWhereNotNull は、無理筋じゃないかい？
やっぱり orWhere で失敗してる感は当たりだったな。メソッドが指数関数的に増えるんすよ、それやると。 うーーーーーーわーーーーーーｗｗｗ
whereDate / whereMonth / whereDay / whereYear / whereTime これに限った事じゃないんだけど、
複雑なSQLはORM使うより、プレースホルダ使ってSQL直で書いてbindした方があらゆる面で便利なんだよね。
DBファサードにしたって、サブクエリが１個入っただけでぐっちゃぐちゃになってんじゃん。
何のために抽象化してんのか訳わからなくなる実装は、見てるだけで痛いよねぇ…。
で、このDBファサード、プレースホルダ使った生SQLって渡せるのかな？
全然記述出てこないけど…。 ```
$users = DB::table('users')
->orderBy('name', 'desc')
->orderBy('email', 'asc')
->get();
```
こういうのもさ、
->orderBy(['name', 'desc'], ['email', 'asc'])
じゃないかなぁ？ 常識的に考えて。
出来るのかな？ 出来ないのかな? Laravelに、せめて2つか3つ、便利なところがあればまだ納得できるんだけど、
「みんな使ってる」以外に良いところが何もない…。
きつい…。 ```
latestおよびoldestメソッドを使用すると、結果を日付順に簡単に並べ替えできます。デフォルトでは、結果をテーブルのcreated_atカラムによって順序付けします。もしくは、並べ替えるカラム名を渡すこともできます。
```
うん、それは ORDER BY で指定すべき事だ。 ```
inRandomOrderメソッドを使用して、クエリ結果をランダムに並べ替えできます。たとえば、このメソッドを使用して、ランダムにユーザーをフェッチできます。
```
なに？ お前、遊んでんの？ ```
skipメソッドとtakeメソッドを使用して、クエリから返される結果の数を制限したり、クエリ内の特定の数の結果をスキップしたりできます。
```
こっちはまだ分かるんだよ。戦略的だから。だが inRandomOrder 、おめーはダメだ！ ```
insertOrIgnoreメソッドは、データベースにレコードを挿入するときに重複レコードエラーを無視します。
```
いや、分かるよ？ 気持ちは分かるよ？
でもさ、それ、DBが一回エラー吐いてるの見てからLaravelが無視してるだけっしょ？
ってことはさ、prepareを有効活用してないって事じゃん。
だって、prepareって、実行クエリを準備してるから、あとはbindする値を変えてループで回せば速いっしょ？っていう仕組みじゃん？
それを、同じ値があっても無視して実行したいってそれ、
１レコード毎にINSERT処理してエラー出たらLaravel側で握りつぶしてるだけっしょ？
prepareする意味、半減っしょ？
そもそも、重複があったらなんか設計ミスかもしんないから、とりあえずご報告しなきゃダメっしょ？PMに「こんなんでましたけど！」ってお伺い立てなきゃダメっしょ？
何勝手に「おっけー！」って事にしてんすか？
ダメっすよ、事故っすよ、事故報告書書くことになるっすよ、
ほんと、何やってんすかLaravel先輩、だからいつまで経ってもPL補佐なんすよ。 ふぅ、とりあえずQueryBuilderのドキュメント一通り見たけど、
後半、読むべきところねぇなぁ…。
EloquerntもDBファサードもどっちも中途半端で使い物にならんわ。
でも、実際には世の中の大半のWEBアプリはこれでも十分足りるんだよな。
分かるけど、分からんわ、人間って。 >>439
いやそうではない
例えばMYSQLに対して発行する場合はinsert ignoreというSQLで発行を行っている
エラーをlaravel側でチェックしているわけではない >>441
PostgreSQLの場合は通常のSQLにon conflict do nothingというSQLを付与してやっている
sqlserverの場合は確か無視するSQLがないのでinsertOrIgnoreを使うとRuntimeExceptionが発生して怒られる Laravelの良い所は何でも出来て実用的ってことかな
ライブラリも多いし。
サービス関係は何だかスッキリしないけど。 >>444
これのDB名+Grammar.phpが実態ですね。
それぞれのファイルでスーパークラスであるGrammar.phpのcompileInsertOrIgnoreを
オーバーライドしそれぞれのDBがサポートしている形で重複無視SQLを組み立てているよ。
SQLServerはそもそも重複無視SQLなんてないのでSqlServerGrammar.phpではオーバーライドをしていないため
SQLServerで実行するとスーパークラスのGrammar.phpのcompileInsertOrIgnoreが呼ばれるが
Grammar.phpでの実装は「お前重複無視サポートしてねーぞ」という例外をスローする実装になっているのでSQLServerで使うと怒られるようになっている
https://github.com/laravel/framework/tree/8.x/src/Illuminate/Database/Query/Grammars スレ伸びてると思ったら、また変なのが湧いてるのか。主観でLaravelくさして何度も投稿するのは、アンチオートインクリメントおじさんに通じるものがあるが、本人？ >>445
なんでもできてというわりには、質問しても答えられないことが多いんだが
少し上で議論されたbladeのWeb編集なんてまさにそれだろ >>449
必要か不必要が議論の焦点で
できるかできないかは議論してないと思うよ 何でもできるへの反証が「web上でblade編集できないこと」って、それさすがに釣り針デカすぎでしょうよ。 もうちょっとシンプルなやつないのかね
Expressみたいな laravelもそろそろバッチ処理関連の機能追加とかないかな
javaやってるとspring batchが便利すぎてこういうのlaravelでも欲しいなって思ってしまう わからんけどイベントとジョブで似たようなもの作れるんじゃない？ Laravel最近ぱっとしねえな
Cakeに戻ろうかな Laravel6だけど、HogeControllerをGETで呼んだ時にそんなルーティングないよってエラーになると思ったんだけどwen.phpのルーティング使われてフロントのHTMLが返却される。
これはlaravelの仕様？
RouteServiceProvider.phpはコントローラーのnamespace以外はデフォルトのままっす
rountes/api.php
-----
Route::post('hoge', 'HogeController');
rountes/web.php（フロントはSPA）
-----
Route::get('/{any}', function () {
return view('app');
})->where('any', '.*'); route:list見ればわかるけどapi.phpのはパスの頭に「api/」要るよ api呼ぶときのURLは↓で呼んでる。なのにweb.phpのルーティングが呼ばれちゃうんです。
http://localhost/api/hoge だいたいのFWがそうなるんじゃない？
any以外に合致するパターン定義してないなら
resource(CRUD)に変えれば除外したメソッドはエラーになるとは思う シンフォニーが使いやすければシンフォニーで良いじゃんって思うけど、なんかLaravelじゃないといけない理由があるのかな。
ライブラリは確かに多いな laravel-uiで認証機能付きのサイトを簡単に作れる所とか 簡単に作れすぎてセキュリティがおざなりにならないか不安 新規のサイト作るときは、ActiveRecord使えるのはやっぱ良いと思うよ。ケースバイケースてことを理解しない一部が的外れな批判をするけれど。
またドキュメントも充実している上にTIPSも多く公開されているのもLaravelの良い点だと思う。
あと細かい話だと、テスト書きやすい、ヘルパ便利、一瞬で開発環境作れる、有能ライブラリ多い、AWSなどさまざまな外部サービスとの連携が簡単。
8以降に限れば、簡単な非同期処理をLivewireでサクッと作れるなんてのも魅力だね。
大前提として英語圏の情報も積極的に集めれる奴じゃないと、あまり恩恵を感じられないかもね。 >>473
cakeなんかはクソ雑魚が実装したらセキュリティホールだらけになるじゃん？Laravelは雑魚が作っても問題が起きにくいから大丈夫じゃね？
POSTのときはCSRF強制されるし、eloquent使えばSQLiも起きにくい。bladeを普通に使ってりゃXSSも防げる。ハッシュ化もHASHファサード使えば、ソルトとストレッチングもお任せだしな。
認証も標準の使ってりゃ、セッション固定の問題も起こさないだろうし。
cookie周りのデフォルト値が若干緩い気もするが、まぁ無知なやつでもある程度のセキュリティは確保できてるでしょ。 8使ってる方はわかってると思いますが
今のバージョンではもうuiは使いませんよ
使うことはできますけど >>468
使えています。
>>469
>>470
そうなんですね。
階層変えて試してみます。
ありがとうございました。 Laravelは学習コスト低いのがいいやね
オレンジ色のサイトも1日あれば読める
PHP自体のを除けば罠も少ない しかし、Laravelはフォルダ・ファイル構成がぐっちゃぐちゃだな…。 Bladeは、ちょっとした物をつくるには手軽で便利かな。
templateの中で直接PHPのクラスを扱えるのは便利。
機能性ではやはりTwigFunctionやTwigFilterのあるTwigが何でも出来てパワフル。 テストはダメかな。
use書き忘れてClass Not Foundしてるはずなのにメッセージが握りつぶされて原因が分かりずらい。 Migrationは全然ダメだな。
foreign key制約とかでQueryException発生するとどうにも身動き取れなくなる。
rollbackもできない。down()だけ実行できないのかえ？
結果、手動で追加したカラム削除しかなさそう…。つらみ。 うーん、AuthがControllerで提供されてるのか。
それこそServiceで提供すべき機能じゃないのかなぁ…？ うーん、入力値のバリデーション時に一緒に既存ユーザのメールアドレスのuniqueチェックまで一緒に行うのか…。
「便利でっしゃろ？」ってつもりだろうけど、それは一緒の概念じゃ無いぞ…。
バリデーションって不正な入力値を弾く為の物であって、登録済みのmailaddressは別に不正な入力値じゃないぞ…。 というか、リクエストのバリデーション中にDBにアクセスするの、キモい。 >>486
バリデーションはこう実装すべきだという仕様を決めようとしている国際標準策定委員会だと
ユニークチェックもバリデーションの一種として含まれているぞ
といっても2015年ぐらいまではこの委員会もユニークチェックはバリデーションでやるべきではないって意見だったけどね >>483
まじで？俺の開発環境だとテスト時のClass Not Foundも出力されるぞ？
といっても自分のバージョンはlaravel6での話だからlaravel8だとでないのかな？ >>484
djangoも確か結局全部消して作り直すのが早いって結論になってしまった気がするし、Laravelに限った話でもないような？
そもそもそんなエッジケースを挙げて、migration全然ダメて結論導き出せるのある意味凄いな。 なんとなく気づいた。
Cakeはarray地獄だったけど、Laravelはcallable地獄なんだ。 こんにちはっす。今日も予定開いちゃったのでLaravelいじってます。
>>488
それ、どうなんだろう？ あんまり賛同できねっす。
>>489
こっちも6.20.34なんだけど、ダメなんすよ。
Requestクラス継承したバリデーション用のクラスをuseしてなかったんすけど、
✘ Status should be within defined numbers
┐
├ Session is missing expected key [errors].
├ Failed asserting that false is true.
だそうっす。しばらく悩んだっすよ。
>>490
いやいやいやいや、だって、既にあるMigrationファイルのdrop()メソッドだけ実行させてもらえればそれでいいじゃないっすか。
あと、そのためにDBのトランザクションがあるんだからExceptionでrollbackじゃないっすか。
おかしいっす。絶対におかしいっす。 新フレームワーク作れないのは勿論のこと課題解決パッチを作ることすらできない人 ほー、middlewareって何なのかようやっと分かったけど、名前悪いよなぁ…。 基本的にLaravelは色々なところで命名下手くそなんだよなぁ…。 うーん、完全にRails臭がしてきた。敷かれたレールに沿ってみんな同じコードを書こう！というスローガンが聞こえる。 Mailのbodyについて、view内のファイルを使うのは無理筋じゃないかい？
絶対ちがうって。 にゃーるほど。まぁ、Auth周りはRailとしては不完全だなぁ。
だからバージョン上がるたびに新しい認証機構が実装され続けてるのか。 >>497
なに言ってるかイミフだが、無理筋でもなんでもない Eloquentを一切使用しなくなったけどバリバリ使ってる人のほうが多いの？
複雑なリレーションもモデルで行ってるの？ >>492
javaのフレームワークでも全部消して作りなおせって結論ですね >>486
今世に出ている大多数のフレームワークはバリデーションでユニークチェックすることになってるな
javaのsprng frameworkについてはバリデーションじゃなくて自分でユニークチェック実装しろって方針だけど Laravelのソースを読み込んでみましたが結構酷い作りですね・・ 例えばどこ？
酷いっていってもオープンソースだからissueで指摘されて直すもんだよね？ このフレームワーク、完全にcakeの劣化じゃん・・・ アンチオートインクリメントおじさん、Laravelくさすのが目的になってるから、だいたい針小棒大な欠点の指摘ばっかりになるし、他のフレームワークでもそうなっているってオチなんだよな。 >>491
地獄っていうほどの実装にはまずならないと思うけど、実コード見たいね。書いてるやつのスキルの問題な気がする。 気に入らないなら使わなきゃいいのに
文句言うためだけにソース見るとか気持ち悪い奴だ >>498
まるで完全なauthとやらを知ってるかのような言い方だな。具体的にどういう仕様なら完全なの？ たとえCakeの劣化であっても、
Cakeより普及してるんだからLaravelを使うしかないと思うの Laravel使ってるとド素人認定されてバカにされる
Rails使ってると時代遅れと言われる
Django使ってると一目おかれfastAPIだと先進的と思われる
expressだとプロだと思われる わけわからん。
railsはちょっと古臭いとは思うが…
何でDjangoだと一目置かれるん？
どんなフレームでも極めれば一目置かれると思うが わりと>>520の意見って業界のスタンダードな意見じゃないか？ 使うものでプロだとかそうじゃないとか一括りにするやつが一番の素人だと思う その場合の道具とはエデイタなどのツールのことでしょ。建築の世界で言うと、フレームワークは、工法や造りに該当する。
作ることの本質は変わらないのだから、どのフレームワークを使っても、標準的なエンジニアよりも高い品質でものを作れるのが本当のプロフェッショナルというものだろう。
あと、運用フェーズでのチームの拡大や自分が誰かに引き継いで別のプロジェクトに移ることまで考えるなら、利用者の多いフレームワークを選ぶ方が合理的だよ。 Laravelはフレームワーク界のWordPressだからなあ Laravelでwordpress実装してくれたら面白いのにね WordPress
→ プラグイン多数
→ データベースゴミ
→ セキュリティガバガバ
→ 初心者向け
Laravelと同じだった >>530
君みたいなプロフェッショナルは何を使ってるの？ 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でアクセスログ解析なんかは古典だけど
今でもアリなのでは無いかと >>634
かなり昔fluentd,GigQuery,Grafanaって構成でやってみたことあったんだけど
その時の感想っていうか反応が
・完全にオーバースペック
・小回りが利かない
・ランニング思った以上にかかる
・費用対効果悪い
って散々な目に合ったトラウマがあって恐怖心しかないｗ
完全に自分の実力過大評価してたなーって今は思う
結局ランニングいくらなの？って質問に答えられるなら
あの頃の俺のリベンジをしたい気もする
どの程度で運用可能なのかね、実際 Apacheでaccess_logに吐くだけだわ
もちろんそれでいいとは思っていない アクセスログってユーザーのアクセスログならGoogleアナリティクスだけど、バックエンド側のログのほうがほしいの？ DB使うならテーブルをログ取得用と集計用にわけないと、すぐ肥大化するよ GAは使いこなせる人間がいないのと
タグマネ入ってるから無料超えちゃう
故に提案したら面倒みる事になるのが嫌かな
しかも俺が作った訳じゃないって理由で単価が安い
その割に俺の学習コストかかる
まあ人生最後にリベンジしたいって気持ちはでかい
あ、この話ってあくまで空想上の話だからね
相談された時に何か美味しいご飯が食べられそう
って匂いがからとかじゃないんだかんねっ >>641
いや今時Apacheなんて誰も使わないだろ Apacheって3割ぐらいしか使われていないってシェアが発表されてた気がする Apacheの新規導入はもはや少数派だと思うけど
更新しながら使い続けてるApacheに乗せるのは普通にある Apacheでダメな理由も特にないからな
シェア3割と言ってもnginxも3割で後はその他って感じらしい laravel動かすのにnginxはapacheの代わりにならないだろ apacheの上位互換のサーバがあるなら使ってるかもしれないけど
現状はapache+nginxのリバースプロキシ よくわからないんだけどapache単独で使うのとapache+nginx使うのとでは
どういうメリットがあるの？ laravel6だけど環境回り何も変えていないのにcomposer install や update するとエラーが出るようになった。
最初はPHPの目盛り足りないって怒られたからおかしいなって思って、
memory_limitいろいろ変えて試してたんだけど解決せず、
最終的にmemory_limit=-1にして実行したら、↓のエラーが発生
Killed artisan package:discover --ansi
Script @php artisan package:discover --ansi handling the post-autoload-dump event returned with error code 137
昨日まではエラー出なかったのに今日急にエラーが発生するようなた。
解決方法わからず、、、同じ現象の人いませんか、、、
★PHP
root@app:/app# php -v
PHP 8.0.7 (cli) (built: Jun 28 2021 20:47:22) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.7, Copyright (c) Zend Technologies
★composer
root@app:/app# composer --version
Composer version 2.0.14 2021-05-21 17:03:37 >>647
Laravel+nginxで何が困るの？ twitter検索したら昨日くらいから似た症状の書き込みありますね、、、
composerの問題っぽい？ >>650
composerのバージョン上げたとか
プロジェクトごとコピーとか移動した？ だからcomposer嫌いなんだよ
もう何でもかんでもcomposerで入れるようになってるからcomposerが動かなくなったら詰むのに割とよく動かなくなって詰む composerで詰むとかそんなんたびたび起きるか？
なんか変なことしてるんでしょ >>653
composerのバージョンは上げていません。
バージョンを2.1.8に上げてinstallやupdateしても解決しませんでした。
ちなみに、laravel6の最新プロジェクトを新たにcreate-projectしてcomposer updateしたらエラーなく正常にvendorが作られました。
元のプロジェクトのcomposer.jsonと違いがあるのか確認中です。 >>654
それが嫌なら高性能なパッケージ管理システム作りなさいな
無能な俺たちは便利なツールを無料で使わせてもらってるって事を忘れちゃいけない
知識不足を棚に上げて作ってくれた方々に対してのリスペクトが無さすぎるよ >>658
まてまて、「環境回り」の中にcomposerでインストールされるであろうパッケージ群も含まれてるって認識なんだけど・・・
discoverしちゃダメなパッケージdiscoverしてるんじゃないの？
.envファイル無しで >>660
.envファイルがあるのは確認しました。
installやupdateが正常に行えてたときのソースバージョンから、
エラーが発生したときのソースバージョンまでのコミットを1つづ確認したところ、
あるコミットが含まれるバージョンでcomposer installやupdateでエラーが発生することが確認できました。
修正内容のどこが影響してたのかはこれから確認になりますが、
アプリの動作はエラーもなく正常だったのでまさかcomposerに影響してるとは思いませんでした。
原因はcomposerのバージョンではなくく初歩的なミスのようです、、、すみませんでした、、、 >>661
パッケージディスカバリーなんてゴリゴリ影響ある部分だよ
人間の側が間違いを起こさなけりゃ機械も決して悪さはしねえもんだ。 >>662
ありがとうごじあます。勉強になりました。 >>659
>無能な俺たちは
多分、毎回それ言ってるのお前だと思うけど、
お前が無能であるから使っている事と俺を一緒にするな。 >>664
無能だなんだって始めて書いたんだけど・・・
そうだね、ごめんね一緒にして悪かったね
俺は自分の事を有能だなんて思った事なんて一度も無いからおそらく無能なんだろうね
だけど今までcomposerが動く要件を満たしているのであれば、動かなくて詰んだ事なんてないよ
「詰む方が有能なんだもん！」って言いたいのかな？
君は表面さらっただけの湯葉みたいな知識しかない割に自己評価高く見積もりすぎだと思うので気をつけようね composer程度も扱えないやつはまじでPHPいじらないでほしい >>667
Issueが182も溜まってるからいくつかクローズしてこいよ Ver2に移行した際に軽い不具合はあったが、それくらいだな
これを使わないなら自力でパッケージ管理してるの？
それは確かにすごい能力だと思うし、自分には真似できない composerでどうのこうの言ってるような奴は
npmなどのjsのパッケージ管理ツールとか異次元なのではw お前らえらそーに言うけどアホ面してcomposer updateとかコマンド打ってるだけだろ？
それがいくらぐぐっても解決しない謎のエラー吐いたら直せるスキルあんのか？
誰かが作ったもの使ってるだけでたまたまうまく動いてるだけのバカが偉そうにすんな無能 どうせメモリ足りないよエラーとか依存性のエラーとかだろ
どうにでも対応できるだろw >>672
bugだけでも36残ってるからどうにでも対応して直してこいよ >>674
Issueが182も溜まってるって言ってんじゃん
バカなの？読めないの？
読めたらコメントしてこいよ >>672
て思うやん？メモリ増やしても解決しねーんだわこれが
さてお前ならどうする？ >>675
愚直なのはいい事だと思うけど
目的地までの道は1本だけじゃないのよ
いつも使ってる道が工事中なら別ルート使うでしょ？
その別ルートをどれだけ知ってるかが経験や知識なのね
もう一度いうけど君は圧倒的にそれが足りないよ
多分まだ若いんだから先人達が書いた素晴らしいコードを何万行も読み込んで勉強しよう
呼吸する様にgithubのコードを読もう
そうすれば数年後には今の俺なんか目じゃないくらいのエンジニアになってるはずだから composer使えないくんが発狂してissueの話を出してきて気持ち悪い つーてもcomposerのソース読んだ奴なんてこの中におらんだろ
普通にマニュアル通り動かしてるだけだろ？それでたまたまエラーに遭遇した経験のない奴が上から目線になっていて笑う >>679
そうだねマニュアルで事足りるからコードを読んだことはないかな
それはプロジェクトに参加してる方々が色々考えて設計が行われたり
充実したマニュアルがある結果なんだよ
なのにそんな人たちの苦労も無視して何のリスペクトも無しに君は
> だからcomposer嫌いなんだよ
> もう何でもかんでもcomposerで入れるようになってるからcomposerが動かなくなったら詰むのに割とよく動かなくなって詰む
こう言ったんだよ、これってとても酷いことだと思わない？
そんな人にどうして対等に会話したいって思えるんだろう
もうこの件に関しては書き込まないから君の勝ちでいいよ
最後に君の言うたまたまがどの程度の事を言っているのかわからないけど
俺は少なくとも3桁回数はインストールしてるしライブラリ作って公開したりしてる
だけどインストールできない時に原因があるのは必ず自分側で
composer側の不具合だったことなんて無い
ここまで言ってわからないのであれば
この職業向いてないと思うから別の職業を模索した方が君の為になる
決断は早い方が選択肢増えるから一度考えてみてね >>680
どう考えもcomposerの不具合だろ issuesにあがってるし composerのバグのせいなのに会社や顧客は修正を待ってくれない
待ってくれないどころかcomposerの存在なんか知らない
すべてアプリ開発者のせい issueがーー！言ってるやつは具体的にどのissueがやばいの？
いくつあるとかそんなんはあまり意味ない composer使えないくんの問題をエスパーするとlararelのバージョンは上げずに他のものだけバージョン上げようとしてるとかだろ多分 就職活動のバグのせいなのに親や兄弟は就職を待ってくれない
待ってくれないどころか就職活動の存在なんか知らない
すべて俺のせい >>684
issueってのは、要望もあるけど大抵は利用者から見て謎エラーなわけ
別にどれがやばいって話じゃなくて「そもそも謎のエラーwなんて無いしw 」って言うなら全部解消して還元してやれってのが、OSS利用者ってもんでしょ issueガーて言ってる人居るけど、あれらは根本的にソフトウェア側の不具合と認定されたものでもない。特に長い間残ってるやつてのは大抵他の人間では再現不可能なもの。
だからissueをピックアップして解決してみろとかいう反論はお粗末すぎると思う。 >>689
bugタグ付いてるのがあるだろ
お前はホントバカだなぁ >>680
わかったcomposerの開発者や提供者には敬意を払うよ
でも人が作ったものに完璧なものなんてないし不具合に悩まされたのも確か
特にバージョン1の頃は完成度低かったと思う、2に移行する時も問題起きた
【エンジニア用語解説】
「完全に理解した」
製品を利用をするためのチュートリアルを完了できたという意味。
「なにもわからない」
製品が本質的に抱える問題に直面するほど熟知が進んだという意味。
「チョットデキル」
同じ製品を自分でも１から作れるという意味。または開発者本人。
俺はなにもわからない人だが、完全に理解したレベルの人がここには多そう >>690
誰がbugタグの話しているんだ？俺はissueの話をしてるんだが？issue = bugではないってことを言ってるのだけど、お前は理解できないんだな。バカはどっちだよ？ >>692
issueの中にbugとしてソフトウェア側の不具合と認定されたものが少なからずあるってことだろ
ごちゃごちゃ言ってないで解消してこいよアホ
反論がおそまつすぎるわ 嫌なら使うなw
それで終わる話
使いたい奴だけ使え PHPエンジニアやっててcomposer使わないって無理じゃないの >>695
嫌ならプルリク出せ
がまともなエンジニアの発想 >>696
遊びじゃないんだからそんな悠長な事を言ってられない
やはり自社フレームワーク回帰しそうな流れだな
WEB系は開発環境を特定のバージョンで構築できない
一度選んだらその開発環境の最新（もしくはサポート内の）バージョンを追い続けるしかない
セキュリティはともかく開発環境すら再現できないのがWEB系の弱点
VB6なんていまだに開発できるのに・・・ >>967
開発環境ってOSの事？ライブラリとかの事？php の事？
いずれにせよ全部固定バージョンで開発可能なんだけど、そういう事がいいたい訳じゃないのか？ おい>>967聞いてるか？壮大な前フリが投下されたぞ 安価も付けられない奴って普段から手動でやらなくていいこと手動でやってミスばかりしてそう 一体何なの？昨日からの流れは
もしかしてこのネタでR-1出ようとしてんのか？
一回戦落ちになるからやめた方がいいぞ composerのおかげで楽になったよ
ほんとありがたいわ symfonyは脱composerを目指しているみたいだけど
symfonyベースのフレームワークであるlaravelもそのうち脱composerしちゃうのかな $curl- コマンドだけでインストールできると思ってたら
それに加えて「composer install」が必要ってことを知り悩みが解決した俺が通りますよ >>709
複数のlaravel動かしたい場合どうやってインストールするつもりだよw composer自体はaptでもインストールできるよ
composerで管理できるパッケージはaptからはインストールできないよ
なぜならaptが使えるプラットフォームは限定されているから composerの役割を分かってないやつが居るようなw symfonyはそういえばaptでインストールできたな VagrantとDockerだとどっち使う事が多い？
俺は100%VagrantでDockerは使ってない Windowsで直環境 AWSのt2.medium Docker良いね。逆にvagrantのメリットは？ Dockerはかなり前にWindowsに入れようとしてうまくいかなくて
それ以来積極的に追ってないのが現状なので
OS含めたほぼ同じ環境構築ができる
どのPCだとしても同一性が担保されてる
複数台立ち上げてローカルPC内でサーバー間の通信テストができる
この辺が可能なら乗り換えたいかなーと
Vagrantはとにかく重いのよ
特に案件毎にbox作ってるから容量も食うし >>716
面倒くさいからwindowsならvagrantの方が楽
homesteadあるし MacだがVagrant+Paralles+CentOS7がお気に入り
Dockerでも良いんだけれど、Macだとボリュームマウンとすると
パフォーマンスが出にくくて使いにくいし、
本番環境でまだDocker導入できてないのもあるし
Dockerの手軽さも魅力的だけどね WinでDocker Desktopてやつ使ったけど、重くて不安定でイマイチ ただ一つだけ、シンボリックリンク張れないのだけなんとかならないすかね あれ？Vagrantって言ってる人はhomestead？ >>723
Windows環境で/vagrant以下でシンボリックリンク張ろうとするとコケるのよ コンポーサークソダーコンポーサークソダーコンポーサークソダー windowsにvirtualbox+vagrantで作った仮想環境にDocker入れてLaravel動かしてる >>727
特にない
Dockerの勉強したかっただけ dockerの仕組みがいまいちわからないんだけど
その時使ってるコンテナにredisが足りないってなったらコンソールで入れて
エクスポートみたいな事する感じなの？ 開発環境作るだけなのに面倒くさいよな
その点xamppはよかった
なんでこんなにやること増えたんだろう vagrantならboxエクスポートするか
provisionの時スクリプトで入れたりする
>>730
構築にかかるコストを最初に払うかデプロイ時に払うかの違いかなーって思ってる
デプロイ時にミスった時の方が圧倒的にコスト上がるから俺としては助かってる homesteadなら最初はboxのダウンロードなどに時間がかかるけど
XAMPPとかでLaravel動かすよりは遥かに楽かと
これで環境作れないようなら厳しい
xdebugの設定はまた別にいるけど DockerでOSごとイメージをAWSにデプロイするのがいいのか
LaravelとかのソースだけAWSのAmazonLinux2もしくはubuntuにデプロイするのがいいのか
決めどころがわからんのだけどみんなどうしてるんですか？ スクリプト言語なんだからgit pullだけで良いじゃない >>733
試してないんだけどvagrantの機能で手元にあるboxをEC2にprovisionできるぽいのよね
けど最近はlaravel forge使ってるけど
圧倒的に管理が楽になった
>>734
エクステンションとか、付随するサービス(supervisorとか)の設定とかその辺りは自動でやりたい >>733
そもそもサーバーレスにするかしないかみたいな話だから、Laravelとは別問題かと。個人的にはEC2に慣れてしまってるせいでそっち使ってるけど、次のプロジェクトはサーバーレスにしよっかて思ってる。 >>735
そういえばforgeあったね
料金高いけど
>>736
サーバーレスってLambdaだとデフォルトではphp対応してない
どのへんをサーバーレスって言ってる？
サーバーレスは曖昧な言葉だから >>737
俺もphpってLambdaで使えなかった気がしてちょっとググったら
サーバーレスLAMPスタックってアプローチ方法でLaravel動かせるって初めて知った
けどコスト考えたら怖くて使えないかなぁ
Lumenにして超軽量仕様にしてから検討のテーブルに乗せるレベル >>738
サーバーレスはそもそもLaravelとかには向いていない
Laravelから切り出した軽量なファンクションで処理順を担保しないものをLambdaにすべきでサーバーレスの仕様に合わせた設計が必要 >>739
ああ、そういう意味でいうと今作ってるやつが
フロントでリクエスト受けてSQSにキュー入れるだけのマイクロサービス仕様だから
考えてたイメージで認識は合ってるはずよ >>737
ECSのことだよ。dockerの話してたでしょ？ >>738
lambda使うならbrefと組み合わせるか、有償だけどLaravel vapor使うんじゃないかな。後者は海外だと商用サービスで使われているはず。ただ今回は単にdockerから繋がってる話だから、サーバーレス=ECSのつもりだったよ。 >>735
laravelタスクスケジュールじゃダメなの？ >>741
なるほど、了解
サーバーレスは意味が広めだから最近悩む Supervisor使ったりSQS使ったりってLaravelじゃなくても良いんじゃないの？
非同期実行自体はPHP8.1でFiberが採用されたら良いなあって程度の状況だし >>746
処理したい内容によって何使うか決めるのも仕事だと思うけどJavaかPythonになるんじゃないかな >>745
うん？Laravelのキュー使った実装はそれ専用の解説書が出ている程度には海外でも使われている
日本だとオープンロジがLaravelキューで実装しているよ
Fiberみたいな話とは根本的に違うでしょ、非同期処理したいわけじゃなくてCQRSアーキテクチャで実装したいのでは？ CQRSならSpring Bootでチャチャっと作っちゃうんじゃない？多分 >>740 は俺が書いたんだけどSQS使う基本的な理由はこれ
もう一つの理由が能力不足と怠慢だろって話なんだけど
Laravel(php)で作った完成物のクオリティを他言語で担保できないってのがある
やっぱりphp3から使ってるだけに言語そのものに対する理解度が他言語とは比べ物にならないから
他言語だと正常に動作するものは作れたとしても
自分が納得できる品質の完成物を作成できる自信がないのよね >>751
わかる
俺も手続き型言語なら何でも良いとは思ってるけど
特定の言語に詳しくなるほどその罠にはまるんだよなぁ
フレームワークもしかり >>751
すげぇよく分かるw
ただ、マイクロサービスとかのインフラとphpってあんまり相性良くないんだよなぁ >>753
さすがにそこまでは行ってないけど
中学の入学祝に中古のPC-9801VM2買ってもらったくらいの年齢よ >>752
>>755
共感してくれる人がいた！ありがてぇ
スキルが足りないなら勉強しろって煽り散らかされるかと思った >>755
高校の入学祝にX68000買ってもらった俺より上か ここって極端に若いかリタイア目前のジジイしかいないんじゃ PHPでダイナミックプロパティ禁止でタイプヒンティングも書いてるなら
他言語いっても同様の品質で書けるしむしろ見通しよく書けるケースも多い
昔のスタイルのままなら手を出さないほうがいい >>756
それで煽るやつが居るとしたら、まともに一つの言語を極めたことないやつだと思う
スキルシートとかで、複数の言語に最高評価つけている奴いるけど、全く信用できないなっていつも思ってる >>759
そんなレベルの話じゃないと思うぞ
phpならキャラクタコードを気をつけなきゃいけない関数を熟知してるけど、他言語だといちいち調べ直してそれでも不安とか
phpならjson_encodeそのまま使うとRFC準拠してないの知ってるけど、他言語だといちいち調べ直してそれでも不安とか
多分そんなレベルの話 >>761
それな
言語の癖みたいなものまで熟知してしまってると、
単にシンタックスが似てるからといって
同じような品質でコードを書けるて思えないんだよな
まぁ実際はそこいらのエンジニアよりマシなコード書けるんだろうけど 例えばこういう部分って他言語との違いを考えたんだけど
他言語でそこまでちゃんと理解してる言語がないから
そもそも例とか出せないんだったわ
例えばPHP限定での例で、配列を連結する場合
$arr = [1,2,3] ;
$arr1 = array_merge( $arr , [9,8,7] ) ; // 大体こっち使いがち
$arr2 = [ ...$arr ,9,8,7] ; // こっちのが早い PHP7.4以降
こういうやつ phpってjavascriptっぽくなってきたよな spring bootでlaravel書いたほうがいいような気がしてきた >>765
それはspring boot以外知らないからそう思えるんじゃない？ いま世界で使われているフレームワークのシェアNo1がspring bootなんだっけ？
そんなにいいフレームワークなのかな？ いいと言うよりオブジェクト思考で作るサービスを提供・利用するのに言語的にJavaが向いてて割と簡単に導入しやすいとか
利用者の多い言語だから欲しいライブラリが既に作られてるとかそんな理由だと思う。
百人以上の規模で作る時に人を集めやすいとか JAVAが向いてる？
たまたま時代的なタイミングが良かっただけ
今更コンパイルしないと動かないようなものとか小規模にはマジでいらない
開発効率悪すぎでしょ コンパイルは透過的に動くから気にせんけど
IDEの支援があるとはいえコードが野暮ったくて使いたくない コードの野暮ったさを言ったらPHPが1番じゃないの >>769
spring-boot-devtools使うとコード変更すると即座に反映されるぞ これからLaravel使い始めようとしてるんだけどサラっとここ見たらハマりやすそうなフレームワークだね ここでJavaの話を出してるようなKYは職場でもKYなんだろう >>774
最近spring bootがphpの実行をサポートしたからじゃない？ すいません、プログラミング初心者です
laravelで2つのセレクトボックスを連動させる方法
(1つめの選択肢:日本、アメリカ、オーストラリア
2つめの選択肢:東京、大阪、名古屋、ロサンゼルス、ニューヨーク、シドニー
のようなもの)
をご教授頂けますと幸いです
一日中ググってるのですが、初心者にわかるようなドキュメントが見つからず困っております。
選択肢は、それぞれモデルを用意しておりdb seedですでにデータベースにある状態です。 javaスクリプトを使うと言うことまでは認識してるのですが、laravelのbladeファイルに書く場合は全てbladeに書いてしまって良いのでしょうか。
その辺りも含めてお教え頂きたく宜しくお願い致します。 結局こういうのはjsで動的に切り替えるような作りにするのが一般的かと
画面読み込み時にjsの変数に全データを代入しておいて
トリガーのセレクトボックスのchangeイベントでもう一つのセレクトボックスを制御するやり方が一番簡単かと 求人とかで募集してLaravelできますとか言う人でたまにこんなのいるんだよな
本当にLaravelしかできない人
最低でもフルスタックエンジニアの経験がないと役にすら立たないと思うんだが
Sierで働いたことが無いんだがこういうポンコツでも雇ってもらえるのか？ なんでエンジニア界隈って、質問に答えずに自分の知識をひけらかしつつ嫌味を言う人しかいないんですか？ 他人がわざわざ自分の時間を使って答えてくれているだけ有り難く思わないと ネット上で質問する人は性格の悪いあなたに対して質問しているわけではないと分かった方がいい
時間を使うのが嫌ならスルーすればいいだけ
他人にウンコの匂い嗅がせてその上感謝まで要求するとか、公害以外の何者でもない スレ違いのセレクトボックスの質問を適切なスレに誘導するなら↓か
+ JavaScript の質問用スレッド vol.123 + [無断転載禁止]
https://mevius.5ch.net/test/read.cgi/tech/1491143438/ >>781
他の人も言ってるようにjavascriptでやる >>781
スレ住人に効くようにうまいこと煽り続ければ誰かがここに答を書いてくれる 5chでテクニカルな質問しても意味はないよ
teratailとかQiitaとか使えば？
ちゃんと質問のルールをしっかり読んで、正しく質問すれば答えは返ってくるよ 質問者はJSでやるのは見当ついててその上でLaravel的な作法を聞いてる
JSスレに誘導するのは文盲すぎる >>795
teratailとか>>785の典型だよな
まともな回答が来るわけない
見ててイライラするサイト Laravelは関係ないけど
こういうのって良く人が足りない案件に入れられて1画面作る担当になってこういう要件で作り方が分からないというありがちなパターンだよね
Laravelは一応分かっていてもフロントのjsの知識が乏しいとググっても自己解決出来ないレベルのエンジニアが来る事あるよなw jsの知識なんて要らんだろ
そのまま使えるソースコードを出してくれたら実装できるんだから
エンジニアが性格悪いからそれをしないだけ teratailとかQiitaに誘導するのは意地悪すぎるｗ
この2つのサービスはもう消えてなくなって欲しいわ
質問読み返したけどこれこのレベルの初心者に説明するの割としんどいぞ、タダではちょっとやりたくないな >>799
webでjavascriptの知識無しの人材なんて仕事にならんよ
趣味でやってるだけなら別にどうでもいいけど 初心者としか書いてなくてレベル感が全く分からないからなあ
文章から読み取るならjavascriptでの実装方法を理解してるとは思えないんだよね
laravelの作法にしてもjetstreamかそうじゃないかで
かなり変わる事を認識してないからlaravelも初心者じゃないかと
まず学ぶべきはlaravelの作法よりjavascriptでの実装じゃないかな
思うに自分自身で学習が必要な部分の切り分けができてないんじゃないかな >>800
5chで聞くよりはまだマシだよ
ここで答えが得られることはまずないが、teraとかならまだある
もっとマシなところがあるならそこに誘導してやりなよ Laravel8＋JetstreamでReactって使えないの？
ぐぐったけどみんなlaravel/ui入れてるけど非推奨だよね？ >>804
ぐぐってteraがよく出てくるけど質問が解決していたこと一度もないぞ >>804
マジレスするとstackoverflowしかないな、本家の方な
俺はそこで解決しなかったら諦めて客に仕様を変更する相談するようにしてる >>806
いくらなんでも言い過ぎよ
すべて解決はもちろんないけど、中には解決してるもんもある
>>807
そもそも本家で質問するレベルの人はこんなところで質問しないわな 初心者なら一番いいのは金払って教えてもらうことだな
クラウドワークスとかで1万ぐらい出せば小遣い稼ぎに教えてくれる人はいるだろう それいいな
初心者ではないが今度試してみるわ、5万出しても自分で1日悩むよりは安い laravelできますって言えるレベルってどの程度なの？ 本まるっと一冊書けるくらいなら言っても良いと思うよ >>811
laravelの開発者に貢献できるようなコミットができるぐらい >>814
ありがとう
こういうネットに落ちてるのをホイホイ使っていいものか…でもまあ自分で作るのと大差ないかそれよりマシか ５chで質問するならまともな回答が得られなくてもかまわない覚悟が必要
真剣に回答してもらいたいならteratailとかQiitaで聞いたほうがいいよ
ただマナーにうるさい人が多いから注意 1つ質問すると10の説教が返ってきて結局何一つ情報を得られないのがプログラミング界隈 何事も使い方次第よ
へたなやつは何やってもダメ
teratailでマトモに質問できないやつはプログラミングも無理だし、
早々に鼻を折られる方が良いとも言える だから信頼できる情報を得たいなら対価として金を払いなよ
見ず知らずの赤の他人のためにタダ働きしなきゃならないなんて変だと思わないかね そもそもここは質問スレではない
クレクレ君は他所でやれ 質問したけど自分が求めていた回答と違うから
ムカついてteratailに誘導するしてると見せかけて同一人物のパターン >>783に割と具体的に書いてるのにこれで理解出来ないならプロで仕事は無理やな プログラマー如きが「プロで仕事」て
よっぽど自己評価高いんだろうな Livewireってやっばり遅い？
がっつりvueとか使ってみたことないけど、まじでphp書けるなら学習コスト低いな
Livewireをモダンなフレームワークにコンパイルしてほしいw >>837
作りによるとしか
結局あれって状態変わるごとに裏で非同期通信して、サーバーサイドから差分のDOMを受け取って差し替えてるだけなので、
下手な実装してしまうと重く感じるかもしれない
ただフロントのライブラリが少ないから(alpine)
ケース次第ではvueより実装コストがかかる 試しにLivewireで1サイト作ってみたんだけど
少し特殊な事やろうとすると方法がわからなくて調べようにも英語メインでシンドイから
もうこれpjaxで良くね？ってなった
ちゃんと使いこなせるならpoolingとかjavascriptからコンポーネントのメソッド呼べたりする所とか
めちゃくちゃ便利だよなぁって思いました こんな流行りそうにないの使うならVueの方が後々楽かと
Vueも使えないなら、諦めろw Bladeって、Laravel使わなくっても使えるの？
オレオレフレームワークでもOKでつか？ twigよりbladeの方が好きな俺は異端か
なんだかんだでphpそのまま書けるのはたまに助かる bladeでforeachで回してる要素に対してjquery発動することは可能ですか？ うまく返したつもりなのか本当にPHPだと思っているのか
selectorの話だとしたら同じclassにして一括操作するか
個別に操作したいなら個々のidを指定してあげる
idよりdata属性の方が適当な場合も多い >>843
foreachで回してphpゲージが溜まってきたら特殊コマンドでjquery発動できるよ composerでlaravelのプロジェクトを作成しようとしているんですがzip解凍するツールねーぞって
おこられて作れないんだけど誰か原因わかる人いますか？
linuxのコマンドとしてunzipは使えるしphp -mでモジュールを見た時にもzipライブラリが認識されているしでよくわからないです 怒られてるメッセージを貼ってみてよ
おそらくはphp-pecl-zipあたりが入ってないんだろうけど 必須ではないと思うけどその後書き込みないから解決したんじゃね laravel関係ないですけど
formタグの中で、ファイルアップロードタグを使う方法教えて下さい。
アップロード押すと、formタグがactionしてしまって困っています。
アップロードタグだけ外に出して、jsで中に表示ってのも試しましたがダメでした。
初学者ですが期日が近くて困っています。 >>853
クラウドワークスとかで教えてくれる人を募集して一万円ぐらいを払うと丁寧に教えてもらえるよ こっちは仕事でやってるのにタダで教えるわけねーだろ
他人をなんだと思ってるんだ 当たり前だろ屁理屈言うための場所だぞ
ここをなんだと思ってたんだ？ ファイルのアップロードすら実装出来ないなら仕事辞めろよ >>863
「セキュアな」って頭につくとめっちゃハードル上がるけどな >>867
httpsでセキュアじゃないならhttpsなんていらなくね？ｗ
>>868
草 >>869
おまえは自分のシステムに他人のファイルを置くことの意味をもっと知ったほうがいい >>870
そんなレベルで気にするならそもそもハッキングされてるやろw
それに大抵は画像ファイルかcsvなどのデータファイルのやりとりだろうし
それで問題が起こるシステムなら設計が悪いんやろ >>869
お前みたいなのがいるからLaravel使いのレベル低いって言われるんだよ
httpsがセキュアなのはクライアントとサーバー間の通信が暗号化されていると言う点でそうだって話で
プログラムの誤動作を誘発する攻撃に対してセキュアであるって話ではないぞ よくそこまで後出しで吠えられるのな
要件にツッコむならわかるが >>873
いやホントw
普通にセキュアと言えば通信の話なのに
そのファイルで攻撃とかw
どんなセキュリティーだよって思うわw セキュアと言えば通信の意味、ってのはどうかな？
たしかにそういう意味合いで使われることは多いけど、
言葉自体の意味としてはもっと広いよ
どっちもどっち、喧嘩両成敗ってところ >>875
アップロード機能に限って言えば、セキュアなって言ったら不正ファイル対策だろ
通信を指すことなんてほぼないぞ >>874
やれやれ、ここまでバカだと話にならんわ
セキュリティの勉強ぐらいしてこい >>876
俺は知らんよw
>>873に言ってくれや いや>>874に言ってくれくや、の間違い
まあ、言葉のあやだし、どっちもどっちだよ
すれ違いってことでいいじゃん Web開発者的には、通信がセキュアなのは大前提だと思っていた >>880
常時SSL当たり前の世の中だからな
セキュアではないって言われて
httpsだから問題ないって答えるのはさすがにヤバイ
>>875
>>872が初レスなのに喧嘩両成敗て言われても困るんだが >>877
お前の方が頭悪いわ
攻撃される様な仕組みなんてphpのサイトに書いているやり方で100%無理やろ
ハッキングされてるならそれはosなり別の問題 >>882
おまえの言ってるphpのサイトって何？ セキュアって言ってるのに急にセキュリティの話してる時点で頭悪すぎでしょ >>885
あなたの考えるセキュアとセキュリティってそれぞれ何を指してるの？ すいません、質問です
単なるhtml,css案件なのかもしれませんが
formタグの外のボタンを、ブラウザ上だけ内側に表示させたいんですが可能ですか？
イメージとしては、メインのフォーム(名前、住所、性別等を入力する欄)があって
その中に画像をアップするエリアがあって
画像アップと個人情報の送信は別個でやるのですが
画像アップを、個人情報と同じエリアに表示させたいです。 今のところ画像アップを完全に枠外に表示すれば、画像をアップした後でそれを含めて個人情報登録、みたな処理ができるんですが
画像アップボタンをエリアの中に入れてしまうとそのボタンでフォームがサブミットされてしまい
どうしたものか困り果てています。 すいませんもう少し分かりやすく言い換えます
フォームの中であるボタンを押した時に、アクションを発動させない方法を知りたいです。 すいません、自己解決しました。
buttonにtype="button"を追加することで非活性化することができました。
お騒がせしました >>894
laravelではPHPのコード書かないの？ >>884
データ細工してバッファオーバーフローされる可能性を考慮してAV通す
等かと思ったらファイル名に注意って、ファイルアップロード関係なくて草
どんなパラメータも基本バリデーションしてくださいよ >>896
リンク先の記事だとわかりにくいけど、セキュアなアップロード機能ってバリデーションすらちゃんとやろうとするとむずい
たとえば、
https://blog.tokumaru.org/2007/12/image-xss-summary.html?m=1
みたいな事例を知らないと、何をチェックすべきかも指針が立たない >>895
アップロードファイルはまずはlaravelが処理してくれるよ laravelに無関係な古い情報のサイト出す人、的外れだね 結局このスレでは誰も答えられないんですね
他当たります 広く使われてるフレームワークにくだらない基礎的な話に対処してないわけないとは思わないのだろうか >>903
サーバ要件にGD系が入ってないからだろ 画像ファイルのバリデーションをセキュアな方に倒すと、GDとか使って別フォーマットに変換してもエラーが発生しないか確認する手法がある
>>898 みたいな事例を知ってるとやりたくなる確認方法だな
Laravelの標準だとgetimagesize()までしか検証してない
基礎レベルの実装はしてるけどセキュアかと言われれば微妙 >>907
たしかに
>>903 はなぜ基礎的な対応はしてあると思ったんだろう
具体性が全然ないな 不正なメタ情報いれてコード実行する手法が過去あったから
画像ファイルは画素情報だけ抜き取って保存する必要があるのがめんどい
大抵のシステムだとリサイズして正規化するからそのついでだけど 通知メールからold('email')を取得する方法をご教授いただきたくお願いします。
デフォルトの実装のauthならできるのですが
カスタマイズした際に、通知メールのリンククリックした際にメールアドレスをbladeに渡せず。 通知メールを日本語化しようと、Notificationを新たに作ってオーバーライドしたら
今度はリンククリックした時にメールアドレスが受け渡されないと
ちょっとした問題を直すために次から次へと新たな問題が生まれてガチでイラついてます。
そもそも最初の英語の文面を直接編集できれば済む話なんですが
そのファイルの場所がどこなのか書いてるサイトもなく。 それくらいのことで苛つくなら、そもそも合ってない
フレームワーク使わずに自分で分かるように実装すれば？ > それくらいのことで苛つくなら、そもそも合ってない
いや、普通に
> そもそも最初の英語の文面を直接編集できれば済む話なんですが
だけの事。 ググってもオーバーライドするやり方しか出てこず
直接編集するやり方が出てきません。 マニュアル読んだ？て質問に対して、ググってもーて返事しちゃうのか
ひょっとしてマニュアル読まないでlaravel使おうとしている？ >>916
マニュアル読んだ？＝マニュアルに書いてあるよ
って読み取れるかどうかはコミュ力なのかなんなのか あ、オーバーライドじゃなくてvendor:publishして直接編集したいって話か >>919
すいません、既に解決しました。
php junkieってブロガーの人が唯一、元のファイルの場所を書いてくれてました。
且つ、直接編集せずにja.jsonに訳を書くだけでいいって教えくれました。
神です notificationとブレードを新たに作ってガチャガチャやるやり方も一応惜しいとこまで行ったけど
トークンとメールアドレスを両方パラメータにしてURLに渡すやり方がようわからず挫折。 >>921
あ、そうなんだ
それなら上で紹介したマニュアルで十分だったか
今後はマニュアルを先に確認するよう
癖をつけとくと良いよ 便利なツールがあふれ速くものが作れるようになった
でも理屈を知らず地に足がついていない技術者？も増えた >>923
調子に乗らないでください あなたもわからなかったくちですよね？ >>928
わからなかったひとを煽るためのレスでしょ？
>>919でアドバイスしてた俺に言われてもお門違いとしか思えない >>929
東大卒新垣結衣似彼女持ちの俺もそう思う 普段Safariの有料の拡張機能で黒白反転させて開発してるんだが
Laravelのエラー画面だけ毎回急にパッと白になるのがめっちゃ腹立つんですが
解決方法ないですか？ お題きましたよ
laravelのエラー画面が真っ白になる、その意外な理由とは？ >>933
Laravelのエラー画面のデフォルトは白だが
Safariの拡張機能使ってもそれだけ色が変わらなくてウザいって話 俺が言ってんのは
error page for laravelのことね Laravelの画面が真っ白ってそれPHPがエラーはいて真っ白になっているだけでは？ CSSの組み方が特殊なのかね？
それともSafariの拡張がヘボいか？
Chromeは標準でナイトモード付いてるけど、それで試したらどうなる そもそも真っ白な画面ってlaravelがまともに動いてないでしょ そんなもの使って開発するな
どうでもいいことに時間使ってんじゃねー 先週からLaravelを触り始めましたが新規登録と更新でまったく同じバリデーションの場合
フォームリクエストは一つにまとめるべきですか？それともバリデーションが同じであっても
新規登録用のフォームリクエストと、更新用のフォームリクエストを分けて作るべきですか？ 同じなら分ける必要ないのではないかと思うけど実践でLaravelを使っている人たちの意見を聞きたいところではありますね >>940
問題が起きにくいのは分ける方式だぞ
トランザクションとしては異なるので仮に記述が同じでも別物として扱う
Laravelで作られた有名どころのOSS見たけど全部そうなってた >>940
この辺の質問されたらいつも
フォームリクエストの名称何にする？って聞いてる
例えばUserCreateFormRequestっていうならそれが答え
UserFormRequestっていうならそれもまた答えだと思う
どう設計するかによって変わると思う >>943
そもそも同じフォームリクエストを使うというのが間違い
バリデーションが同じであろうがフォームリクエストは分けるべき >>943
意識高い系ぽい回答で笑ってしまった
それだと設計上のメリデメを答えてないから
何か言ってるようで何も言ってないじゃん >>945
確かに読み返してみたらかなり偏差値低そうな中身ゼロのレスだった
恥ずかしいから無かった事にして・・・
でも一個だけ言い訳させて
酔ってた 初心者だけどhttps化したいけどhttpでaccessできちゃうし、httpsでaccessしても最後に/がつくとhttpになっちゃうんだけど原因ってなんだろ?
.htaccessいじってみたけど効果ないし。 >>948
初心者ならできる人に頼め
普通はrewriteで対応するけどやり方はインフラによる laravel初心者です
ちょっとわからないので教えてください
A,B,Cという3つのテーブルがあった時
A-Bは1対多
B-Cは1対1
というリレーションで関連付けられています
この場合ＡからＣの値をとってくる際
belongsToManyであってますでしょうか？
厳密には多対多ではないので別の方法いなるんでしょうか？
初歩的な質問ですいませんが一般的なやり方を教えてください
よろしくお願いします >>951
ありがとうございました！助かりました！
追加で質問すいません
hasManyでリレーションしているテーブルに対してwithをつかったデータの取得がうまくいきません
原因は何でしょうか？
・リレーション
A-Bは1対多
・やりたいこと→Ａの値と、それに関連するＢのIDのみを取得
Ａ::with(['Ｂ:id']);
・結果
Ａの値のみ取れて、Ｂの値が空っぽ
・補足
なぜか「Ａ::with(['Ｂ']);」だとデータは取得できるようです もうここまでくると『生SQL書いてた時代の方がよっぽど平和だったな…』ってなるわ。
hasManyだのbelongsToManyだの…
JOIN理解してればそんな無駄冗長複雑怪奇腐れ糞うんこメソッドなんか、
覚える必要、全くねーだろ！
って、時代になってしまったな。
今どきの園児neerは可哀そうだ。
哀れな子だ南無～ by 岩柱 >>952
そりゃそうよ
BはIDカラムしかないのに
AとBのJOINする時どのカラム使うつもりよ >>954
Aとjoinするためのa_idというカラムはもっています >>955
俺は人間だからa_idを持ってるんだろうなーって想像できるけど
withの人はわからないでしょ？ >>953
そこはフレームワークも強制してないし好き好きでいいけど
結果をJavaでいうDSOのような定義済みEntityに格納さえしてくれれば
いまダイナミックプロパティ多様してるプロジェクトみててサツイわいてる >>957
次に出そうな疑問が
モデルにリレーション定義書いてあるのに何で改めて書かなきゃなんねーの？
辺りかなと読んでwithさんはモデルAで仕事してる様に見えるけど
実はeloquent builderからの派遣(しかもリモート)社員だからモデルAの社内ルールは知らないのです
とか言おうとしてたけど壊滅的に例えが下手な事に気がついた 色々ご返答ありがとうございます
やり方自体は間違ってなくて
こちらの環境に問題があるということですよね？
とりあえずもうちょっと調べてみます マニュアルの「特定のカラムのEagerロード」の項目の
Note: この機能を使用するときは、取得するカラムのリストで常にidカラムと関連する外部キーカラムを含める必要があります。
これをどう解釈する？ ありがとうございます！
ようやく理解できました
idではなくa_idを追加すればよかったんですね
ずっと悩んでたんですが助かりました😂 6の本買ってずっと放置している（知識は5で止まっている）のですが、
9の本が近々でる可能性ってありますか？
8の本はありますが、これから学ぶつもりはありません。 >>965
本はでるかもしれないけど、あなたはきっと読まないでしょう >>968
毎週8のアップデートに目を通しているやつなら
9が来てもそんなに変わったとは思わんだろうね symfonyが変わるにしても、
フレームワーク使う人が触る部分でがっつり変わることはなさそうだけれど
速度とかそういうところには影響しそうだが 速度気にする人はそもそもlaravel使ってないだろう RDBMSつかうなら大半待ちで変わらなさそうだけど
同時処理増えてくるとさすがにJVM系には負ける
低レイテンシーなオンメモリ処理が主体ならうまく書く必要あるけどCやErlang 言語を変えろって行きすぎじゃね？
PHPのFWの範囲内でいいだろ まぁ普通に>>977だよね。高いサーバーてかアプリケーションサーバーの台数増やすって話。
速度のためにDX犠牲にするって発想は、今の時代に合わない。 イベントとキューってどうやって使い分けるんですか？
Laravel初心者なんでどっちも同じように見えます キューは非同期処理
時間がかかり待つ必要がない処理につかうと発行する側は待たずに済む artisanファイルって本番環境ではやっぱり削除しといたほうがいいのかな？
普通はドキュメントルートにしかアクセスできないから安全と思ってたけど
最近Apacheでドキュメントルート以外のファイルにアクセスできる脆弱性が見つかったから
今後同じような脆弱性がまた発見されたときどうなるかが心配です 9のリリース日まだ決まってない？1月中に出るんだろうか >>984
仮にアクセスできたとして何が問題なの？
アクセスした人間に実行権限が与えられるとでも？ むしろ心配すべきは.env覗きみられることじゃね？ >>983
ありがとうございます
イベントで非同期になる場合ってないんでしょうか？ >>984
マイグレーションとかタスクスケジュールとかどうやるつもりなのか Laravel遅すぎるからCodeIgniterにする 公認会計士とwebエンジニアならどっちがウマミある職業ですか？ >>990
プロファイラでどこが遅いかしらべた？
Builderとか特定のどこが遅すぎるか知りたい
まーI/OかGILで待ってるかアルゴリズム悪いだけだろうけど 会計士の方が一生稼げるけど、うっちゃけ金の計算ばかりの仕事面白いんかな >>992
調べたというより世界中で調査してるからそれを見たらLaravelが一番遅くて萎えた >>993
会計士は稼げるけど、独立しない限り労働環境ブラックだぞ
エンジニアは内製しているそこそこのweb系起業ならかなりホワイト >>996
ベンチマークにモチベーション求めるエンジニアもいるからただのバカではないかもしれない
ベンチマークフェチの変態エンジニアの可能性もある このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 124日 18時間 5分 44秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
