◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:【PHP】Laravel【フレームワーク】 Part.8 ->画像>1枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/php/1625721320/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
コントローラーで共通の処理を別ファイルにまとめるのはトレイトを使うのはlaravelの流儀ではないと思うんですが先輩方のご意見を伺いたいです。
別に使って良いと思うが
コントローラーの共通の処理があるなら、コントローラーの基底クラスに実装するのがOOPとしての当たり前の考え方だが、
ドキュメントにトレイトを使ってくれって書いてないもので。。。
自分でかいてるアプリなら自分の好きにやりなよ
そのへんの自由度が、railsやcakeとかと違うところだよな。
何やってもいいなら、もう、フレームワークの価値ないじゃん。
他人に迷惑かけない限りは好きに使えよ
>>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使うんじゃないの？
>>55 その話はとっくに結論出てるし、vendorネタに持っていこうとするあたりループ君でしょ。
Laravel勉強してるんですが実際に使われてるwebシステムで参考にできるオープンソースあったら教えてほしいです
荒らしさんとかルーパー君が入れないレベルの話をすればいいんだよ！
>>61 それくらいググれよ
laravel example で検索したら色々出てきたわ
>>60 こっちは初めてこのスレにきたんだからそういわれましても
>>63 すいません検索ワードが分からないです。なんて検索したら良いですか？
>>64 ありがとうございます。
日本語のサイトは無いですか？
lockフォルダ以外で、どうやってatominするの？
jetstreamやらuiやらbreezeやらたくさんあるけどメンテナンス大変そう
Jetstreamは結局クソという結論でいいのか？
使った奴の感想もっと聞きたいんだが誰も使ってないから話にならないという
>>75 使ってるぞ。特に文句無い。ローカライズがちょっと面倒なのと、マイグレーションファイルに使ってないカラムが入ってくるのはウザイけど。
>>76 最初使った時はスゲーって思ったからローカライズ用リポジトリ作ったりしたんだけど
ちゃんと使いこなせなかったみたいでだんだん使わなくなってリポジトリ更新止めちゃった
正直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でも
>>86 この手のチュートリアルやった初心者は
面接でlaravelとvue使った事ありますって言っていいのか？
>>86 使ってるモノが微妙にバージョン古くない？
>>86 検索に引っかからないようにSEO落としてやるよ
>>94 逆SEOってこの間の法律改正で犯罪扱いになったんじゃないっけ？
>>94 よく堂々と逆SEOしますなんて発言できるな
>>96 laravelとvueに関する知識は一切獲得できないけど、良質なチュートリアルってそういうもんなの？
Laravelのdotenvは環境切り替えに便利ではあるけど
環境によって変わるものは.env
また.envはコミットしないとかイキってるバカが湧いてきた
.envに書くならデータベースの設定などはconfig/app.phpに入れる必要ないよね
>>106 confg/app.phpにデータベース設定書いてあるの？
本番用の.envはコミットするけどテスト用とか開発用とかの.envはコミットしないよ
>>109 .envって結構phpでは使われるから覚えていたほうがいいぞ
APP_NAMEとか.envとapp.php両方に書いてあるからね
>>111 ちゃんとドキュメント読んでる？
そもそもdotenvとconfにあるファイルって用途が違うってわかってんのかね
なんでLaravelはveuばっか使うんだよ
>>114 どう考えてもLaravelは上級者向けだよ
大手でもたくさん採用されてるし
vueなんて日本でしか使われていないし主流はReact
>>118 それお前の妄想だよね？なんかデータあんの？俺の認識だと日本はRailsが主流のガラパゴス。世界的にはLaravelのほうが主流。googleトレンドやjetbrain社の調査結果が根拠。
Railsの案件なんて実際相談も来たことねーわ
>>124 もちろんLaravelを使う人は「意識高い」よ
「意識高い系」じゃなくて「意識高い」だから気をつけてね
>>125 言ってる意味がわからないです。ようするに意識高い系ってことですよね
意識高い系と意識高いの違いわからないの？
>>124 Laravelを使う人は意識高い系です
>>127 じゃあLaravel使ってるだけの人は意識高い系で間違いではないだろ
Laravel使う奴はむしろ意識低い奴だと思うが
保守のためにCakePHPを使うことはあるけど
>>131 いや流行ってるから使ってますって理由だけだったら意識高い系だろ
今だとLaravelしかない。
変だと思うならsymfony使えば良いだけでしょ。laravelをdisりながらそれ使うとか矛盾してるぞ。
Laravelはもう下火だしな
お、意識高い系がバカなこと言ってるな。nodejs使ってるとこなんてスタートアップでもプレイドぐらいしか知らんわ。せめてデータで示せよ。
実際Symfony6がリリースされたらLaravel駆逐されそう
>>139 具体的に6は何が良くなってんの？symfonyてメジャーパージョンアップつっても劇的に何かが改善されるイメージ無いんだが？
>>140 このサイトのデータって外部から分かる範囲のデータのみで比較してないか？
当然nodejsのスコア高くなると思うんだけど
>>142 外部からわからないものをどうやって調査しろと言うのか？
少なくとも日本ではExpressがLaravelより使われてるという感じはぜんぜんないね
>>143 そういう性質のデータなのに
>>137 で
> Laravelはもう下火だしな
> 今はExpressのほうが圧倒的に使われている
って言い切ってるのがおかしいって言いたいんだけど
>>145 それはどのフレームワークでも同じ話で、見えてる範囲と見えてない範囲でシェアが近いと
>>146 expressはX-Powered-Byで識別できるケースもあるんで、他のフレームワークより検出しやすい
>>145 データの正しい見方を勉強してからレスしなさい
お前だけレベルが低すぎてデータ見ても頓珍漢なこと言ってるぞ
Reactのセットアップって1行でしょ？
>>140 それって技術スタックを推測するツールを使ったデータ？すでに指摘がある通りlaravelに関しては判定できないケースが結構あるよ。
俺が信頼しているjetbrain社のエンジニア向けの無作為抽出アンケートでは、普段使っているjsフレームワークは？という問に対して、expressと答えたのは2019、2020年が40%、43%だったのに対して、2021年は24%に落ち込んでる。
一方のlaravelは2019、2020年が50%だったのに対して、2021年は67%になってるね。
お前の主張と真逆の結果になってるよ。
他のフレームワークに寄生するLaravelが人気なんだもんな
>>150 jetbrain社っていうところで既にバイアスあり。
>>151 OSSのパッケージインストールしたことない人？大抵のライブラリは他のライブラリに依存していると思うんだけど？そういうのを寄生と表現するのは初めて聞いたわ。
それとramenてのも初めて聞くね？文脈からするとフレームワークかな？もしかしてlumenから派生したもの？
>>154 多分、開発者エコシステムの現状というアンケート結果を見てるのだろうけど、
·phpとjavascriptは分けて集計されてるから、67％という数字だけで単純比較できない
·フレームワーク使用の割合を足して100%超えるのはどういうことだろう？
·アンケート対象に偏りがある。重み係数が非公表。
もう少し情報処理能力を磨いたほうがいい、
まあ特定言語向けの製品作ってるところのアンケートは信用できないわな
>>155 日本語ちゃんと理解できる？俺は前年度の同フレームマークの比較しかしてないんだが？勝手にexpessとlaravelを比較しているような印象操作はやめてくれるか？
あとアンケート対象に偏りがあるとする根拠は？ちゃんとメソドロジーのとこ確認した上で主張しているかい？それともお前の妄想に基づく主張？
>>156 あー、メソドロジーのとこ読んでないで妄想で批判してるだけってことだね。理解。
てか
>>140 は他のひとたちからも否定的な見解が出てるのに、
>>140 に固執する理由が謎だし、
>>155 のように重み係数の公開まで要求しているくせに、それよりはるかに透明性に欠けてそうな
>>140 を信頼している理屈がわからん。
>>157 このアンケート見て、expressが単純にシェアを急激に下げてると判断してるとすると、お前やばいぞ
んなもんどっちでもいいだろw
>>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スレ簡単に見つかるけど、
久々にきたらめちゃくちゃスレのPartが進んでいてびっくりした
>>184 技術に関することで論破されてLaravelerが発狂して荒らしたの間違いだろ？
>>183 荒らしたいループくんに見事に釣られまくったやつがいてスレ消費しただけ
どっちもまともにLaravel知らんから、過去スレ見る価値もない
でlaravelとExpressはどっこいどっこい？
>>188 もう俺の負けでいいから他スレでその話題はやってくれ
>>186 だからなんでわざわざ話題をループさせるんだよ お前ループ君か？
>>188 どう考えてもLaravelのほうが優秀
>>197 >>190 もループ君だぞ。釣られんなよアホ。
ごめん、話ぶった切って悪いんだけど、俺、凄いことに気づいちゃった！
古い書籍（5系）をブックオフで見つけたから買ったんだが、
すみません。
>>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
いやちがった
時間の無駄になるし、とっとと8の本を買った方が言いよ
5でなんとかCRUDの基礎を学んだわ
>>211 正確悪ぅ！ これだからLaravelerはキモいんだよ！
Laravelで複合主キーを使う方法について教えてください
>>215 ループくんはいつになったら消えてくれますか？
非公式のトレイトがどこかで紹介されていたけど
blade書く時に、HTMLを直接書いてますか？
>>219 複合ユニークにしたほうが無難なんですねご回答いただきありがとうございます。
よく考えたらマイグレーションでは複合主キーサポートしているのにEloquentはサポートしていないっておかしいよな
郵便番号や駅データなどの大量レコードを用意したいとき、
それが無難だと思いますよ
シーダーの話だと思うけど
>>224-225 シーダーの話です。
初期データはシーダーで用意するイメージが有りましたが、
SQLかCSVの方がいいんですね
シーダーで大量のデータ入れるのって大変じゃない？
シーダーっても大した機能ないから、直接SQL叩くのとほぼ変わらんよ
ドキュメントではシーダーで出来るよって書いてあるけどね
別に本番でもシーダーで初期値設定することが悪い訳では無いとは思う
Laravelのドキュメントにはシーダーは「テスト用」とはっきり書かれているが
>>230 馬鹿発見
公式でもやめろって言われてるのにまだやってる馬鹿いるんだな
シーダーはテストデータ詰めるときとかは色々使いようがあるが、
それな、使うべき理由がない
>>232 でその理由は？
特に理由が無いのに何も考えずに辞めろってｗ
シーダーで登録して何か問題あるの？ｗ
プログラム板にLaravel初心者のキチガイがいてたぶんこちらに来ると思うから相手よろしく
どうせいつものアンチオートインクリメントおじさんだろ
よくわからないんだけどシーダーで登録するとどういうデメリットがあるの？
また前スレか前々スレの話題かよ。ループくん？
モデルのオブジェクトでAttribute と Original で値が違う場合がある？
>>243 orginalはDBから取り出した直後の値。attributeは外部またはシステムによって書き換えられた値が入る。それだけの話だから謎でも何でもないと思うが。
なぁ、ファサードって、何なん？
俺も気になってた
単に簡潔に書けると言うくらいかと
テストする場合、テスト側からファサードに登録しているクラスをモッククラスに置き換えられるのは大きなメリットじゃね？
>>249 別にその用途ならDIでやれるしなぁ
わざわざファサード使わなくても良くね？
>>250 依存が少ないならそれでも良いと思うぞ。コンストラクタインジェクションで長々とクラス列挙されたら嫌じゃん？
>>249 >テストする場合、テスト側からファサードに登録しているクラスをモッククラスに置き換えられるのは大きなメリットじゃね？
まぁ、その説明は確かに分らんでもないけど、そのくらいしか使いどころが無いのかい？
>>252 普段使いではそんぐらいでしょ。レアケースで良いなら、ファサードで呼び出してたサードパーティパッケージがイケてなくて、オーバーライドが必要な時に便利みたいな話はある(実際過去1度だけそういうケースがあった)。
Laravelはそろそろcreate-projectした段階でusersテーブルのマイグレーションやモデルが用意されているのを辞めてほしい
そこまで用意して来るならジャンゴみたいに綺麗な管理画面作ったくれると良いんだが
>>254 いらなきゃ消せばいいだけだし
普通はそのまま使うし認証部分は大きく変えたりしないし
>>256 Novaがあるでしょ。まぁ有償だけども。
usersテーブルの認証機能を使わないなら何のためにLaravelを使うのか
そこまで毛嫌いするもんでもない
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ファイルを作ってそっちを編集したほうがいい
元あるファイルを修正するのではなくそれをオーバーライドした
>>277 煽るぐらい自信満々に回答したのに、バカにされたからって話を変な方に持ってくのはやめとけ。恥の上塗りだぞ。
サービスプロバイダでmergeConfigFromメソッドとか使ったことないんかね・・・
Taylor Otwellはよく講演で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フォルダ直接修正しているね
自分で作ったものなら意味も分かってる訳だし動作確認とかで修正するのもありなんじゃね？
>>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に
>>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なんだろうって謎が解けたわ
今日もまた一つ賢くなってしまったありがとう
いまいち本番環境へのデプロイがイメージわかないんだけど
>>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は選択肢として有り
composerやnpmは環境次第で高確率でトラブるから使わないようにしてる
WindowsとMac使わないって開発環境もLinuxって事なの？
開発環境はWindows上のLinuxだろDockerか何かの
composerやnpm使ってデメリットになることはほとんどないな
【悲報】Laravel9でまたModelsディレクトリが消失してしまう
モデルの置き場を強制されることを嫌う奴が開発陣にいるの？
リポジトリには来てないけどな。情報源はどこだろう？公式のdiscordでもなさそうだし。
皆さんはlaravelを使っていると思いますが
Eloquentの100ループ問題を早く修正してほしい
Eloquentって使ったことないなそういえば いつもクエリビルダ使ってるけど
>>336 bladeをWordPressみたいにWeb上で更新できるようにしたい
ローカルでいちいちエディタ使わないといけないのが面倒だ
laravelはsymfonyと比べると使いづらい
>>340 自分もあったら良いなと思ってたんですよね
自作するとしてエディタは何がいいと思いますか？
それならFTPなどの同期でも利用すればローカルのbladeファイルを保存したらアップロードされたりするしそれで良さそうな
使う場面が想定できんな
詳細な要件は不明だけど、今どきはgithubリポジトリでピリオド打鍵したらすぐwebエディタ起動するじゃん？それでbladeファイル編集して、保存時にgithubアクションでデプロイする仕組みにしとけば、希望は叶うんじゃないの？プレビューしたいとかなら、話は変わってくるかもだが。
>>345-347 やりたい事はかなりシンプルで
デザイナー？HTMLコーダー？の人から上がってきた
HTMLをbladeファイルにする作業から逃げたいってだけなんだよね
結構github何それ？って人とかいてそういう人にどうやって直接触ってもらおうか悩んでるのよね
ヘッドレスCMSとかも考えたんだけど不評でさ
デザイナレベルならGitHubたたき込んだ方が早い
>>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みたいなテンプレートエンジンがあるんだろ？
普通はwebデザイナーにHTMLを作って貰ってそれをプログラマが
デザイナーはモック作ってお前らがphpでマークアップするんだろ
別会社が作ったHTMLを組み込む場合は自分でbladeにするけど、社内で全部作る場合はデザイナーがblade書くよ
たとえばデザイナーに修正させるときはどうするんだよ？
いじるなって言ってもミスは防げないだろって意図か？
プログラマーが作るhtmlとcssはマジでゴミクソだからな
俺が書くHTMLのソースはきれいだと、よくデザイナーに褒められるぞ。
俺の周りはデザイナー作のマークアップのほうがひどいわ。セマンティック何それ？コンテンツモデル何それ？autoprefixer何それ？みたいなの多い。
Reactをいじっているところだけど、
>>381 自称フロントエンジニアはただのプロップスマン
デザイナーにステート管理とstyleComponentとjsxを任せるしかない
>>382 理想はそうしたいけどそうなると今までのデザイナーの担当範囲を相当超えちゃうでしょ
もはやデザインができるプログラマーみたいにならない？
そもそもデザイナーがコーディングなんて担当しないだろ
Laravel6でAppServiceProviderのboot()に↓を記述してDBアクセスしてもログが出力されないんだけど原因思い当たるエスパーいますか。
>>386 ちなみに何がログ出力されない原因だったんですか？
>>383 プログラマーができないんだから仕方ないじゃん
今まででまともにできるプログラマーを見たことがない
>>384 デザイナーはhtmlとcssができてプログラマーはできないからやらせるしかないよな
モックからマークアップに起こせるプログラマーもいないし
>>387 クエリログを出力していない別のログファイルを見てました、、、
Laravelerって簡単なWEBページ作成すらできないのかよ・・・・
LaravelってCakePHPでいうテーマ機能って無いんだな
ページ作成できるできないで言ったらできるぞ
Laravelの認証ってLaravelだけで完結してるの？
Firebase使わんとならんとかなら使いようがないだろうねw
そもそもなんだけど、auth0とかFirebaseとかなんで外部の認証サービス使うんですか？
釣りでしょどうせ。初学者がLaravelセットアップして最初にやることが認証パッゲージの導入でしょうに。
完結できるならそれでいいんですが、なぜLaravelでFirebaseなどの有料認証サービスを使う開発があるんですか？
簡単な話だよ。外部の認証サービス使えば、内部に認証情報を保存しないから、セキュリティ面での不安が少なくなる
>>400 うーん、だけどFirebaseでIDトークンって厳密には漏洩リスクがあるから最大1時間で可能なら要件によってもっと短く設定しますよね
どっちもリスクあるから好きなように使えってこと？
作り方次第では？
認証って、どのレベルまでのを想定してはなしてんのよ？
Laravel用のSmartyってあるんだな。しかも8にも対応してる
わざわざsmarty使う必要は無さそうだけどcakeからの移行なら使いやすいのかな？
Smartyは、EC-CUBEで嫌々ながら使っている
>>403 メアドとパスワードの認証レベル
他にはGoogleとかのプロバイダ認証も使うかってこと？
なんでServiceProviderみたいなめんどくさい事してんだろ…。
Laravel作った人ってさ、静的クラス使ったら死ぬ病なのかな？
必要もないのにインスタンスなんか作るから遅くなるんだよ…。
ああ…、もしかして、use書きたくないマンなのか…。
なんとなくServiceProviderの仕様、分かりました。
DBファサードのget()結果は\stdClassのコレクション限定なん？
…pluck()、また、どうしてそんな実装考えついちゃった？ってのが出てきた…。
…chunk()、は、分からないでもないけど、そんなのが必要なケース、出会った事無いなぁ…。
うーん…、これ、外側の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 「レコードの主キーに基づいて結果を自動的にページ分割します。」って、どういう意味よ？
あれ？ ちょっとまって？
```
土方が入ってくる現場ではQueryBuilderは採用できないな、これは。
```
```
あえて用意してる機能に文句ばっかり言ってるけどeloquent使わんの？
JSON型のサポートがあるのか…。使った事無いなぁ…。
>>427 Eloquerntはある程度知ってるから、今日の Learning からは除外。
whereNull／whereNotNull は、まぁ、分かるけど、
うーーーーーーわーーーーーーｗｗｗ
これに限った事じゃないんだけど、
```
Laravelに、せめて2つか3つ、便利なところがあればまだ納得できるんだけど、
```
```
```
```
ふぅ、とりあえずQueryBuilderのドキュメント一通り見たけど、
>>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編集できないこと」って、それさすがに釣り針デカすぎでしょうよ。
もうちょっとシンプルなやつないのかね
laravelもそろそろバッチ処理関連の機能追加とかないかな
わからんけどイベントとジョブで似たようなもの作れるんじゃない？
Laravel最近ぱっとしねえな
Laravel6だけど、HogeControllerをGETで呼んだ時にそんなルーティングないよってエラーになると思ったんだけどwen.phpのルーティング使われてフロントのHTMLが返却される。
route:list見ればわかるけどapi.phpのはパスの頭に「api/」要るよ
api呼ぶときのURLは↓で呼んでる。なのにweb.phpのルーティングが呼ばれちゃうんです。
http://localhost/api/hoge だいたいのFWがそうなるんじゃない？
シンフォニーが使いやすければシンフォニーで良いじゃんって思うけど、なんかLaravelじゃないといけない理由があるのかな。
laravel-uiで認証機能付きのサイトを簡単に作れる所とか
簡単に作れすぎてセキュリティがおざなりにならないか不安
新規のサイト作るときは、ActiveRecord使えるのはやっぱ良いと思うよ。ケースバイケースてことを理解しない一部が的外れな批判をするけれど。
>>473 cakeなんかはクソ雑魚が実装したらセキュリティホールだらけになるじゃん？Laravelは雑魚が作っても問題が起きにくいから大丈夫じゃね？
POSTのときはCSRF強制されるし、eloquent使えばSQLiも起きにくい。bladeを普通に使ってりゃXSSも防げる。ハッシュ化もHASHファサード使えば、ソルトとストレッチングもお任せだしな。
認証も標準の使ってりゃ、セッション固定の問題も起こさないだろうし。
cookie周りのデフォルト値が若干緩い気もするが、まぁ無知なやつでもある程度のセキュリティは確保できてるでしょ。
8使ってる方はわかってると思いますが
>>468 使えています。
>>469 >>470 そうなんですね。
階層変えて試してみます。
ありがとうございました。
Laravelは学習コスト低いのがいいやね
しかし、Laravelはフォルダ・ファイル構成がぐっちゃぐちゃだな…。
Bladeは、ちょっとした物をつくるには手軽で便利かな。
テストはダメかな。
Migrationは全然ダメだな。
うーん、AuthがControllerで提供されてるのか。
うーん、入力値のバリデーション時に一緒に既存ユーザのメールアドレスのuniqueチェックまで一緒に行うのか…。
というか、リクエストのバリデーション中にDBにアクセスするの、キモい。
>>486 バリデーションはこう実装すべきだという仕様を決めようとしている国際標準策定委員会だと
ユニークチェックもバリデーションの一種として含まれているぞ
といっても2015年ぐらいまではこの委員会もユニークチェックはバリデーションでやるべきではないって意見だったけどね
>>483 まじで？俺の開発環境だとテスト時のClass Not Foundも出力されるぞ？
といっても自分のバージョンはlaravel6での話だからlaravel8だとでないのかな？
>>484 djangoも確か結局全部消して作り直すのが早いって結論になってしまった気がするし、Laravelに限った話でもないような？
そもそもそんなエッジケースを挙げて、migration全然ダメて結論導き出せるのある意味凄いな。
なんとなく気づいた。
こんにちはっす。今日も予定開いちゃったので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のソースを読み込んでみましたが結構酷い作りですね・・
例えばどこ？
このフレームワーク、完全にcakeの劣化じゃん・・・
アンチオートインクリメントおじさん、Laravelくさすのが目的になってるから、だいたい針小棒大な欠点の指摘ばっかりになるし、他のフレームワークでもそうなっているってオチなんだよな。
>>491 地獄っていうほどの実装にはまずならないと思うけど、実コード見たいね。書いてるやつのスキルの問題な気がする。
気に入らないなら使わなきゃいいのに
>>498 まるで完全なauthとやらを知ってるかのような言い方だな。具体的にどういう仕様なら完全なの？
たとえCakeの劣化であっても、
Laravel使ってるとド素人認定されてバカにされる
わけわからん。
わりと
>>520 の意見って業界のスタンダードな意見じゃないか？
使うものでプロだとかそうじゃないとか一括りにするやつが一番の素人だと思う
その場合の道具とはエデイタなどのツールのことでしょ。建築の世界で言うと、フレームワークは、工法や造りに該当する。
Laravelはフレームワーク界のWordPressだからなあ
Laravelでwordpress実装してくれたら面白いのにね
WordPress
>>530 君みたいなプロフェッショナルは何を使ってるの？
Laravel使ってるっていうと恥ずかしいよな
何が悲しくてPythonでサイト作らないといけないんだよ
世界ではphp自体がもはや廃れていく方向
ここまで具体例の無い批判してて恥ずかしくねーのか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 検収することが煽りで筋が悪いってことか？
意味わかんねえんだが
で技術的負債がゼロの開発を教えてくれるか？
技術的負債の増加が早いことを指摘しているのに、他のやつのツッコミに対して技術的負債ゼロの開発を教えろやって言ってるあたり、読解力も底辺なのかな？
アホの集まりだな
あーコイツ、マジでオフショア開発やったことあるって嘘ついてるか、オフショア開発の一部の工程しか担当したこと無い感じか。
>>577 オフショア開発の一部工程しかやったことないのはお前だろ？
そりゃ一部工程しか関わってないときは俺もお前と同じ認識だったけど
オフショア開発全部に関わるようになった今は認識が違うんだよ
>>578 へー、お前も俺みたいに現地のCEOらと開発品質について議論したり、プロセスについて議論したことあるんだ？それなのに技術的負債の蓄積が早いという話は理解できないのか？マジで？
>>578 「オフショア開発全部」ってワードに
使い方合ってる様で気持ち悪い違和感感じるんだけど俺だこ？
俺だこって何だよw
この殴り合いの感じ、5chらしくていいね
元請けからしてみたらテストコードが網羅されていればソースの出来なんて全く気にしないんだがな。
すいません、
原因はバリデーションルールをいじったからだろ
>>589 registerControllerの中のvalidatorをいじったまでです。
そこが影響してるのかわかりませんが
authの中身見ても問題はなかったので
laravel のログインエラーに詳しい方いないかなあと。
正直全く理由がわからず手詰まりです。
>>588 おめえSVNかCVSでソースコード管理してないの？
>>591 SVNとかCVSはよく分かりませんがギット？は使ってます。
だったらログイン時にもそのコントローラー通ってるくらいしか考えられないでしょ
Eloquentとクエリビルダのget()の結果を扱うときに違いがあるのが気持ち悪い
あと、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で操作したとしてもコールバック内で同じ気持ち悪い感じになるんじゃないかな？
>>594 クエリビルダはハイドレート先のクラスが無いため、標準クラスとして返す。だから配列としてアクセスできないという身も蓋もない話なんだけど、まぁ確かに最初は気持ち悪く感じるよね。
ただ気持ち悪いからって理由でハイドレートするような処理を追加しちゃうと、結局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の悪夢がよみがえるから
おしまい
お前らどうした？
>>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のコードとヘルパすごい参考になりました。
お疲れ様です。
今の仕様だとハッシュの文字数分●が表示されてしまうのでおかしいです。
ハッシュ化しているのに元の文字列が復元できたら意味ないやんw
元のパスワードの文字数を別カラムに保存しておけば●の数を再現できるぞ
>>620 釣り？もしかして、「ポリモーフィック関連はアンチパターンである」を勘違いして、多対多自体をアンチパターンと勘違いしている？
そもそも●の数をハッシュ化前と一致させることに何の意味もないと思うんだが。プロフィール変更画面で●を並べるどころか、パスワード欄を空白にしてるサイトも結構あるはず。
ワイも登録されているパスワードを表示せず空欄でいいと思う
客に言われた通りの仕様しか作れない底辺が偉そうだなwww
アホか客に作らせた方が楽だろうが
仕様がクソだと実装もクソになりがち。クソな仕様を無くしてしまえば、実装コストゼロ。言われたままに作るのは3流。
アホか客のクソ仕様をそのままバカ正直にクソ実装するわけないだろ無能じゃないんだから
具体的な話が一切出ない言い争いしてるし・・・
アクセスログみたいな時系列データってどういう設計にしてますか？
>>633 多少ログが大きくなったりする場合はPHPだけでどうにかすることは難しいので
fluentdを利用してPHP側からはfluentdに投げるだけの仕様にして
その先の設計はまた別に考えた方がいいかもね
良くあるのがfluentd,Elasticsearch,kibanaでアクセスログ解析なんかは古典だけど
今でもアリなのでは無いかと
>>634 かなり昔fluentd,GigQuery,Grafanaって構成でやってみたことあったんだけど
その時の感想っていうか反応が
・完全にオーバースペック
・小回りが利かない
・ランニング思った以上にかかる
・費用対効果悪い
って散々な目に合ったトラウマがあって恐怖心しかないｗ
完全に自分の実力過大評価してたなーって今は思う
結局ランニングいくらなの？って質問に答えられるなら
あの頃の俺のリベンジをしたい気もする
どの程度で運用可能なのかね、実際
Apacheでaccess_logに吐くだけだわ
アクセスログってユーザーのアクセスログならGoogleアナリティクスだけど、バックエンド側のログのほうがほしいの？
DB使うならテーブルをログ取得用と集計用にわけないと、すぐ肥大化するよ
GAは使いこなせる人間がいないのと
>>641 いや今時Apacheなんて誰も使わないだろ
Apacheって3割ぐらいしか使われていないってシェアが発表されてた気がする
Apacheの新規導入はもはや少数派だと思うけど
Apacheでダメな理由も特にないからな
laravel動かすのにnginxはapacheの代わりにならないだろ
apacheの上位互換のサーバがあるなら使ってるかもしれないけど
よくわからないんだけどapache単独で使うのとapache+nginx使うのとでは
laravel6だけど環境回り何も変えていないのにcomposer install や update するとエラーが出るようになった。
>>647 Laravel+nginxで何が困るの？
twitter検索したら昨日くらいから似た症状の書き込みありますね、、、
>>650 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でどうのこうの言ってるような奴は
お前らえらそーに言うけどアホ面してcomposer updateとかコマンド打ってるだけだろ？
どうせメモリ足りないよエラーとか依存性のエラーとかだろ
>>672 bugだけでも36残ってるからどうにでも対応して直してこいよ
>>674 Issueが182も溜まってるって言ってんじゃん
バカなの？読めないの？
読めたらコメントしてこいよ
>>672 て思うやん？メモリ増やしても解決しねーんだわこれが
さてお前ならどうする？
>>675 愚直なのはいい事だと思うけど
目的地までの道は1本だけじゃないのよ
いつも使ってる道が工事中なら別ルート使うでしょ？
その別ルートをどれだけ知ってるかが経験や知識なのね
もう一度いうけど君は圧倒的にそれが足りないよ
多分まだ若いんだから先人達が書いた素晴らしいコードを何万行も読み込んで勉強しよう
呼吸する様にgithubのコードを読もう
そうすれば数年後には今の俺なんか目じゃないくらいのエンジニアになってるはずだから
composer使えないくんが発狂してissueの話を出してきて気持ち悪い
つーてもcomposerのソース読んだ奴なんてこの中におらんだろ
>>679 そうだねマニュアルで事足りるからコードを読んだことはないかな
それはプロジェクトに参加してる方々が色々考えて設計が行われたり
充実したマニュアルがある結果なんだよ
なのにそんな人たちの苦労も無視して何のリスペクトも無しに君は
> だからcomposer嫌いなんだよ
> もう何でもかんでもcomposerで入れるようになってるからcomposerが動かなくなったら詰むのに割とよく動かなくなって詰む
こう言ったんだよ、これってとても酷いことだと思わない？
そんな人にどうして対等に会話したいって思えるんだろう
もうこの件に関しては書き込まないから君の勝ちでいいよ
最後に君の言うたまたまがどの程度の事を言っているのかわからないけど
俺は少なくとも3桁回数はインストールしてるしライブラリ作って公開したりしてる
だけどインストールできない時に原因があるのは必ず自分側で
composer側の不具合だったことなんて無い
ここまで言ってわからないのであれば
この職業向いてないと思うから別の職業を模索した方が君の為になる
決断は早い方が選択肢増えるから一度考えてみてね
>>680 どう考えもcomposerの不具合だろ issuesにあがってるし
composerのバグのせいなのに会社や顧客は修正を待ってくれない
issueがーー！言ってるやつは具体的にどのissueがやばいの？
composer使えないくんの問題をエスパーするとlararelのバージョンは上げずに他のものだけバージョン上げようとしてるとかだろ多分
就職活動のバグのせいなのに親や兄弟は就職を待ってくれない
>>684 issueってのは、要望もあるけど大抵は利用者から見て謎エラーなわけ
別にどれがやばいって話じゃなくて「そもそも謎のエラーwなんて無いしw 」って言うなら全部解消して還元してやれってのが、OSS利用者ってもんでしょ
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 聞いてるか？壮大な前フリが投下されたぞ
安価も付けられない奴って普段から手動でやらなくていいこと手動でやってミスばかりしてそう
一体何なの？昨日からの流れは
composerのおかげで楽になったよ
symfonyは脱composerを目指しているみたいだけど
$curl- コマンドだけでインストールできると思ってたら
>>709 複数のlaravel動かしたい場合どうやってインストールするつもりだよw
composer自体はaptでもインストールできるよ
composerの役割を分かってないやつが居るようなw
symfonyはそういえばaptでインストールできたな
VagrantとDockerだとどっち使う事が多い？
Windowsで直環境 AWSのt2.medium
Docker良いね。逆にvagrantのメリットは？
Dockerはかなり前にWindowsに入れようとしてうまくいかなくて
>>716 面倒くさいからwindowsならvagrantの方が楽
homesteadあるし
MacだがVagrant+Paralles+CentOS7がお気に入り
WinでDocker Desktopてやつ使ったけど、重くて不安定でイマイチ
ただ一つだけ、シンボリックリンク張れないのだけなんとかならないすかね
あれ？Vagrantって言ってる人はhomestead？
>>723 Windows環境で/vagrant以下でシンボリックリンク張ろうとするとコケるのよ
コンポーサークソダーコンポーサークソダーコンポーサークソダー
windowsにvirtualbox+vagrantで作った仮想環境にDocker入れてLaravel動かしてる
>>727 特にない
Dockerの勉強したかっただけ
dockerの仕組みがいまいちわからないんだけど
開発環境作るだけなのに面倒くさいよな
vagrantならboxエクスポートするか
provisionの時スクリプトで入れたりする
>>730 構築にかかるコストを最初に払うかデプロイ時に払うかの違いかなーって思ってる
デプロイ時にミスった時の方が圧倒的にコスト上がるから俺としては助かってる
homesteadなら最初はboxのダウンロードなどに時間がかかるけど
DockerでOSごとイメージをAWSにデプロイするのがいいのか
スクリプト言語なんだから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じゃなくても良いんじゃないの？
>>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ってjavascriptっぽくなってきたよな
spring bootでlaravel書いたほうがいいような気がしてきた
>>765 それはspring boot以外知らないからそう思えるんじゃない？
いま世界で使われているフレームワークのシェアNo1がspring bootなんだっけ？
いいと言うよりオブジェクト思考で作るサービスを提供・利用するのに言語的にJavaが向いてて割と簡単に導入しやすいとか
JAVAが向いてる？
コンパイルは透過的に動くから気にせんけど
コードの野暮ったさを言ったらPHPが1番じゃないの
>>769 spring-boot-devtools使うとコード変更すると即座に反映されるぞ
これからLaravel使い始めようとしてるんだけどサラっとここ見たらハマりやすそうなフレームワークだね
ここでJavaの話を出してるようなKYは職場でもKYなんだろう
>>774 最近spring bootがphpの実行をサポートしたからじゃない？
すいません、プログラミング初心者です
javaスクリプトを使うと言うことまでは認識してるのですが、laravelのbladeファイルに書く場合は全てbladeに書いてしまって良いのでしょうか。
結局こういうのはjsで動的に切り替えるような作りにするのが一般的かと
求人とかで募集してLaravelできますとか言う人でたまにこんなのいるんだよな
なんでエンジニア界隈って、質問に答えずに自分の知識をひけらかしつつ嫌味を言う人しかいないんですか？
他人がわざわざ自分の時間を使って答えてくれているだけ有り難く思わないと
ネット上で質問する人は性格の悪いあなたに対して質問しているわけではないと分かった方がいい
スレ違いのセレクトボックスの質問を適切なスレに誘導するなら↓か
+ JavaScript の質問用スレッド vol.123 + [無断転載禁止]
http://2chb.net/r/tech/1491143438/ >>781 他の人も言ってるようにjavascriptでやる
>>781 スレ住人に効くようにうまいこと煽り続ければ誰かがここに答を書いてくれる
5chでテクニカルな質問しても意味はないよ
質問者はJSでやるのは見当ついててその上でLaravel的な作法を聞いてる
>>795 teratailとか
>>785 の典型だよな
まともな回答が来るわけない
見ててイライラするサイト
Laravelは関係ないけど
jsの知識なんて要らんだろ
teratailとかQiitaに誘導するのは意地悪すぎるｗ
>>799 webでjavascriptの知識無しの人材なんて仕事にならんよ
趣味でやってるだけなら別にどうでもいいけど
初心者としか書いてなくてレベル感が全く分からないからなあ
>>800 5chで聞くよりはまだマシだよ
ここで答えが得られることはまずないが、teraとかならまだある
もっとマシなところがあるならそこに誘導してやりなよ
Laravel8＋JetstreamでReactって使えないの？
>>804 ぐぐってteraがよく出てくるけど質問が解決していたこと一度もないぞ
>>804 マジレスするとstackoverflowしかないな、本家の方な
俺はそこで解決しなかったら諦めて客に仕様を変更する相談するようにしてる
>>806 いくらなんでも言い過ぎよ
すべて解決はもちろんないけど、中には解決してるもんもある
>>807 そもそも本家で質問するレベルの人はこんなところで質問しないわな
初心者なら一番いいのは金払って教えてもらうことだな
それいいな
laravelできますって言えるレベルってどの程度なの？
本まるっと一冊書けるくらいなら言っても良いと思うよ
>>811 laravelの開発者に貢献できるようなコミットができるぐらい
>>814 ありがとう
こういうネットに落ちてるのをホイホイ使っていいものか…でもまあ自分で作るのと大差ないかそれよりマシか
５chで質問するならまともな回答が得られなくてもかまわない覚悟が必要
1つ質問すると10の説教が返ってきて結局何一つ情報を得られないのがプログラミング界隈
何事も使い方次第よ
だから信頼できる情報を得たいなら対価として金を払いなよ
そもそもここは質問スレではない
質問したけど自分が求めていた回答と違うから
>>783 に割と具体的に書いてるのにこれで理解出来ないならプロで仕事は無理やな
プログラマー如きが「プロで仕事」て
Livewireってやっばり遅い？
>>837 作りによるとしか
結局あれって状態変わるごとに裏で非同期通信して、サーバーサイドから差分のDOMを受け取って差し替えてるだけなので、
下手な実装してしまうと重く感じるかもしれない
ただフロントのライブラリが少ないから(alpine)
ケース次第ではvueより実装コストがかかる
試しにLivewireで1サイト作ってみたんだけど
こんな流行りそうにないの使うならVueの方が後々楽かと
Bladeって、Laravel使わなくっても使えるの？
twigよりbladeの方が好きな俺は異端か
bladeでforeachで回してる要素に対してjquery発動することは可能ですか？
うまく返したつもりなのか本当にPHPだと思っているのか
>>843 foreachで回してphpゲージが溜まってきたら特殊コマンドでjquery発動できるよ
composerでlaravelのプロジェクトを作成しようとしているんですがzip解凍するツールねーぞって
怒られてるメッセージを貼ってみてよ
必須ではないと思うけどその後書き込みないから解決したんじゃね
laravel関係ないですけど
>>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 あなたの考えるセキュアとセキュリティってそれぞれ何を指してるの？
すいません、質問です
今のところ画像アップを完全に枠外に表示すれば、画像をアップした後でそれを含めて個人情報登録、みたな処理ができるんですが
すいませんもう少し分かりやすく言い換えます
すいません、自己解決しました。
>>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')を取得する方法をご教授いただきたくお願いします。
通知メールを日本語化しようと、Notificationを新たに作ってオーバーライドしたら
それくらいのことで苛つくなら、そもそも合ってない
> それくらいのことで苛つくなら、そもそも合ってない
ググってもオーバーライドするやり方しか出てこず
マニュアル読んだ？て質問に対して、ググってもーて返事しちゃうのか
>>916 マニュアル読んだ？＝マニュアルに書いてあるよ
って読み取れるかどうかはコミュ力なのかなんなのか
あ、オーバーライドじゃなくてvendor:publishして直接編集したいって話か
>>919 すいません、既に解決しました。
php junkieってブロガーの人が唯一、元のファイルの場所を書いてくれてました。
且つ、直接編集せずにja.jsonに訳を書くだけでいいって教えくれました。
神です
notificationとブレードを新たに作ってガチャガチャやるやり方も一応惜しいとこまで行ったけど
>>921 あ、そうなんだ
それなら上で紹介したマニュアルで十分だったか
今後はマニュアルを先に確認するよう
癖をつけとくと良いよ
便利なツールがあふれ速くものが作れるようになった
>>923 調子に乗らないでください あなたもわからなかったくちですよね？
>>928 わからなかったひとを煽るためのレスでしょ？
>>919 でアドバイスしてた俺に言われてもお門違いとしか思えない
>>929 東大卒新垣結衣似彼女持ちの俺もそう思う
普段Safariの有料の拡張機能で黒白反転させて開発してるんだが
お題きましたよ
>>933 Laravelのエラー画面のデフォルトは白だが
Safariの拡張機能使ってもそれだけ色が変わらなくてウザいって話
俺が言ってんのは
Laravelの画面が真っ白ってそれPHPがエラーはいて真っ白になっているだけでは？
CSSの組み方が特殊なのかね？
そもそも真っ白な画面ってlaravelがまともに動いてないでしょ
そんなもの使って開発するな
先週からLaravelを触り始めましたが新規登録と更新でまったく同じバリデーションの場合
同じなら分ける必要ないのではないかと思うけど実践でLaravelを使っている人たちの意見を聞きたいところではありますね
>>940 問題が起きにくいのは分ける方式だぞ
トランザクションとしては異なるので仮に記述が同じでも別物として扱う
Laravelで作られた有名どころのOSS見たけど全部そうなってた
>>940 この辺の質問されたらいつも
フォームリクエストの名称何にする？って聞いてる
例えばUserCreateFormRequestっていうならそれが答え
UserFormRequestっていうならそれもまた答えだと思う
どう設計するかによって変わると思う
>>943 そもそも同じフォームリクエストを使うというのが間違い
バリデーションが同じであろうがフォームリクエストは分けるべき
>>943 意識高い系ぽい回答で笑ってしまった
それだと設計上のメリデメを答えてないから
何か言ってるようで何も言ってないじゃん
>>945 確かに読み返してみたらかなり偏差値低そうな中身ゼロのレスだった
恥ずかしいから無かった事にして・・・
でも一個だけ言い訳させて
酔ってた
初心者だけどhttps化したいけどhttpでaccessできちゃうし、httpsでaccessしても最後に/がつくとhttpになっちゃうんだけど原因ってなんだろ?
>>948 初心者ならできる人に頼め
普通はrewriteで対応するけどやり方はインフラによる
laravel初心者です
>>951 ありがとうございました！助かりました！
追加で質問すいません
hasManyでリレーションしているテーブルに対してwithをつかったデータの取得がうまくいきません
原因は何でしょうか？
・リレーション
A-Bは1対多
・やりたいこと→Ａの値と、それに関連するＢのIDのみを取得
Ａ::with(['Ｂ:id']);
・結果
Ａの値のみ取れて、Ｂの値が空っぽ
・補足
なぜか「Ａ::with(['Ｂ']);」だとデータは取得できるようです
もうここまでくると『生SQL書いてた時代の方がよっぽど平和だったな…』ってなるわ。
>>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ロード」の項目の
ありがとうございます！
6の本買ってずっと放置している（知識は5で止まっている）のですが、
>>965 本はでるかもしれないけど、あなたはきっと読まないでしょう
>>968 毎週8のアップデートに目を通しているやつなら
9が来てもそんなに変わったとは思わんだろうね
symfonyが変わるにしても、
速度気にする人はそもそもlaravel使ってないだろう
RDBMSつかうなら大半待ちで変わらなさそうだけど
言語を変えろって行きすぎじゃね？
まぁ普通に
>>977 だよね。高いサーバーてかアプリケーションサーバーの台数増やすって話。
速度のためにDX犠牲にするって発想は、今の時代に合わない。
イベントとキューってどうやって使い分けるんですか？
キューは非同期処理
artisanファイルって本番環境ではやっぱり削除しといたほうがいいのかな？
9のリリース日まだ決まってない？1月中に出るんだろうか
>>984 仮にアクセスできたとして何が問題なの？
アクセスした人間に実行権限が与えられるとでも？
むしろ心配すべきは.env覗きみられることじゃね？
>>983 ありがとうございます
イベントで非同期になる場合ってないんでしょうか？
>>984 マイグレーションとかタスクスケジュールとかどうやるつもりなのか
Laravel遅すぎるからCodeIgniterにする
公認会計士とwebエンジニアならどっちがウマミある職業ですか？
>>990 プロファイラでどこが遅いかしらべた？
Builderとか特定のどこが遅すぎるか知りたい
まーI/OかGILで待ってるかアルゴリズム悪いだけだろうけど
会計士の方が一生稼げるけど、うっちゃけ金の計算ばかりの仕事面白いんかな
>>992 調べたというより世界中で調査してるからそれを見たらLaravelが一番遅くて萎えた
>>993 会計士は稼げるけど、独立しない限り労働環境ブラックだぞ
エンジニアは内製しているそこそこのweb系起業ならかなりホワイト
>>996 ベンチマークにモチベーション求めるエンジニアもいるからただのバカではないかもしれない
ベンチマークフェチの変態エンジニアの可能性もある
このスレッドは１０００を超えました。
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
このスレへの固定リンク： http://5chb.net/r/php/1625721320/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「【PHP】Laravel【フレームワーク】 Part.8 ->画像>1枚 」 を見た人も見ています：・国民民主党→山尾玉木の駆け落ち新党 党内政局総合スレッド87 「データセンター」がゴミ処理場と同類の「迷惑施設」と化している 「建設強行」に住民が反発 ★2 [蚤の市★] 【滝沢充子】のん part903【神崎将臣】 【星ドラ】都道府県鍵提供スレ★57 健常者はホモ(精神病患者は普通) 【韓国】まともな国産ロボットは産業用機械と掃除機だけ 世界１位のロボット王国「不都合な真実」 NHK総合を常に実況し続けるスレ 180758 おはよう 平手友梨奈が厨二病じゃない世界線にありがちなこと 情熱大陸【菅田将暉】 【衰退国】円安はもはや「日本の実力」 競争力の落ちた日本にはマイナス面のほうが大きい…長期の円安に備え国内市場の整備を★３ [ramune★] THE WILLARD／part52 【皇室】皇后雅子さま、はじめてたったおひとりで公務に臨まれる 小中学生の膨らみかけのおっぱいwwwwwwwwww 【速報】とんでもなくスケベな身体をした素人女を発見したのやが 【野球】阪神 ドラフト１位は当日決定 矢野監督「想像して書いたほうが楽しいやん。宣言するより」 いもうとシスターズ Part14 【SV＝退職者製造機】ベルシステム24札幌 PART19 【画像】男さん、電車の中で葉巻を吸ってることを咎められブチギレてしまう [324064431] 検査拒否、入院拒否して何が悪いの？人権考えろよ [999127778] 高収入なのに結婚してない特徴 honto（旧bk1）のあしあとポ.イ.ン.ト.が大改悪で俺涙目(´；ω；｀) [262911309] 【朝日新聞】（社説）政権中枢襲撃 許されぬ政治への暴力 [香味焙煎★] 【日刊】11月24日今日はどんな日 誕生日 山岸理子（98年つばきファクトリー） 元厚労省官僚が警鐘「ワクチン接種期に震災以上の超過死亡」政府やマスコミが黙り込む"不都合な真実" ★14 [Stargazer★] 新・ゲーム総合ランキングスレ 1757位 【韓国経済崩壊】90年以降に生まれた若者は将来年金を受けられない [動物園φ★] コナミ50周年記念アーケードクラシックス、悪魔城ドラキュラ、魂斗羅コレクション発売決定！ ●▲北海道の自作ｼｮｯﾌﾟ事情▲●Part229 （ ヽ´ん`）「駐車場で俺の車だけ曲がってるな・・・・」 [333352723] ものすごくタイプな女の子の画像をUPするスレPart152 任天堂「儲からない3DSの修理辞めたわｗ」 ソニー「まだまだ遊べるPS3のアップデート行います！」 中外テクノスってどうなの？ PART11 【完全オワコン】詐欺師ヒカルpart316【ゴミ動画毎日投稿】 専修大学part253 【千葉】千葉競輪、「廃止」からの大逆転 企業（日本写真判定）負担で多目的施設に 日テレ読売情勢調査自民単独過半数割れ、立憲共産維新上積み、社民れいわ国民±0、N国0議席 映画「ゴールデンカムイ」アシリパの父・アチャ役は井浦新 [少考さん★] 今日大阪でデモやってたみたいだけど日本でやる意味あんの？ 【テレ朝】プーチン大統領は「年明けにも辞任」ロシア政治学者が政府関係者から聞く「北方領土問題での進展が期待」学者発言 [どこさ★] 【日本史】クローン技術で古代日本人縄文弥生復活 NHK BS 13576 【野球】ヤクルト・村上(19）が２４号３ラン、８月は６戦４発 3打数1安打3打点 103試合 .227 24本 76打点 3盗塁 真夏の夜の淫夢 [775658677] 【社会】「どこつかんどんじゃコラ、ボケェ」に「おい、ヤクザ」の応酬 大阪機動隊員の沖縄「土人」発言のガラの悪さ ★４ 【みんゴル】カジュアルツアー募集スレッド Part3 【モーニング娘。17期】 井上春華ちゃん応援スレ 京都之47 【はるさん、はるしゃん】 【集合】なんJGoToイート部 トランプ氏、日本製鉄のUSスチール買収計画巡り再審査を指示 [蚤の市★] 巨専】★2 韓国ガールズグループ雑談スレ★261 豆腐の愚痴吐きスレ ★3 【国際】安倍首相「日韓両国は戦略的利益を共有する最も重要な隣国だ」 文在寅氏にお祝いのコメント ★3 【朗報】メルカリに福島産の桃が〝訳あり品〟として大量に格安で売られる [324064431] 特価品6612 【速報】週刊朝日。自民党100議席減の180議席 緊急情勢調査に安倍官邸衝撃 「地方でここまで印象が悪いとは…もう末期症状だ」 [535898635] ドラム式洗濯機 PART86 実況 ◆ フジテレビ 88621 ラブドール ロリ系総合4 ©bbspink.com ラブドール ロリ系総合5 ©bbspink.com 百田尚樹、大嘘つきのクソ野郎だった 清水郵便局 初心者優先デジタル一眼質問・購入相談室 97 広河隆一氏が元発行人「デイズジャパン」破産申請 性暴力などの損害賠償で 【恒例】日本のゲーム業界人が決める今年のベストゲームは？ 日向坂2nd「ドレミソラシド」がキュンと比べて完全にコケてるんだが、誰の責任だよ？？？？？？
ブックマークへ