私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】Laravel【フレームワーク】 Part.6
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
おまえら昔は大手にいたかもしれんが
最近のシステムを触ってないでしょ?
どんどんリアルタイムに変わっていってるのに
そもそもサーバにクレジットカードの情報があるようなシステムは違法だぞ
最近のシステムを触ってないでしょ?
どんどんリアルタイムに変わっていってるのに
そもそもサーバにクレジットカードの情報があるようなシステムは違法だぞ
客の基幹システムが古いんだから仕方ないじゃん
こっちは頼まれた通りに作るだけだよ
こっちは頼まれた通りに作るだけだよ
なにそのキチガイな設計、頭だいじょうぶか?
普通にリクエスト受けたらCSV生成してダウンロードさせたらええだけやん
普通にリクエスト受けたらCSV生成してダウンロードさせたらええだけやん
>>398
バッチ処理書いたことない人だったか
バッチ処理書いたことない人だったか
>>408
そうそう。荒らしね。知識なくて話に加われないなら黙ってりゃ良いのにといつも思うわ。
そうそう。荒らしね。知識なくて話に加われないなら黙ってりゃ良いのにといつも思うわ。
反論したくなるギリギリの外し方は上手いと思うから知っててやってるんじゃないかと予想した
でも、あんまり知識レベルは高くないと感じるから
いくつもやってたら無知が故に画期的なアイデアを書くかもしれない
がんばれ
でも、あんまり知識レベルは高くないと感じるから
いくつもやってたら無知が故に画期的なアイデアを書くかもしれない
がんばれ
俺の会社は>>379で書いた通りの方式だからバッチ処理はないな
上位システムでは何かやってるのかもしれないけど
上位システムでは何かやってるのかもしれないけど
バッチ処理をどうやるかって話をしているのに
わざわざ「俺の会社ではないな」とか書いてくる奴ってガイジなのか?職場でもそんな感じで会話してるの?
わざわざ「俺の会社ではないな」とか書いてくる奴ってガイジなのか?職場でもそんな感じで会話してるの?
死語な感じするけどキョロ充ってやつじゃないの
とにかくハブられないために情報量ゼロでも何か発言せずにはいられないんだろう
悲しいね
とにかくハブられないために情報量ゼロでも何か発言せずにはいられないんだろう
悲しいね
バッチ処理は必要だしみんなしてるよ
スレ読んでて何故それが未だにわからない?
スレ読んでて何故それが未だにわからない?
>>416
バッチ処理ってどれを想定してるかで答え変わるんじゃないかな?
ちなみに俺は6番だと思ってる
1. 時間のかかる処理をする事
2. 非同期で処理をする事
3. 複数の処理をまとめた機能
4. 定期的に行う処理の事
5. コンソールから行う処理の事
6. Batchableジョブの事
バッチ処理ってどれを想定してるかで答え変わるんじゃないかな?
ちなみに俺は6番だと思ってる
1. 時間のかかる処理をする事
2. 非同期で処理をする事
3. 複数の処理をまとめた機能
4. 定期的に行う処理の事
5. コンソールから行う処理の事
6. Batchableジョブの事
>>419
HTTPリクエスト以外からのlaravel処理起動ってことだ。
バリデーションをHTTPリクエストしか想定してないところに書くのがどうなの?って話になって、例としてバッチはどうするの?って話になって、バッチを知らない馬鹿が騒いでるのが今の流れ。
HTTPリクエスト以外からのlaravel処理起動ってことだ。
バリデーションをHTTPリクエストしか想定してないところに書くのがどうなの?って話になって、例としてバッチはどうするの?って話になって、バッチを知らない馬鹿が騒いでるのが今の流れ。
サーバ内部からアクセスできないようなコントローラを作って
そいつに対して別システムからもらったCSV等のデータをPOSTしたりとかするようにすれば
FormRequest使えるのでは?
そいつに対して別システムからもらったCSV等のデータをPOSTしたりとかするようにすれば
FormRequest使えるのでは?
>>422-423
あれ?話がループしてね?
あれ?話がループしてね?
書くの忘れてた
バリデーションをHTTPリクエストしか想定してないところに書くのがどうなの?
って部分に関してはバリデーションの対象が「リクエスト」なのでFormRequestに書くべきだと思う
FormRequestを使わない処理に対してのバリデーションは必要があるなら処理単位で書くべきと思ってる
バリデーションをHTTPリクエストしか想定してないところに書くのがどうなの?
って部分に関してはバリデーションの対象が「リクエスト」なのでFormRequestに書くべきだと思う
FormRequestを使わない処理に対してのバリデーションは必要があるなら処理単位で書くべきと思ってる
FormRequestを継承したクラスをnewしてそれのrules()で取り出したルール使いましょうよ
このスレでは行間読んでもうバッチでいいけど、
個人的にはバッチって表現とLaravelのバリデーションを紐づけるのは違和感あるよね
Laravelのドキュメントの中でバッチって使ってたりするか?
個人的にはバッチって表現とLaravelのバリデーションを紐づけるのは違和感あるよね
Laravelのドキュメントの中でバッチって使ってたりするか?
>>431
バッチって定義はないけど、cursorやchunkメソッド、lazy collectionなんかは大量データを一括で処理するためのものだよね。
バッチって定義はないけど、cursorやchunkメソッド、lazy collectionなんかは大量データを一括で処理するためのものだよね。
こんなんで言い争いしてるのを見るとわかる通り
laravelはダメなフレームワークです。
laravelはダメなフレームワークです。
バッチの定義がおっさんと若者で違うんだろうか
でもこんなスレでそう結論付けてはいかん気がする、異常者が集まっている
でもこんなスレでそう結論付けてはいかん気がする、異常者が集まっている
>>429
それやった段階でルールがどこで使われてるかが追えなくなっちゃうから
のっぴきならない事情でそのルールを変更せざるを得なくなった時に
影響範囲が全くわからなくて予想外の不具合起こしかねないからやりたくないのよね
チーム開発とそんな変更受けちゃダメってのは無しでお願いします
それやった段階でルールがどこで使われてるかが追えなくなっちゃうから
のっぴきならない事情でそのルールを変更せざるを得なくなった時に
影響範囲が全くわからなくて予想外の不具合起こしかねないからやりたくないのよね
チーム開発とそんな変更受けちゃダメってのは無しでお願いします
Laravelは独自の用語が多いから単語本来の意味と違ってたりして話がややこしくなる
そういう所は嫌い、というか普通にバッドプラクティスだろそれ
そういう所は嫌い、というか普通にバッドプラクティスだろそれ
>>438
サービスって単位での使いまわしはするけど
基本的にクラス単体を複数個所で利用するって事はしてないな
当然共通処理って部分での使いまわしは当然あるけどabstractでやってる
実際に使う場合はサービスプロバイダで必要なインターフェースが実装されたクラスをbindして
コンテナから呼び出して使ってる感じ
このやり方が全くの見当はずれだったりアンチパターンとかだったりしたら早急に修正しなきゃいけないから変だったら言って欲しいのよね
サービスって単位での使いまわしはするけど
基本的にクラス単体を複数個所で利用するって事はしてないな
当然共通処理って部分での使いまわしは当然あるけどabstractでやってる
実際に使う場合はサービスプロバイダで必要なインターフェースが実装されたクラスをbindして
コンテナから呼び出して使ってる感じ
このやり方が全くの見当はずれだったりアンチパターンとかだったりしたら早急に修正しなきゃいけないから変だったら言って欲しいのよね
>>440
プロジェクトの規模にもよるけど俺のほかに2人で外部に必要あればちょいちょいって感じ
設計とかインターフェースの部分の開発をやってもらう場合は確かに人が集め難いとは思うけど
どちらかっていうと能力が低くても依頼可能にしたかったからこうしてるんだよね
とはいえメソッドチェーンってなんすか?レベルまではカバーできないけど
プロジェクトの規模にもよるけど俺のほかに2人で外部に必要あればちょいちょいって感じ
設計とかインターフェースの部分の開発をやってもらう場合は確かに人が集め難いとは思うけど
どちらかっていうと能力が低くても依頼可能にしたかったからこうしてるんだよね
とはいえメソッドチェーンってなんすか?レベルまではカバーできないけど
>>441
.envをコミットするかしないかで延々議論していたころに比べれば健全だろ
.envをコミットするかしないかで延々議論していたころに比べれば健全だろ
・.envはコミットする必要がある
・/vendorはコミットする必要がある
・バリデーションルールはモデルに書くべき
・テストを書く必要は無い
・いかなる場合もバッチは必要無い
・jsonは脆弱性があるので使うべきではない
・/vendorはコミットする必要がある
・バリデーションルールはモデルに書くべき
・テストを書く必要は無い
・いかなる場合もバッチは必要無い
・jsonは脆弱性があるので使うべきではない
>>404
ネタにマジレスして悪いがその処理だと要件満たしてないw
ネタにマジレスして悪いがその処理だと要件満たしてないw
>>404
1は会員登録および退会の時刻を見ればいいだけだから別に0時に処理する必要はない
2はテーブルに持つべき値ではない
3も同様
磁気テープの時代ならともかく、値を取得を得られるまでの期待値が0.1秒未満の今の時代に
なぜバッチ処理をするのか?
レスポンス改善の為にあらかじめCSVを作成して静的に配置しておくっていうならともかく、そういうわけでもないようだし・・・
1は会員登録および退会の時刻を見ればいいだけだから別に0時に処理する必要はない
2はテーブルに持つべき値ではない
3も同様
磁気テープの時代ならともかく、値を取得を得られるまでの期待値が0.1秒未満の今の時代に
なぜバッチ処理をするのか?
レスポンス改善の為にあらかじめCSVを作成して静的に配置しておくっていうならともかく、そういうわけでもないようだし・・・
類似してるかもしれないスレッド
- 【PHP】Laravel【フレームワーク】 Part.9 (884) - [98%] - 2022/3/13 12:00
- 【PHP】Laravel【フレームワーク】 Part.8 (148) - [98%] - 2021/8/8 21:30
- 【PHP】Laravel【フレームワーク】 Part.7 (779) - [98%] - 2021/7/9 16:18
- 【PHP】Laravel【フレームワーク】 Part.5 (568) - [98%] - 2021/5/1 22:00
- 【PHP】Laravel【フレームワーク】 Part.12 (314) - [96%] - 2023/1/30 18:45
- 【PHP】Laravel【フレームワーク】 Part.3 (983) - [96%] - 2021/2/12 4:00
- 【PHP】Laravel【フレームワーク】 Part.10 (446) - [96%] - 2022/6/6 19:30
- 【PHP】Laravel【フレームワーク】 Part.11 (870) - [96%] - 2022/8/28 15:45
- 【PHP】Laravel【フレームワーク】 Part.4 (460) - [96%] - 2021/4/4 4:00
- 【PHP】Laravel【フレームワーク】 Part.2 (917) - [96%] - 2019/9/10 9:15
- 【PHP】Laravel【フレームワーク】 (887) - [84%] - 2019/4/23 21:00
- 【PHP】フレームワーク Akelos (129) - [56%] - 2019/5/9 7:46
トップメニューへ / →のくす牧場書庫について