【PHP】Laravel【フレームワーク】 Part.5
レス数が1000を超えています。これ以上書き込みはできません。
テンプレ追加修正お願いします
Laravel
ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
日本語
http://laravel.jp/
書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)
※前スレ
【PHP】Laravel【フレームワーク】 Part.4
https://medaka.5ch.net/test/read.cgi/php/1613209188/ おっす！ 腹痛くて起きた。酒飲みすぎ、ダメ。
>>480
> Laravelのソース何か見ても理解できる訳が無いやろｗ
>>482
> お前のほうがむしろ古臭い考え方だぞ。環境に依存した設定は本来コードから切り離すべきってのが今の主流。dotenvはそれに沿った仕組みだよ。
なわけねぇだろ。見りゃわかるよ。だから『下等な作り』っつってんじゃん。
あのな、書いたとおりまだ.envどうやって読み込んでんだかコード見てねぇから詳細はしらんけど、
設定は$_ENVスーパーグローバルにつっこまれてて、env("hogehage") とか下駄関数使って取得するんだな。
https://readouble.com/laravel/8.x/ja/configuration.html
なんすか？ これ、みたいな。
まず、『今どきグローバル関数っすか？』みたいな。
関数定義場所はhelpers.php、『ヘルパー』なのな、これ。中見るとEnvクラスの静的メソッドのラッパになってる。
『なんでこんな事になってんだい？』と思ったら、恐らく、旧バージョンとの互換なんだろうな。
で、$_ENVって、『連想配列』な。つまり、『変数』な。
あのさぁ、PHP本体のスーパグローバル、汚染する？ 普通？
それでさぁ、『環境』に関する定義、を『変数』に突っ込む？『定数』にしねぇ？ 普通。
変わったら困るし、変えられたら尚困るじゃん。
定数の方が明らかにアクセス速度も早いしさぁ。
もう、しょっぱなから全然ダメ、Laravel。 >>492
そんな仕組みになってない
せめてドキュメントにあることぐらい理解してから煽れアホ で、
> 環境に依存した設定は本来コードから切り離すべきってのが今の主流。
だけど、今の主流っていうか、遥か太古からそうだよ。
そういう話じゃなくて、すげぇ簡単に適当にコード書くと、
class Env {
public static function set(){
$env_file = "/file/to/environments/.env_" . self::which_env();
if(! file_exists($env_file) ){
throw new \Exception("ねーよ");
}
self::register($env_file);
}
private static function which_env(){
$toriaezu_saba = $_SERVER["SERVER_NAME"];
switch(true){
case $toriaezu_saba = "本番環境": return "product";
case $toriaezu_saba = "おれ.の.IP.アドレス": return "oredayo";
default: return "develop";
}
}
}
みたいにして、（いいか？ 繰り返し言うけど、上のコードは今適当に書いただけだからな？）
/file/to/environments/
├.env_product
├.env_oredayo
├.env_omaedayo
│ ：
└.env_product
な感じにしとけば、コミットしようがしまいが関係ないじゃん、って話。
だから『Laravelは下等な作りになってんなぁ』って言ってんの。 >>492
本当にやべーなコイツ。環境変数で受け取るって主流のやり方を全否定してやがる。12factor.appぐらい読めよ。環境によって異なる設定をお前はコード内で定義すんの？環境増えたらどうすんの？コード内で分岐増やすのか？
あとenvヘルパはLaravel固有のファサードによるアクセスを簡易にできるようにラップしたものだぞ。古いバージョンとの互換性とか見当違いも良いとこ。ファサード批判なら分かるがヘルパ関数否定するのは意味不明。
さらに定数にしろって話も、何も分かってないの丸分かり。L aravelの場合、環境ごとに自由に値を切り替えられるようそういう作りになっているが、速さについてもconfig:cacheによって担保されている。
単にお前が無知で全然ダメってだけ。 >>493
書いてあんじゃん。引用したじゃん。おまえ、馬鹿じゃん。
で『どこがどう認識違ってる』って言えばいいだけじゃん。
やっぱおまえ、馬鹿じゃん。 >>496
> .速さについてもconfig:cacheによって担保されている。
だーめだ、このポンコツ頭。
おまえの言ってる『速さ』って、一体何の速さの話だ？ >>496
> 環境によって異なる設定をお前はコード内で定義すんの？環境増えたらどうすんの？【コード内で分岐増やすのか？】⇠
脳みそくさってんなぁ…。
ここも、設定ファイルに切り出すに決まってんだろ。
で、それを読み込んで『自動分岐』
おれ、書いたよな？ （いいか？ 繰り返し言うけど、上のコードは今適当に書いただけだからな？）って。
おまえ、本当にプログラマか？ アマグラマだろ。 >>496
> あとenvヘルパはLaravel固有のファサードによるアクセスを簡易にできるようにラップしたものだぞ。古いバージョンとの互換性とか見当違いも良いとこ。
しらねぇよ、そんなもん。言ったじゃん、昨日初めてLaravel入れてみたって。
でさ、そんな事どうでもいいって事すら、理解出来ん？
おれが問題だっつってんのは、
『今どきグローバル関数っすか？』みたいな。
env()とかconfig()とかの事な。
グローバルスコープ名前空間で定義すんなよ、ってのが、
今のPHPに限らず『あらゆる言語』での『常識』。
だから『PHPerはダメだ』って言われんだよ。 特に >>496 の脳みそが腐ってんのは、
おれが何故上のコードを書いたかというと、
『.env をリポジトリにコミットする馬鹿がいるから』って前提条件があるって事を、
完全に忘れてんのな。
もう『お前、ニワトリだろ？』みたいな話。 https://readouble.com/laravel/8.x/ja/configuration.html
> 機密性の高い資格情報が公開されるため、侵入者がソース管理リポジトリにアクセスした場合のセキュリティリスクになります。
言ってる事、わからなくもないけどさぁ…、
それ、別のところのセキュリティを心配しろよ…、みたいな。
それは .env をリポジトリに含めるかどうかって話とは、全く関係ないだろ、みたいな。
レベル低い会社だと『セキュリティの為、変数名と関数名は連番にしてくださいい』みたいな会社が『平成の後半に入るくらい』までは、
あったらしいけどさぁ…、
『おまえ、着目点、おかしいだろ？』みたいな。 laravelの.env関連がオブジェクト思考な作りになってないって言いたいだけか。
話が長い。まわりくどい。無駄に人格否定しすぎで批判君の話を聞こうと思う人を減らして批判君は損してるね。
批判するために批判するのが目的でないなら、批判君の理想の作りに変更してlaravelに採用してもらってみなさい おれ様w仕事何してるの？w
どうせ無職ニートなんだろうけどw >>501
君が言う問題を要約すると「関数をグローバルに使えるか」が焦点なの？
その仕様が糞かどうか以前に、それがphpの言語仕様だからLaravelはあんまり関係無いな。cakephpにもグローバルに使える関数は存在する。
phpは元々オブジェクト指向の言語ではないし、そこを気にするならLaravel以前にphpが糞ってことで使うのを辞めたほうがいいよ。 >>501
間違いを指摘されて「俺は初心者だから仕方ない」「そこは論点じゃない」
w > env()とかconfig()とかの事な。
グローバルスコープ名前空間で定義すんなよ、ってのが、
> 今のPHPに限らず『あらゆる言語』での『常識』。
それが良い悪いはともかく、
多くの動的型付け言語、いわゆるスクリプト言語ではグローバルな名前空間で関数定義可能だけどね
つーかもはやlaravel関係ないし javascriptやPHPの歴史を知らずクソとかいう奴と同レベルだな .envの仕組みはLaravelオリジナルじゃなくてphpdotenvってライブラリから提供されるものだからLaravel関係ないぞ
提案があるならこっちのissuesに書いてくれば？
https://github.com/vlucas/phpdotenv > で、$_ENVって、『連想配列』な。つまり、『変数』な。
あのさぁ、PHP本体のスーパグローバル、汚染する？ 普通？
$ENVに詰め込んでるのはLaravel関係ないぞ
てか君、文体からして>>210と同じ人でしょ ほんとだサロゲートキーおじさんがLaravel使ったこと無かったのと、「だーめだこりゃ」の口癖が一致してる。
恥ずかしくなって逃げたと思ったけど帰ってきたんだね。
そろそろ63bitのbigintをオートインクリメントで埋めることは叶いそうかい？w サロゲートキーおじさんは$_ENVを汚染するなおじさんに転職したのか
呼びにくいからサロゲートキーおじさんのままでいいよ あ、コイツあれだ。前にORM自作しててLaravel使ってないとか言ってたやつだわ。>>511が正解だな。 アンチオートインクリメントおじさんまとめ
・Laravel使ってないのになぜかLaravelスレで偏った主張を繰り広げる
・サロゲートキーにオートインクリメントを使うのはアホ。なぜならint型なのでオーバーフローするから。
・bigintを知らない。その証拠に922兆をunsignedと決めつける謎の主張をして周りを混乱させてる
・Laravelと直接関係ないdotenvの仕組み(symfonyで取り込まれた)を根拠にLaravelは下等だとのたまう
・環境ごとに分岐するクソみたいなサンプルコードを書いたあと、あれは適当に書いただけで本当は自動分岐だからて言い訳する
・グローバル関数使ってる言語やFWはありえないらしい
・環境変数に値を設定するとPHP本体のスーパーグローバルが汚染されるという謎の主張を繰り広げる >>515
単位を京と書くところ間違って兆にしてたわ。訂正。 まぁ、あんまり922京をunsigned(64bit)と間違えたことを指摘すると揚げ足とってるみたいだからそこは触れないにしても、
仮にそれを半分のsigened(63bit)にしたって461京あるんだが、
それを100年間かけて枯渇させるには1日あたり126兆件のレコードを挿入する必要あるんだよね。
・利用者世界規模のエンタープライズシステムを作ってる
・bigintという概念を知らなかった初学者
どっちだ >>480
laravel/uiのソースくらいから読むと色々勉強になるがね >>519
126兆件/日＝30万件/秒だぞ
仮にそれだけの利用機会があっても現代のマシンでは性能が足りないな >>519
まぁ普通はそこで揚げ足とりなんてしないけど、彼の場合unsignedだと決めつけてそれを根拠に更に謎理論を展開した挙句人格攻撃までしてたからね。慈悲は無い。 まったく、お前らみたいな低レベルは話の焦点が理解できんみたいだから会話にならんな。 『慈悲は無い』って、バカかと。
お前に無いのは『知能』だろと。 『Laravelのソース何か見ても理解できる訳が無い』レヴェルの集まりだからな。
話が合うわけがない。 このヴァカ、まだ日本語読めずになんかホザいてるし。
525nobodyさん2021/04/30(金) 10:00:06.40ID:???
bigint知らない人がなんか言ってるw そう思うなら、スレから消えたら良いだけなのに、負け犬の遠吠えみたいに書き込むあたり実に浅ましいなぁwww こいつがリアルで何をやっているのかw
開発者ですら無さそうだが どうした、元気ないな
一杯構ってもらえてよかったじゃないか >>531
はいはい、低レベらーなララベらー元気っすね。 サロゲートキーをAIするとオーバーフローするから危ないだろ！！
→ bigintの概念を知らなかった
$_ENV上書きするのバカすぎｗｗｗ
→ Laravelじゃなくてphpdotenvの仕様なのでスレチ
今どきグローバル関数っすか？
→ これだけ具体的にどんな問題があるのか分からないから教えて欲しい 正直な所、32bit unsigned intでも溢れるような案件って
そんなにあるようには思えないが実際はどうなんだろうね？
idをbigintにしないといけないような案件なら、週か月のバッチ処理で古いデータを
移動させたりするような運用が無いと、マジでディスクがいくらあっても足りなさそう
ログみたいに大量に出力されるもの前提ならそのままDBに突っ込むのでは無く
fluentd等を使って他の場所で処理させた方が良さそうだしなぁ >正直な所、32bit unsigned intでも溢れるような案件って
>そんなにあるようには思えないが実際はどうなんだろうね？
そんなには、ねぇよ。
何回言ったらおまえらの低脳でも理解できんのかわかんねぇけど、
おれが言ってんのは
プライマリキーに『有限な値の型』を使う発想が理解出来ん、
って事。
で、数年で普通にint超えるレコード登録される可能性のあるテーブルに
int AUTO_INCREMENT してる案件あった、
馬鹿ってさ、どこにでもいるんだよ。
.envをコミットする馬鹿もいるだろ？
だから、馬鹿が馬鹿な事出来ない設計をする必要があるんだって話。
分かった？ 馬鹿君。 >>536
じゃあお前はvarcharとか使ってるのかよｗ
その方があり得んわｗｗｗｗｗ
流石低能ｗ
どんな型でも有限なんだよｗ
お前のディスクは無限大なのだよｗ
ガイジはホント開発すらしたことないから物事が何も理解出来てないようだｗ >>537
> じゃあお前はvarcharとか使ってるのかよｗ
> その方があり得んわｗｗｗｗｗ
なんで？
> どんな型でも有限なんだよｗ
例えばvarchar（32）が許容するユニーク数幾つになるか、お前、計算できる？
ほんと、こんな馬鹿しかいねぇんだよな、ララベらー…。 >>539
unsigned int（32bit）ですらいくらあるか知ってるの？w
お前ごときがそれ埋まる程のデータ使うとか有り得んやろw
プライマリーキーに文字列wとか普通に考えたらディスクは食うわ遅くわでそんな設計しないわw
あ、ナチュラルキーしか駄目なガイジだったかw
商品コードをそのままプライマリーキーにしたいニダ？w
死んどけw >>540
> unsigned int（32bit）ですらいくらあるか知ってるの？w
桁が違うって事すら分からない馬鹿は黙ってた方がいいよ？
まじでおまえ、計算出来ないだろ？
- 例えばvarchar（32）が許容するユニーク数幾つになるか、お前、計算できる？ >>540
> 商品コードをそのままプライマリーキーにしたいニダ？w
> 死んどけw
なんで？
おまえってさ、『実務』って、知ってる？ このageてる荒らしはluckerまたはgoku59またはteratail_dayoと言ってteratailで何度もBANされてる問題児
超低レベルなくせに上から物言って論破されるのが趣味のやつ IDだしてくれる分にはありがたいからそんなこと言うなよ >>544
なんだ？ この馬鹿。
自分から『わたしは頭おかしいです！』って宣言する奴、居るか？ 普通。
ほんと、ララベらーって馬鹿ばっかだな。 これか。
キチガイじゃん、こいつ >>544
940 名前：仕様書無しさん 2021/04/30(金) 20:03:35.46
【至急】luがLaravelスレに来てうざいです。引き取ってください それで、>>544 は、なんでそんなに発狂しちゃったん？
これか？
本物の知恵遅れだろ、お前 >>544
541 名前：nobodyさん 2021/04/30(金) 20:18:13.45 ID:???
>>540
> unsigned int（32bit）ですらいくらあるか知ってるの？w
桁が違うって事すら分からない馬鹿は黙ってた方がいいよ？
まじでおまえ、計算出来ないだろ？
- 例えばvarchar（32）が許容するユニーク数幾つになるか、お前、計算できる？ >>545
IDにしてもキャラ付けにしても自作自演のための小道具だよ
こいつキャラ付けずに別人のふりして自演擁護するけど時々失敗してバレるから というか、これ
940 名前：仕様書無しさん 2021/04/30(金) 20:03:35.46
【至急】luがLaravelスレに来てうざいです。引き取ってください
…って、『マドハンドFは なかまを よんだ！』
みたいな話なの？
頭おかしいだろ、こいつ >>544 >>549
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ クソ小物 ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
草原出来るわｗ だからいい加減話理解しろよ
俺が言いたいのはプライマリキーに有限な値の型を使っているのが理解できないってこと
お前らプライマリキーが限界値に達したらユーザにどう説明するの？
システム止めてくださいって惨めに土下座しながらお願いするのか？ > だからいい加減話理解しろよ
ぐるぐるパンチレベルで草 >>555
プライマリキーの前にIDをつけるってどういうこと？ >>555
こいつ新しいこと覚えるのに時間かかるから無理ｗｗｗ お前らって2038年問題ってどのように対策している？ みんなに論破されたから今度は自分のことを偽物扱いしようとしていて草 >>558
PHPはCarbon使ってたら問題ない気がする
DBはdatetimeにしてる >>562
はいはい、低レベらーなララベらーキチガイっすね。 無能全レスおじさんに成り下がったか
人間こうなったら終わり >>565
下がってない
もう何年も同じところで低空飛行してる ていうかteratail_dayoは多分m.ts10806に相手してほしくてここで暴れてるんだよな？
mtsがいたとしても相手にしないと思うぞ https://codepen.io/sadsfff/pen/oNBryGr
すいませんphpスレでも聞いたんですが、
return $first_img;
<span class="thumbnail2"> この部分が連結できません。調べてもわからず、RSSで画像を引っ張ってきたときに画像がないものにダミー画像を使いたいのですが、何をどう調べればよいか教えてください。 >>534
> $_ENV上書きするのバカすぎｗｗｗ
> → Laravelじゃなくてphpdotenvの仕様なのでスレチ
そんなん、採用しなけりゃ良いだけじゃん。
Laravel開発陣営は、有り物採用しないとマトモな実装も出来ませんって話なの？
本物の馬鹿なの？ ララベらーって。 環境ごとのパラメータは、環境変数にセットすべきて話は理解しているはずなのに、「$_ENV上書きするのバカすぎｗｗｗ」て言ってるのはなぜ？
お前はどうしたいの？ >>572
こいつはそもそも環境変数にセットすべきということは理解してない
>>495を見れば分かる
これならdotenv採用するわな
環境ラベル付けや環境の増減によってコードを変更する必要あるし 多分実務経験が無いか、フリーランスの1人エンジニア、もしくは開発メンバーが極端に少ない会社に勤務しているんだろうね。
OSの環境変数に値設定することを全否定してるみたいだけど、
AWSのパラメータストアやAzureのKeyVault使いたいとき、つまりIassS側で設定する時どうするんだろ？
そもそも俺が経験して来た多くの現場ではdotenvはローカルの開発環境向けに使わないし、IaaS側はIaaS側のインタフェースから（AWSのパラメータストアとか、AzureのApp ServceのConfiguration）で環境変数を設定してきたよ。
>>571
報告する場所が間違ってる
お前が報告するべき場所はこっち
https://github.com/vlucas/phpdotenv/issues >>573
え？そういうこと？？やべーな。10年以上前のスタイルで開発してるってことか・・・ >>574
失礼、訂正
"しか"が抜けていた
× dotenvはローカルの開発環境向けに使わないし
○ dotenvはローカルの開発環境向けにしか使わないし あと殆どのパッケージは、なんらかのありものを使って開発してると思うんだけど、全世界のOSS作成者disってるの？ > あと殆どのパッケージは、なんらかのありものを使って開発してると思うんだけど、全世界のOSS作成者disってるの？
論点すり替える馬鹿。便利なら使う。便利じゃ無ければ作る。
>>577 は思考停止した本物の知恵遅れ >>572-575
宇宙から電波受信して妄想語りあう病院通いの馬鹿共。 > OSの環境変数に値設定することを全否定してるみたいだけど、
誰が言ったんだよ、その寝言？
脳みそ腐ってんな、こいつ。
まじでばかって３ぎょういじょうのにほんごよめねぇのな。 話伝えられないタイプの人ね。大規模現場では弾かれる人。 こんなのが現場に居たら、それだけで士気下がりそうだな。誰とも仕事できないし、自分の頭の悪さを自覚せず周りのせいにばっかしてそう。 まあ確かにlaravel9では.env廃止してyamlの設定ファイルにする見たいだから
環境変数やめようって方向性はあるのかもしれん >>581-583
妄想爆裂して妄言語りあう病院通いの馬鹿共。 必ず３発ずつレスするヴァカｗｗｗｗｗ ちょーうけるんですけどぉｗｗｗｗｗｗｗｗｗ ここまで律儀に煽りに反応している奴ってのも何だかなぁ。他に構ってくれる人居ないのか？可哀想。
ところで>>572の質問には答えることができないのだろうか？人格攻撃で返されてビックリした。 > ここまで律儀に煽りに反応している奴ってのも何だかなぁ。他に構ってくれる人居ないのか？可哀想。
なんだ？この自己紹介馬鹿 ふむ。やはり>>572には回答できないのか。残念。 アホすぎて相手にされなかったという事すら分からない馬鹿の自己主張 >>593 まごう事なき本物のバカの妄言。これが筋が通っていると信じ続ける知恵遅れの >>593
572nobodyさん2021/05/02(日) 08:32:15.85ID:???
環境ごとのパラメータは、環境変数にセットすべきて話は理解しているはずなのに、「$_ENV上書きするのバカすぎｗｗｗ」て言ってるのはなぜ？
お前はどうしたいの？ > 6時間後に更に追加でレスするの面白いな
すげぇな。らっきょが転がっても笑うだろ、お前。 Laravel使いって、意識高い、レベルも高いPHPerが多いと思っていたんだけど、
どうやら拙者の思い違いだったようでござるよ Laravel 9に向けて本出してくださいね
お願いしますよ
今どき6の本出すのは池沼ですから 今年発刊されたのが6.x対応とか書かれたの見た時はおいおいって思ったな マジかよｗ
てか公式サイトあれば本要らんやろ あれ見れば大体わかる Laravelのマニュアルを理解できないレベルだと、そもそも言語自体の初心者だったりMVCパターンすら知らないだろうから、そういう層をターゲットにしてるのかな？
MVC+PHP+Laravelをパッケージで覚えるみたいな。
個人的にはそれぞれバラで理解するほうが効率的だと思うが。 海外でもLaravelはバージョンアップのサイクルは早いから、本を書き上げたときには次のバージョンに移ってて無理て言われるぐらいだぞ。大人しく、公式マニュアルで勉強しとこうぜ。 書き上がってから変更点を直せばいいんではないの？もう刷っちゃってたら変更点のdiffをサイトで公開するとか その理屈で言うなら、Laravel6を本で勉強した後に最新との差分は公式見て勉強するアプローチで良いのでは。いずれにせよ公式マニュアル優秀すぎるんだよな。
それより俺はLivewireの本が欲しい。親子関係のコンポーネント作った時の実装分からなさすぎてツライ。 9がLTSだから秋以降に何冊かは出るだろうな
今から6とか8の本を出すのはさすがにセンスがない 本なんか出してももう売れる時代じゃ無いのにな
公式見てわからん奴は開発しなくていいしw >>609
Laravelのバージョンの考え方が今年の2月ぐらいに見直しになったからね。
それまでは8のサポート期間は2021年9月までだったんだけど、3月のバージョン9リリースを見送ることになったタイミングで1年延長された。 LTS末期までお前ら自身が生きてられるか不明なのに心配しなくていいだろ リリース後もバージョンアップに追従したりみんなしてるの？
こちらは開発終わればそもそも終了なのでその後の事は全く知らんけど そんなの契約内容次第だが
自社製品だったり、業務委託でも保守契約結んでたりすればアップデートもするし、そうでなければしないだけのこと 本業は自社サなので当然バージョンアップもする。趣味のサービスも勉強ついでにバージョンアップする。副業のサービスのみ微妙。毎月の保守費の中で対応できそうならやる感じ。 保守するかどうかはクライアント次第なのでエンジニアが底辺かどうかは関係ないのでは 614が底辺かどうか知らないけど、常識レベルの質問するあたり新人って感じはする 底辺煽りはイキり散らしている奴相手のときだけにしとけ。普通に質問している奴には、ちゃんと回答してあげたら良い。 >>612
pbs.twimg.comは手軽に持ってこれるからTwitterでそれらしい画像探してきたんよ すみません教えてください。
laravel-mixでjsファイルやcssファイルをコンパイルするというのはわかりましたが
phpファイルはどうやってコンパイルすればいいのでしょうか >>623
.jsと.scssと.phpを一緒のディレクトリにぶっ込んでnpm run prodって叩けばいい phpをコンパイルしてネイティブに変換するプロジェクトがあった気がするけど名前が思い出せない Laravelってなんでルートの書き方変えたの？
IDE使ってると補完聞いて便利ぐらいしか思いつかないけど
なんか技術的な理由でもあるのか？ >>627
php8でJITを有効にすればある意味コンパイルしているようなものではあるけど
まだ使ったことが無いので使用感は分からないが laravel 10ぐらいでromaに移行すると思いますか？ >>628
前の実装だとクロージャールートがキャッシングできなかった。それを改善するために今回の変更が行われたんじゃないかな。
6/30のツイートでそのような主旨の発言をしているし、その5日前には当該箇所を修正してコミットしている。 クロージャーキャッシングってなんだよ
次から次へと新しい言葉でてくるし何のことかさっぱり
なんでおめえらさんたちそんなに詳しいんだ クロージャーキャッシングじゃなくてクロージャーのルートをキャッシュすることだし、
クロージャーすら分からんのはお前が無知すぎるだけ。 >>633
これはさすがにレス乞食だと思うからスルーで良いと思うよ 今年リリースされるLaravel9はどういう変更点があるのかな 噂だとBladeではなくTwigに変わるらしいけど本当なんだろうか ガセでしょ。envやめてyamlにするってガセ書き込んでる奴もいたし。リポジトリもツイートもほぼ毎日見てるけど、どっちの話一切見かけたことないわ。 5年後、laravel-mixからromaに切り替わってると予想 それなら知ってる。ただそれ持ち出すなら、まずlaravel-viteのほうが先だと思うよ。 テンプレエンジンはどう考えてもTwigにした方がいいだろ。
当時既にSmartyクソだってなってTwigがかなり流行っていたのに
なんでBladeとか独自路線行ったのか意味分からん。 twigもbladeも単体で使えるし、今のlaravelでもtwigをインストールすれば使える
そもそもphpのテンプレートエンジンとか使わんからどうでもいい
jsonさえ出力してくれればいいよ >>644
twigはbladeと比べて具体的にどこらへんが良いの？ >>646
それを説明できる奴なら黙ってblade使ってる説 BladeにはTwitterのaddFilterとかaddFunctionみたいなのないっしょ。 CodeIgniter4触ってみたけどなかなかいいですねぇ >>648
bootで独自ディレクティブ定義すれば同じことできると思うんだけど、それだと何か不満あるの？ 昔はフレームワーク無しでtwigだけ使ってたから懐かしい >>650
3が薄っぺらかったんだけど4で盛り盛りになったの？ お前らがSymfonyやCakeやCodeIgniterなどではなくLaravelを選択した理由ってある？
単純に世界中で人気だからとかではなくてなんか技術的な部分で 多分このスレには技術選定する立場の人間はほぼ居ない 脳みそ停止してるからあまり難しいこと聞いても無反応だよ フレームワーク無しやCakePHP,FuelPHPなどで色々組んでいたけど
Laravelがある程度名前が知られるようになった5年くらい前に切り替えた覚えが
それ以降は他のフレームワークには浮気していないな >>657
お前がそうだからって、周りもそうと決めつけるのは良くない。 >>657
んなわけねーだろ
このスレは零細と個人事業主がメイン層だから否応なしに技術選定する奴がたくさんいる
それなりに人数揃えてる企業に勤めてる奴はこのスレだとレアなんだよ >>663
それな
このスレには、やれスクラムマスターだのプロジェクトリーダーだのがLaravelを選んでそれに従ってる、なんて言う軟弱者はほぼ居ない。
「プロジェクトのプログラマは俺だけだ、だから技術選定も俺がする」って言う孤高の戦士がメインだから。 >>663
それなりにでかい企業だけど、事業部制だとサービスの規模次第では普通にやらされるぞ。技術選定。 >>664
> 「プロジェクトのプログラマは俺だけだ、だから技術選定も俺がする」って言う【孤高の戦士】がメインだから。
自分で言うかね？ ダッセ Laravel遅い遅いっていわれるけど実際実感したことないな
不特定多数の人からLaravelで作ったホームレスページにアクセスされたら遅くなるの？ >>667
それ主張してる人、単にOPcache使ってない説が濃厚なんだよね。 >>653
4は薄いLaravelって感じになってる
artisanコマンドに似たsparkコマンドってのが用意されていて
そのコマンドでコントローラとかモデルとかマイグレーションなどいろいろ生成して実装する Fuelさんはもう復活しないのかな
書籍はめちゃくちゃ評判よかったのに 速いとか遅いとか、ただの体感だからなぁ…。
こんなページでサーバからのレスポンス何秒で返ります、とか書いてくれれば比較のしようもあるんだけどね…。
ちな、Laravel使ってないオレのサイトのブログ風ページのレスポンス大体0.067秒くらい。
これ、メモリキャッシュ使わないでファイルI/Oオーバーヘッド有りの状態。 阿部寛のHPをLaravelで構築するとどうなりますか？ >>669
> artisanコマンドに似たsparkコマンドってのが用意されていて
もう、徹底的に引火にこだわってんのなｗ
あれITで引火にこだわると炎上プロジェクト連想されてすげぇ不吉なんだよね。PHPなら尚更。 Cake4の本が出てくれればいいのに、出ないよなぁ
Laravelのスレで嘆いても仕方ないことだけど そういえばLaravel最新のマイナーバージョンアップで、ついにページネーション時のlimit offsetていうクソ実装やめたな。 >>678
ページネーションする時にLaravelはlimitとoffsetを組み合わせてDB問い合わせしてるんだが、これはインデックスが効かないので件数の多いテーブルに問い合わせする時に著しいパフォーマンス低下を招く。
それを今回idとlimitを組み合わせて問い合わせる方式に変更したってわけ。 >>679
limitはできるけどoffsetはできなくなったということですか？ >>679
idとlimit組み合わせてoffsetができるの？ えー。ページネーション自分で実装したことないのかよ。取得したレコードの最後のidをキーにしてlimitと組み合わせて取得するって実装は古来より行われてきてたでしょ。offsetなんてそもそも要らん。 >ページネーションする時にLaravelはlimitとoffsetを組み合わせてDB問い合わせしてるんだが、
ここまでは、分かる。
> これはインデックスが効かないので
何これ？ なんでlimitやoffsetにindexが関係してくるの？
だってselect hoge from hage where a='b'←ここでしょ？ indexが関係するの
意味がわからないんだけど…。 >>684
issue読んだ？そこにも書いてあることだけど、少なくともMySQLは、offset+limitの位置までレコードフルスキャンして、そこからoffsetまでのレコードを捨てるという挙動になる。
だから大量データをページングしようとした場合、ページを進むごとにパフォーマンスが悪化していく。
当たり前の話だと思ってたけど、案外知らん人も居るのか。 ポスグレも同じような仕様だったと思う
最近のは知らんが 全DBそういう仕様だった気がする
DB実装している人たちもこの実装はおかしいと思わなかったのかな >>685
相変わらず、何言ってるか分かんない。
issueのって、idの番号に意味がある場合の話でしょ？つまりidの順番がそのままselect結果の順番になって良い場合のみの話。
ページネーションだから例えばブログ記事を例にするけど、idの順番って記事の登録順って事になる。
でも、最近更新された記事順なら全く意味なくなるでしょ。
id:1の記事をつい最近更新したけどwhere id > 10 〜 offset 10やられたらselect対象から外れちゃうもん。
そんなキー使っても意味ないでしょ。
>>687 も何言ってるか分かんない。
おかしいもなにも、こんなの当たり前じゃん。
極めて特定のケースというか、むしろDBの用途としてはほぼ使わないケースを例に上げておかしいと思わなかったのかなって、何？
>>688 に至ってはもう…。
どんなキー使うかは全く関係ないじゃん。
あなた達、何言ってるの…？ まじで分からん。
まだ俺が誤解してんのかなぁ…？ >>689
お前が何を分かってないのかがよくからんね。もう少し論点整理してくれ。みんなも困ってるじゃん。
ところで全然関係ないけど、bigintの92京はsignedだって知ってる？前にそんなことも知らずにここで人を小馬鹿にして暴れてたやつとお前の態度すごくよく似てるので同一人物かな？て。 >>687
別に変ではない。ページネーション付きのリスト表示つっても多くて数百とかならそこまで劣化しないだろうし、where条件が複雑になって辛いってのもある。
ただそうは言ってもoffset使いたくないて思うケースもあるのは事実で、↓みたいに国内でそこそこ有名なLaravelの使い手もoffset使わない実装を解説してたりする。
https://qiita.com/mpyw/items/b94b7d69146777f7a407 Laravelの公式の方々がやってることを意味分からんって言うなら
もうLaravelなんか使わずに自分で納得できるフレームワーク作りなよw
なんでこのスレに来てるのか謎 >>690
はぁ？ 何処が分からないって言ってる？ 日本語読める？ ページネーションの概念も現状の実装、DBの仕様や実装も含めて何も理解せずに、
「オレの考えが正義」の発想だから>>684や>>689みたいなことになるんだろうな
とにかく何かめちゃくちゃ勘違いしてることだけはたしかだが、
その態度がでかいから叩かれるw 俺様が使ってやっているんだから、ありがたく思え！
当然俺様の要望も全てのんで、実装しろ！
ってことかな？ アンチサロゲートキーおじさん、相変わらず健在なのか。いい加減、他所に行けば良いのに。 最近でもvue.jsとかreact使わないアプリ開発している人多いのか？
bladeでゴリゴリ画面作ってた昔が懐かしい お、本人再降臨か
句点ついてるし分かりやすくて笑えるw
もう言いたいことはなくなったのかな？
また面白いこと言ってこのスレ賑わしてくれよw Laravel9って今のところどういう変更点が予定されているの？ >>702
9はこれからだよ。リポジトリ見てるとそこそこ9に回されてるPRはあるけど目を引くものは無いかな。だいたい7月にデカイPRが入る。
というか8のマイナーバージョンアップで入ってきた機能も相当あるので、9を気にする前に8をキャッチアップしたほうが良いかもしれん。 Laravelでバッチ処理書いてみたけどやたら遅くないか？
CodeIgniterだと5分で終わる処理がLaravelだと1分かかる アクセスログ見たら、.env狙い撃ちしてるのあった。 このフレームワーク、ずっと完成しない気がしてきた…。 >>708
何でそう思うの？Laravel8の毎週の機能追加みてたら分かるけど、破壊的変更しない限り、8のマイナーバージョンにガンガン取り込まれていってる。だから9での変更点なんてそんなに無いと思うよ。
そして破壊的変更をそんないくつもマージするようなことは過去無かったので、8→9の変更点は少ないと予想している。 エアロスミスがLaravelのチュートリアルやりはじめたらしい Laravelで聴きたいことがあるんですが複合主キーってどうすればいいですか？
モデルのprimaryKey変数にどのように設定すればいいかがわかりません。 >>713
このスレで複合主キーの話題はNGなんだ
他のスレで質問したほうがいい ググればやり方くらい出てくるやろ
ただし動作の保証はしないけど そもそも複合主キーを使用する時点でDBとしての設計が間違っているから設計の見直しをしたほうがいい マジレスやめれ。前から荒れた話題が収まった頃に初心者のふりして同じ質問してくる芸風の、それこそバカの一つ覚えみたいな荒らし居たでしょ。相手にするだけ時間の無駄。 複合主キーそういえば対応していないな
他PHPフレームワークも対応しているのみたことがない
JavaだとSpring Frameworkが複合主キー対応しているけど >>719
逆だろ 初心者が質問したらそれを揚げ足取る連中が表れてスレを荒らすから
初心者の質問に誰も回答せず 結果再度初心者が荒らしがいなくなったころに
再度同じ質問をしなければいけない状態になっている >>721
こんなクソみたいなスレに、わざわざ質問しにくる初心者が居ると本気で思ってる？しかも荒れたら、間を置いて再度質問する？本気かよ。ピュアホワイトかよ。 実際Laravelについて気軽に質問できるのってこのスレじゃないか？
他にも質問できる技術サイトはあるけど初心者には敷居が高いだろう 複合主キーってどうすればできますか？という質問は
.envをコミットするしないで議論していたことに比べたらすごい真面目な質問だろ まぁ推奨しないから設計を見直したほうがいいというのが結論やろうな
複合ユニークは普通に設定できるしそっちにすれば良いかと お前ら複合主キーの質問が来ただけで発狂したのかなよ・・・・
さすがに技術レベル低すぎでは？ まあペチパーのリテラシーなんてこんなもんよ
これがRailsだったらイケメンがサラリとアドバイスするのに laravelで複合主キーのサポートしてくださいってissuesに上がってもよさそうだけど
みんな複合主キーサポートはそこまで望んでいないのかな >>727
ある議論で荒れて収まったと思ったら、同じ質問をするやつが現れるってことが何回も起きてるからね。>>719に書いた通り。 >>732
そもそも複合主キーのどこに荒れる要素あるんだよｗｗ >>733
>>140からの流れ見てもらえればわかるけど、サローゲートキーにオートインクリメント絶許マンが現れて荒れたんだ・・・。 複合主キーも設定できないなんて、Laravelってポンコツなんですね。
ガッカリしました。 質問なんですが、/var/www/htdocsをドキュメントルートとして
/var/www/projectでlaravelをインストールした場合、
http://sample.comでフロント側を動かし
http://sample.com/mngで管理画面を動かしたいです。
そのような場合、htdocsにmngというシンボリックリンクを張って、
（ln -s /var/www/project/public mng）
あと、フロント側はどうすればいいのでしょうか？
この方針だとまずい場合、どうするのが一般的でしょうか。 フロントは何で動いてるの？Laravel使うのはあくまで管理画面？ フロントもLaravel、管理画面もLaravel？プロジェクトはフロントと管理画面で別ってことかな？同じなら、別にシンボリックリンク要らんからね。 １つのプロジェクトでルーティングや処理を分けたいと思ってます。
同じプロくジェクトならシンボリックリンク不要でしょうか…？
ドキュメントルートの配下にプロジェクトを置くということでしょうか？
どういうディレクトリ構成にすればいいのか分かりません。。 というか、CMS付きのホームページをLaravelで作る場合、
どうやるのが一般的なんでしょうかね？ 同じドメインで1プロジェクトなら特に何も考えなくても良いのでは？
ルーティングでどうにでもなるでしょ？ これまでは
/var/www/htdocsにmngというプロジェクトでLaravelをインストール
↓
/mng/.htaccessに
RewriteCond %{REQUEST_URI} (\.\w+$) [NC]
RewriteRule ^(.*)$ public/$1
でリライトして管理画面を作ってました。
http://sample.com/mng
へアクセスして、
Route::get('/', function () {
return redirect('/login');
});
というルーティングでログイン画面へ、といった具合です。
「何も考えなくても」ということなので、私が何でもない所で悩んでいるような気は
するんですが、できれば具体例で「こうすればOK」というのを教えて欲しいです。。 あ、ちなみに最初のシンボリックリンクのくだりは、上記の方法で行き詰ったので
方法を変えたがまた行き詰った…という経緯です。 普通はドキュメントルート指定して、あとはroute/web.phpで、ユーザー用のURLと管理用のURLを定義するだけだと思うけど。なぜ上のような設定にしたのか意図がわからぬ。 特に意図してやったというわけではなく、URLで/mngにアクセスした際に
/mng/public/index.phpを実行させるためにこうしないと、と思っただけです…
「ドキュメントルート指定して、あとはroute/web.phpで、
ユーザー用のURLと管理用のURLを定義」の部分を具体的に教えて欲しいですm(_ _)m
http://sample.comでフロントのトップページ
http://sample.com/mngで管理画面のトップページ
としたい場合、
・プロジェクト名
・ドキュメントルート
・web.phpをどう記載するか
を教えて欲しいです。。
ルーティングのアクションは適当な例示で構いません。
質問ばかりですいません… これまでで管理画面（社内向けシステム的なもの）しか作ったことなかったので
ある意味上記の方法で悩むことはありませんでしが、根本的にやり方は良くなかった
のでしょうかね。そんな気がすごくしてきました。 そんなところで詰まってたら永遠に完成しないと思うぞ
ルーティングの基礎の基礎なんだから、ちゃんとドキュメントみてしっかり考えようや
https://readouble.com/laravel/8.x/ja/routing.html ドキュメントルート直下にmngという名前でLaravelをインストールして、
mng配下の中身をルート直下に移動→.htaccessで
RewriteCond %{REQUEST_URI} (\.\w+$) [NC]
RewriteRule ^(.*)$ public/$1
とすることで
Route::get('/', function () {
return view('welcome');
});
Route::get('/mng', function () {
echo 'test';
});
とすることで、フロントと管理画面を分けられそうです。
これが一般的な方法でしょうか…？ viewはpublic似ないのに何故そんなよくわからないことをするの？ 起点となるのは/public/index.phpなので、publicをURLから省くための
何らかの処理がいると思うんですが。。 シンボリックリンクとルーティングだけで普通にできないかね？
まあ、何したいかもよく分からんし、それで動くならそれでええやん ルーティング難しいよなぁ
htaccessが絡むと余計にわからなくなる 何度もすいませんが、その場合ドキュメントルートを/publicに指定するということでしょうか？
シンボリックリンクはどこからどこへ張ればいいのでしょうか。 >>737
Alias使った方が良いんじゃないの？
考え方としては別ドメインと同じなのでLaravelを2つインストールする。
https://www.javadrive.jp/apache/ini/index12.html 俺がヒマだったら予約システムぐらい、Laravelでさくっと作ってやるのに 日本のITオンチっぷりがシャレになってない感じだから、自分の技術力で何とかしてやりたいと思うことはある すいません。こちらいかがでしょうか…？
>>755 うちにもcomposer使えない環境へのデプロイ必要な案件来てしまった
しょうがないからvendorコミットしたわ 俺みたいな古い人間は、composer使うと抜けがあるのではないかと心配してしまう composerが使えない環境って
社内LANみたいな感じで外部と一切つながってないって事？
まぁ、社内システムなら社内のネットワークだけで閉じるというのはありそうだけど >>766
その通りです。社内のネットワークしか繋がっていない環境です。 >>750
そもそもドキュメントルート直下にインストールすることを想定したフレームワークではない
管理画面もフロントだと思うんだけどこのあたりしっかり説明してもらわないと
求めている回答が付かないと思います >>771
あなただけじゃないと思うけど、php自体やその他の更新頻度を見ると、現実的に仕方ないかなぁとも思う >>770
広い意味では管理画面もフロントですが、私の言うフロントは
公開側という画面と言う意味です。
たしかに、公式のドキュメントにもそのように記載されている
のは承知していますが、管理画面とフロント側をどのように
分ければいいのかが分かりません。
公式の推奨に従ってhtdocs（Webルート）と同階層にインストール
したとして、
http://sample.com/mng
というアクセスでLaravelアプリケーションを動かそうと思うと
htdocsに「mng」というシンボリックリンクを張ればいいと思いますが、
（ln -s /var/www/project/public mng）
http://sample.com
というアクセスで同じ「project」というアプリケーションを
動かすにはどうすればいいのでしょうか？
そこさえクリアできれば、あとはルーティングでどうにでもできると
思うのですが。。 teratailだと切れた常連エンジニアに説教食らいそう。 rewriteのルール(ドキュメントルートの.htaccess)はLaravelのデフォルトのままで良くて
そもそもシンボリックリンクなんて使う必要も無く単にルーティングで分ければ良いだけでは？
rewriteもフレームワークを使わず直接phpを動かす場合はURLのパスの部分がそのまま
ドキュメントルートからのサブフォルダの階層にはなるが 出来の悪いコロナ予約システムにLaravel使ってる噂 むしろ何で分からんのや。マーソて受託した会社の採用ページみたり、ソースみりゃ分かる。 inputタグの属性でcakePHPてはっきりわかんだね。 NGワードひっかかってURLが貼れないわ
見様見真似でcakephp使ってるらしいな
https://i.imgur.com/nLDH7s5.png
2019年に書かれたブログ記事 マーソの話題はスレチなのでcakePHPスレでやって >>773
だからAlias使えばいいじゃん。Apacheじゃないの？ 案の定、NginxでもAlias使えるし。
人の話、ちゃんと聞きなよ。上の方で一回言ったよ？ 入力された電話番号が正しいものかどうかって判定するには実際どうすればいいんだ？
入力された電話番号にショートメールで認証番号を送信して
それを再度入力しないと登録が完了させないようにするとかになるのかな >>791
SMSを使って確認する方法も微妙に穴があるけど、それぐらいしかないのも事実 新しくlaravel始めることになりました。
COBOLからの乗り換えなんで爺さんには大変です。 自分の環境だとGNOME40になってからEloquentが動かなくなった
GNOME40とEloquentはまったく関係がないはずなんだけど・・・・・ >>795
海外だと勘定系がLaravelはあるんだぜ・・・ >>774
>>770の方法でやろうと思う理由ですが、Laravelを2回インストールしたくないからです。
回答が遅くなりました。 勘定系をPHPのシステムでって、端数丸め対応が大変そうだな。 6月からLaravel勉強しようと思ってるんだけど、
ちょうど6月に販売される本って高いね。4000円超える・・・
みなさんはやっぱりオンラインマニュアルで覚えたんですか？ >>801
あなたの今の知識次第だと思いますよ
PHPとインフラ/ミドルウェアに対しての知識が十分であれば、公式が最も適したドキュメントになります ググる時間がもったいない
本1冊を一気通貫でやるのが最短
4000円なんて技術者１〜２時間の人件費でしょ？
本で節約できる金額考えたらおつりがくるよ Laravelの本のターゲット
・MVCが初めて
・PHPが初めて
・Laravelが初めて
・お金をケチらない
一個でも外れてるなら買わないでドキュメント読んだほうが良いと思うよ
というか全分当てはまってる状態でLaravel始めても尚更訳分からんと思うからやっぱり個別に覚えたほうが良いと思うけど >>804
全部外れてるけど、「ドキュメントがわかりづらい・理解できない」ですよね・・・ >>801の本の詳細説明みてからコメントしてる奴おりゅ？
あの本はLaravel8の解説書ではなく、Laravel8に対応した「ぼくのかんがえたさいきょうのせっけい」を読まされるだけじゃね？ADRとか言ってる時点で論外。中級者以上なら参考になるかもしれないが。
それよか、ちょうどドットインストールがLaravel8の入門公開してたからそっち見たほうが良いと思う。 >>806
そうなんですか・・・危うく買ってしまうところでした
今の時期は本屋にも行きにくいし、中身確認できないですからねぇ Laravelに関しては本と公式だと完全に公式の勝ち
まだ出てない本は知らんけど、余程じゃないと勝てんぞ Laravelの公式リファレンスはある程度の技量がないと読み解けないと思う
職人のためのフレームワークだからそれでなんの問題もないけどね
あれを読み解けないなら本を買うのは普通にありだと思うよ
分かりやすいわかりにくいはあるけど、だいたいは公式リファレンスよりかみ砕いて書いてある
ただ、今月出るやつは2回目の改訂だと思うが、ADRとか書いてあるし、
書いてる人がアンチFacadeだしで初心者向けではない感はある 昔よくあった掲示板の作り方のように
何か作りながら機能説明してくれる方がわかりやすいと思う >>811
時間があったらそういうのを１から作るというのを解説したブログとかを書いてみたいんだけどね
今ならyoutubeで解説したら見てくれる人はいそうだけど
そんなの作ってる時間ないな Youtubeは逆に難しいと思うぞ
動画を再生したり停止したりって動作が面倒すぎる 自社パッケージをLaravelで作っているがバージョンアップ多いので辛そう。
LTSで作って次のLTSでバージョンアップっていうのが王道なのかな？
メンテナンスとか保守とかが辛くなってきそうだ。
ライセンス問題が解決したCodeigniter使った方が良いのかなって思い始めてる。 確かにバージョンアップ頻発するとつらいね
そういう点でうちはCakeのままのがあるわ >>806
ドットインストールのお兄さんの声ってイケメンだよね >>814
王道は「バージョンアップなどしない」だぞ
テストやらのコスト考えると3年やそこらでメジャーバージョンアップとか却下 Laravelはlaravel-shiftて有償のバージョンアップ支援するサービスがあるので、それ使えって話で終わる。LTS→LTSなら7000円ぐらいでできるはず。 お前らの蔵なら作ったらほったらかしが基本だろ？
10年前に作ったCake1のシステム、CentOS6のPHP5で元気に稼働中 いや普通にバージョンアップ計画立てるが。趣味のサービスでさえ、6→8にしようと進めてる。 >>820
でもその毛髪をカウントするWEBアプリってバージョンアップする意味あるの？ 普通はわざわざLaravelのバージョン上げることもないよね
よっぽど重要なシステムなら運用中もそれなりに人材いるだろうけど大抵は運用中はそもそも開発した会社は完全にノータッチの事も多いだろうしね >>821
ハゲのお前には、バージョンアップのメリットは理解できないかもしれんな。 >>822
Laravel、今年だけですでに3回も深刻な脆弱性みつかってるから。
ignition由来のやつはまぁいいけど、バインド変数のマッピングの脆弱性は6より前のバージョンだと修正されずに放置はされてるはず。
作って納品して終わりみたいな人達はバージョンアップに縁は無いんだろうけど、運用している奴らはバージョンアップしないと自分のこと首を絞めることに。 脆弱性って言っても、コロナ予約システム並みじゃなければ
そうそうデータが盗まれるとかはないんじゃね？ >>817
なるほどです。
>>818
shiftの存在は知っているけど、その後にshiftでマイグレーションされたパッケージを全機能とかチェックするテスト工数は省けないわけで。 >>814
PHP、Laravel、自社アプリすべて常にバージョンアップを続けてる
多少の不具合は許される環境だから出来ることだと思うが
少しでも手を休めたら逆につらい そらそんな必要ないからな
客が納得して納品したら終わりや 今までの経験だと自社サービス開発、受託開発問わず、ほぼ確実にエンハンス開発はあるんだけど、このスレでは納品して一切触らないケースがほとんどなの？ 一切触らないケースが多いな
中小零細だと継続依頼ってなかなかないぞ >>831
受託開発した後に納品先に切られて別の開発会社に乗り換えられてる説 >>831
触らないケースが多いね
顧客がバージョンアップや新機能追加などの開発費出す余裕がないから エンハンス開発が無い = 作ったシステムがビジネスとして成功しなかった
だからね、ビジネスとして軌道に乗るなら改良もするが、軌道に乗らないきゃ改良なんてしない どの世界でも当然の話しなんだが、金出さないと成功しないからな
初期投資だけで成功すると思ったら大間違いだ >>831
そもそも完成するまでの依頼でその後依頼された事なんて無いからね
メンテなんて安い所に頼めばいいとでも思ってそうだけど
他人のコードを理解する方がよっぽど高度なのにね・・・ >>838
それ、冗談抜きでめちゃくちゃあるよな
あれだけ作る前にやりとりしてたのはなんだったのかと言いたくなる >>838
社内システムとかクローズドなシステムの開発が割と多いからそもそも納品した後で稼働しているか確認する術も無いけどね >>840
>>841
うちもB2Bばかりなんだけど客の担当がノリノリでも、現場が新しいもの使いたがらなくてなかなか移行できない…みたいに見える、想像だけど
納品後も客が管理者IDとPASS変えないから入れちゃうのでたまに見ると、データ増えてない あ、そう言えば納品してサヨナラじゃなかった今思い出した
SSL証明書の更新だけは毎年依頼されるｗ >>842
え、それちゃんと許可貰って覗いてんのか？ >>842
納品したシステムに勝手に入ってデータ監視とか終わってるなLaravelはｗ >>846
laravelは関係ないけど842の頭はヤバいな クエリビルダしか使わない場合、モデルは書かなくても良いでしょうか？ >>848
普通はLaravelのドキュメントに書かれているような
DB::table('tests')->where(条件)->get()
みたいなやり方よりはTestモデルを定義して
Test::where(条件)->get()
みたいに書く方が良い気がするんだけどね
テーブルが複数名でプライマリーキーがidならモデルのクラス作っておけばいいだけだし
（実際にはguardedなどは定義した方がいいけどひとまず置いておいて）
モデルを全く定義しないプロジェクトなんてやったこと無いから分からないがｗ DB::table('tests')->where(可変)->where(固定)->where(固定)->orderBy(固定)->get()
みたいなのがコントローラに延々並んでいるよりはモデル作って
Test::getSomething(可変)
みたいにした方がスッキリするんちゃう >>848
書かなくて良い。でもそんなシステム触りたくないわ。バッチなら良いけど。 >>842
それ大丈夫なの？
依頼があって見てるわけじゃなくて自ら勝手に見てるんでしょ？ >>842
それ許可なくログインはアウトだろ・・・・ > Test::getSomething(可変)
> みたいにした方がスッキリするんちゃう
やってる事が昭和だな。 >>856
どうゆうこと？>>850はローカルクエリスコープの話してるんだなって思って読んでたけど。 すいません。>>737 の質問をした者です。
自己解決できたので一応。
Route::get('/', function () {
return view('welcome');
});
の「'/'」の部分を、サーバーのルートからのファイルパスだと
間違って認識していたのが原因だったみたいです。
htdocsと同階層にLaravelをインストールして、
/htdocs/public/index.phpでパスだけ変更、
サーバーのルートを/htdocs/publicに設定することで
あとはルーティングでどうにでもできそうです。
>>746
で仰ってた意味がやっと分かりました。
色々すみませんでした。 >>857
いやスコープならscopeから始まる名称じゃないと駄目じゃない？
getから始まってるってことは昭和な書き方だよ 確かにローカルスコープを使うにはscopeから始まる名前にしなさいと
Laravelのドキュメントには書いてあるけど 実際はscopeから始まらなくても使えるんだよ 前スレのこういうレスがあったので
パフォーマンスを重視するならクエリビルダを使うってことでモデル不要なのかなと思いました
35 名前：nobodyさん [sage]： 2021/02/27(土) 09:16:39.22 ID:???
リレーションシップで取得可能かつクエリもパフォーマンスに影響が出ないものならeloquent。それ以外はクエリビルダ。 scopeの件理解した、なるほどそういうのがあるのか
でもやりたいことは単にgetという想定なのでメソッドはgetでいいと思う >>859
いやいや、そりゃモデル内で定義するときはscopeGetSomething()だけど、
呼び出すときはTest::getSomething()でしょ。
ただ命名のことを問題にしてるってことは理解した。
それについてはget()まで含むクエリスコープなら、getから始まる名前つけるのは悪くないと思った。 >>863
それ書いたの俺だけど、意図としては原則Eloquent使って、例えば数万件のデータをバッチでfetchするときはクエリビルダ使うってこと。
詳細画面や一覧画面とか表示する分には、クエリビルダのほうが速いって言っても誤差の範囲だから使う理由はない。 故人的にはgetSomethingよりもfindSomethingのほうが好きだな
Test::getSomething()->get()
Test::findSomething()->get()
となるかの違いでしかないけど >>868
1件あたりのデータの取得時間の差はμsレベルだぞ。単にmodelオブジェクトにhydrateするかしないかって話だから。
その上でどれぐらいの同時アクセスを想定してる？そのレベルの誤差を気にする前に、サーバーのスケールアウトを考えるべきだと思うけど？ >>867
故人www生きろ！
てツッコミは置いといて。
それだと条件クエリをビルドしているだけだから、getもfindも論外だと思うな。加えてLaravelではfindは主キーを使って検索するってコンテキストになってるから、getより筋が悪いまである。 >>867
>Test::getSomething()->get()
getSomething()の中でgetもやるから->get()はいらないんだよ、なんならget後の加工までやるぞ
findの方は知らん getSomething()の中でget発行したらダメでは？
あくまでもローカルスコープはクエリの組み立てまでにとどめるべき いやだからLaravelのスコープとは関係ないんだってば
単に便利なgetメソッドを関数として書くだけ、目的はコントローラ内の記述を減らすこと > 単に便利なgetメソッドを関数として書くだけ、『目的はコントローラ内の記述を減らすこと』
こういうのをControllerに書かざるを得ないという仕様な時点で狂ってる。
CakePHPとかと一緒。 >>874
そんな制約はLaravelに無いよ
勝手にそんなアホな実装してる奴がいるだけ アプリのソースをどういう構成にするかは作る側が決めることだよね コントローラにすべての処理を書くのを批判する奴がたまに居るけど
どこに書こうが一緒やん
大規模になればDIでコンストラクタでサービスのインスタンスを受け取る手法もありとは思うが
そもそも殆がDIする必要もないしな >>840
予算の都合だよ
これ以上知るとバカらしくてやってられなくなるぞ >>879
これ実際どんな弊害があるのかな？
モデルに関する処理は長々とコントローラに書かずにモデルに書いて、共通処理は別の場所に書けば、コントローラで処理を書いてもそこまで長々と書くこともない気がする
それをサービスに追い出したところでサービス側がコントローラと同じようになるだけだしあんまり意味がない気がしてならない 共通化できそうなところは共通化して使いまわさないと改修時にコピペ箇所の改修漏れが発生しやすい 複数のコントローラで利用したい処理を1ファイルにまとめたいのですが
CakePHPのヘルパーに相当する機能は何でしょうか。 >>882
継承かトレイトかライブラリ化、用途に合わせて選べ >>882
Laravelは「継承よりコンポジション」てモダンな考え方に基づくから、traitを使うことが多い。 ただ共通化て言葉は、ベテランのエンジニアがよく警鐘を鳴らしているものだから、本当にその共通化が必要なものかはよく考えた方が良い。 ファットコントローラーの害が感覚的にわからないならプログラマとして必要なセンスがない
Cで言うと全部main関数に処理書いちゃってmainがバカでかくなってる初心者みたいなもん その説明では納得しないでしょ。ファットコントローラーがダメな理由は、コントローラーの責務を無視して処理を追加した結果だから。
責務を無視してしまうとMVCの構造が壊れてしまうので、MVCがメンタルモデルとして定着しているエンジニアは、そのコードを読んだり改修することが極めて困難になる。 つかそういう事は10年前1万回議論されて結論出てるんだから
ググレカスって話だよな >>883,884
トレイトを使う場合、のディレクトリに保存するのでしょうか？ >>890
正解は無いんだけど、俺の場合controller用なら、Controllersディレクトリ配下にConcernsてディレクトリ作ってそこに格納する。
このやり方はRails由来だね。ただLaravelの人気パッケージでも取り入れられている手法でもあるので、お勧めしておく。 そういや
php artisan make:trait
ってコマンド結局まだ実装されてないんだっけ？ ファットコントローラーって名前が嫌だからコントローラーは太らさないようにしてる 別に最初はコントローラーファットでよくない？
途中のリファクタリングの過程でファットでなくすりゃいいだけだし 俺はControllersにTraitsってディレクトリ作って入れてたな >>892
そんな議論て過去にあったの？traitてPHP側で実装されたものじゃん？ 自作でartisanコマンド追加してる人は結構いるってくらい 誰一人としてファットコントローラーがダメな理由を納得出来るレベルで言えないのだから
結局外に追い出した所でそこのコードは同じことになるのだしなぁｗ
意味ない論議なんだよ お、煽りおじさんがきたぞ
いい天気なんだからぬこの散歩でも行って来いよ コードを書けば行数が増えるのは当たり前で、大きくなるのが嫌だからどうにかしようというのは、そもそもが違うよね。
行数増えて困ってる人というのはIDE使ってないの？何なの？ 下手な逆張りしてケンカを煽ろうとしても無駄だぞ
盛り上げたかったらもうちょっとマシな話題持って来いや ファットコントローラ解消してもファットモデルになるだけ 結局どこかには処理を書くのだから別に外に追い出した所でそれがベストですって
言う説明をしていたらそれこそ初心者レベルかと
同じ処理を何度も書かないとか基本的な事を守れていたらいいと思う
そこをコピペとかでやってたりするのは明らかに初心者だろうが >>904
じゃあファットコントローラーは何故ダメなの？ ダメな理由が全く納得いかないものしか無いやんｗ
頭悪いからダメと言うしかないの？ｗｗｗ 真面目にここにいる奴仕事で作ってるの？ｗ
お前のコントローラーは実装が数行しか無いの？ｗ
趣味の奴はでしゃばるなと思うわｗ クラスごとに適切な役割分担をしようって話でファットコントローラーだからとかファットモデルだから全部駄目って単純な話じゃないでしょ
モデルだけで不十分ならRepositoryパターンやValueObjectパターンや他のデザインパターンも入れれば良いし、コントローラーとモデルだけで話が完結する話じゃないじゃん >>909
ファットコントローラーはダメという単純な話だよ
ダメじゃないケースはないから >>902
いや普通ミドルウェアとかトレイトに持たせるやろ >>911
コントローラーってRouteに対して固有の処理になるから固有の処理ならしゃーないけど
共通化できる処理ならできるだけ括り出して外に持たせるべきじゃない？ >>912
ミドルウェアとかトレイトならファットになってもいいの？ >>898
>>888で納得できない？もっと掘り下げて説明してほしいなら、どの辺が納得できないか教えてくれると助かる。 コントローラーってのは処理の流れをコントロールするものなんだよ
データの加工みたいなゴチャゴチャした処理をする場所ではない
これだけのことなんだがわからんか？ >>914
処理単位でそれぞれ分けるならファットにならないぞ >>909
ファットコントローラーはとにかくダメだって言ってる奴いるけど、そいつは無視して良い。
何故ダメかは>>888に詳しく書いたから読んでみてくれ。結局のところファットコントローラーてのは、単なる設計ミスの産物だからダメなのであって、もしコントローラーの責務に見合った処理を書いた結果、なおファットコントローラーになってるなら、別に問題無い。 >>918
>>909はよくわかってるやつじゃん。釈迦に説法だった。 馬鹿しか居ないのかなんなのか知らんけど、
『ファットコントローラー』っていうのは状態であって、手法じゃねぇの。
Controllerに書くべき物で溢れてるなら、いいんじゃねぇの？ファットでも。
問題なのは、本来はModelに書くべき処理を全部Controllerに書いている状態の事。
Railsとか使ってMVS分かった気になってるヴァカはModel=DBにアクセスする物…
みたいな腐った誤謬を持ってるけど、
本来ビジネスロジックを書く場所がModelなので、
それがControllerに書いてあったら、
おまえ、ﾌﾟｷﾞｬｰ
なの。わかったか？ヴァカ共 MV"S"ってなんだよ？タイプミスったわ。
よし、ここからSの定義が何なのか議論始めるぞ。 てか、上で俺含めその説明してるでしょ。むしろ、理解してる奴の方が多いぐらいじゃね？ Controllerに書くべき物がそんなに溢れることってある？
余程でかいシステム作ってるのか JavaのSpringFrameworkだと
Controller、Model、View、Repository、Serviceに分かれるな ModelにDaoとRepository両方書いてる奴は居そうだな お前らのソースコードってすごいカルボナーラになってそうだな ああそうかDBアクセスのクエリとかModelに書いてしまえばコントローラーからはメソッド呼び出しだけで済むのか >>925
EloquentてORM使ってんのにDAOて単語が出てくる理由がサッパリなんだが説明してくれる？
その上でRepositoryてDDDのデータ操作レイヤーの話だと思うんだけど、お前はModelに書くことに否定的な立場なの？
上でも出てるローカルクエリスコープは、このデータ操作をビジネスロジックとして表現するための機能だから、俺の認識だとModelに書くのは至極当たり前に感じるんだが。 公式ドキュメントでもクエリビルダのレクチャーはコントローラー内に書いてあるがな DaoもDtoもEntityもRepositoryも全部Modelの役目だよ >>931
Eloquentとクエリビルダの違い理解してない人？ この馬鹿は一体何を言い出したのだ、お前たちよ。
932nobodyさん2021/05/23(日) 17:43:16.84ID:???
DaoもDtoもEntityもRepositoryも全部Modelの役目だよ そういや次スレﾜｯﾁｮｲのあるこっちでいいんじゃね？
【PHP】Laravel【フレームワーク】 Part.5
https://mevius.5ch.net/test/read.cgi/tech/1618480141/ >>932本人じゃないからわからんけど、 MVCを前提にした場合、controllerの役割とviewの役割は具体的に明示されているから、それ以外の全てがmodelにぶち込まれるってことを表現してるんじゃないか？
だから馬鹿とは思わなかったけどな。逆になぜ馬鹿と言い切れるのかその根拠を知りたい。 他のテーブルとのjoin操作までModelに入れるのはなんか違う気がするんだけどその辺どうしてるの？ >>937
人の話聞いてんのかな？ ModelはDBにアクセスする物じゃねぇんだから、
Modelとテーブルが１対１なわけねーーーーーーーだらーーーーーーーーーー！
937nobodyさん2021/05/23(日) 18:01:50.48ID:???
他のテーブルとのjoin操作までModelに入れるのはなんか違う気がするんだけどその辺どうしてるの？ >>937
そもそもEloquent使ってたらjoinなんて使わないでしょ。クエリビルダ使いたいなら、DBファサードになるからmodelは呼び出されず、必然controllerで書くだろうさ。それが嫌なら層を増やすべきだけど、MVC話の文脈とズレていくだろうからそこはスルー。 >>939
お前、Laravelまともに使ったことないでしょ。EloquentModelの特殊性を全く理解できてないように見える。もしかしてアンチサロゲートキーおじさん？ >>933
ラッピングされてるだけで一緒のものやぞ
$any_table = AnyTable::where(...)->where(...)->where(...)->select(...)->oderBy(...)->get();
$any_table = DB::('any_tables')->where(...)->where(...)->where(...)->select(...)->oderBy(...)->get(); EloquentModelつーかActiveRecordて概念を全く理解していないというのが正解か。 >>942
ラッピングしているというのはそうだけど、それ以外は全然違う。まずクエリビルダはModelを介さないのでデータ操作を隠蔽できずcontrollerに操作を書くことになる。さらに結果はmodelへのhydrateの工程がないためDBから受け取ったデータは標準クラスになる。当然castできないから、ぜんぶstring型という悲劇。 別にControllerにDB処理書いてもいいと思うけどな
Laravelのドキュメントも思いっきり書いてるし >>945
まあ大多数の人はそうしてると思うけどね
ただモデル側に書いた方がシンプルなコードにできるってだけでそれでマウント取るのはホント意味わからん LaravelどころかMVCを全く理解してない奴がゴロゴロいるんかこのスレ
だめだこりゃ MVC理解していないのってお前らの大半やろ
Modelに関する処理をModelに置けば
Controllerは何やっても問題無いやろ
それを何の根拠も無くファットコントローラーｗとか言っているのだからｗ
それ外に追い出したらコントローラーの記述が減ってるだけやろｗ ところでお前らLivewireかinertia使ってる？ >>949
落ち着け。それでログ読め。ファットコントローラーを頭ごなしに否定しているのは1人だけだぞ。 Webサービスでの画面遷移について質問があります。
画面Ａ →(POST)→ 画面Ｂ →(POST)→ 画面Ｃ
と、遷移させたいとします。
で、画面Ｃで受信したPOSTデータにエラーがあったら画面Ｂに戻りたい。
このとき画面Ｂでは、画面Ａから先にPOSTされたデータと、画面Ｂで先に入力した値を再表示させたい。
そこで質問ですが、
・画面Ｂや画面Ｃでは、受信したPOSTデータをセッションに保存するように作るのでしょうか？
・画面Ｃから画面Ｂに戻るには、redirect()を使うべきか、それとも $this->画面Bのメソッド(); を呼ぶのがいいのでしょうか？
教えてください。
お願いします。 そういう場合は、画面Bから画面CにPOSTするんじゃなくて、
画面Bから画面BにPOSTして、エラーが無かったら画面Cにリダイレクト >>952
ファットコントローラー否定派は俺以外に少なくとも1人いる。
MVCはMがアプリケーションでVとCは単なるUIなんだよ。Mにビジネスロジックは全部書く。UIがWebだろうがコマンドラインだろうが独立して動けるようにMを書く。
なのでバリデーションやDBアクセスはMに書くべきで、Cには認証やらGET/POSTの処理やらクッキーアクセスetcを書く。
それが本来のMVCだが、Laravelのドキュメントが違ってるなら、厳密なMVCを目指してはいないのだろう。別にMVCだけが正解なわけでもないから。 まー、955が正解だわな。
949みたいなオレオレMVC論を唱える奴がいるところが、ららべらーの次元の低さを如実に表してるな。 >>955
いや、「頭ごなし」に否定してる人はってことね。MVCちゃんと理解して設計してねって話をしてる人が大半だと思ってて、ファットコントローラーはその設計に失敗した結果だからダメって言ってると思うんだよね。
俺が書いたのは>>888や>>918ね。 バリデーションがMって違和感があるんだけどそんなもん？ >>958
LaravelはControllerかその手前のFormRequest、 RailsやCakePHPはModelでやってた気がする。 俺はCakeを触ってたからバリデーションをControllerでやってるLaravelのドキュメントに違和感ある >>957
MVCちゃんと理解して設計したら、ファットコントローラーにはならないというのがMVCの思想なんだけど、違うか？ >>961
そんなことはMVCのオリジナルの論文には書かれてなかったと思う。
元々は、ユーザーのメンタルモデルに沿った形でアプリケーションを再利用しやすいよう分割しようってだけの話だったかと。一体何を読んでその理解に至ったんだ・・・。
↓オリジナル
https://www.semanticscholar.org/paper/The-Model-View-Controller-(MVC)-Its-Past-and-Reenskaug/ff2ada602c96499c0f8a634e26c2c58ef8ec490f >>962
何を読んでって、Skinny Controller, Fat Modelってあちこちで言われてきたじゃん
と思ったらこれってRailsの話で結構古い記事なんだな、今の人は知らん＆また違うのかも知れんな >>962
オリジナルって何だ？MVCの概念自体は1970年代からあるものでその論文？はそれを研究してまとめたものじゃないの？
コンピューターサイエンスにおけるMVCにファットコントローラーの話は出て来ないかも知れないが、
ここではWebフレームワークにおけるMVCの話をしてるんだと思う 捨て垢でもいいのでQiitaに持論をまとめてほしいです Skinny Controller, Fat Modelでぐぐるとキータすぐ出てくるやん
今まで散々議論されてる話題だし >>964
・MVCそのものにはFat Controllerなんて概念は含まれていない
・Rails以降WebアプリケーションでMVCが使われ出して、正しくない実装によるFat Controllerが問題視されるようになった
てことなんかな
でその後果たしてFat Modelって本当に正しいんだろうか？という議論が起こり、EntityやらRepositoryやらに分割したり、
Webアプリの実装に特化したLaravelではRequestにバリデーション機能を持たせるようになったりしてると >>968
MVCていうとJavaはstrutsとかもっと前からあるし、PHPならMojaviとか。Railsはもっと後発。初期のMVCフレームワークは、原則に従った結果としてcontrollerの役割が肥大化する傾向が指摘されていた。
railsあたりで色々変わったんだよね。入力値の検査をなぜかmodelでやるようになったり。
Laravelはrailsリスペクトなのに、例えば入力値の検査は オリジナルのMVCの原則に従ってたりする。
なのでMVCの原則通り設計してもファットコントローラーはあり得る。あとはフレームワークのベストプラクティスに従うかどうかに依存している。だから>>918のような言い方にしないと人によっては反発されてしまう。 > LaravelではRequestにバリデーション機能を持たせるようになった
Controllerにバリデーション機能を盛り込む
Modelにバリデーション機能を盛り込む
Requestにバリデーション機能を盛り込む
全部やってる事一緒じゃん。
なんで、バリデーションを行う専門のアーキテクチャを実装しねぇのか頭かち割って苺シロップかけてた方がいい。 LaravelにはFormRequestていう専用のクラスにバリデーション関係を切り出せる。>>968が言ってるのはおそらくそういうこと。
だから「全部やってること一緒じゃん。なんで、バリデーションを行う専門のアーキテクチャを実装しねぇのか頭かち割って〜」て発言の真意が、ちょっとよく分からない。 >>971
結局それはRequestにバリデーション機能を盛り込むってことだろ？ >>972
はて。話が通じていないような？Requestにバリデーション機能を持たせるって言葉をどう解釈したのか知りたいなぁ。 横だが俺も>>970が何言ってるのかわからない
そしてそれは>>970のせいだと思う バリデーションはモデルに書くようにしないとCLIで必要になった時困るぞ
その必要が絶対無ければFormRequestでできるのは便利だとは思うが… Laravel動かすならapacheの方がいいでしょうか？
ほぼ動的コンテンツになる気がするのですがnginxでLaravel使ってる人も多いようで迷います 素人はapacheにしときなされ。nginxの場合それだけでは動かないからphp-fpmあたりも組み合わせなきゃいけない。 >>978
どちらかというと今までnginxばっかり触っていてapacheは初めてです 今どきQiita見りゃnginxの設定くらい余裕やろ じゃあnginxで良いじゃん。どこからapache出てきたの・・・ >>981
nginxは基本的に静的コンテンツに強いサーバで本来phpのような動的コンテンツを動かすようなサーバではないです
動的コンテンツは基本apacheなので自分もapacheにしようと思ったのですが調べたらLaravelで作られたサービスは
nginx上で動作させていることが多いと分かったので疑問に思って質問しました。 マジレスするとLaravelはnginxにあわせて最適化されたフレームワークなので
政敵コンテンツが特異なnginxであってもLaravelならnginxを使ったほうがいい フレームワークにApache向けとかnginx向けとかあるの？何が違うの？ 大体ApacheなんてApacheの方が使いなれてる、xamppで手軽に環境が整う、どうしても.httaccess使う必要があるくらいの理由以外で選ぶ必要がない 表向きはnginxバックエンドでapacheの中でlaravelをうごかせばOK 特殊な事情がないかぎりは
今どきApacheを積極的に使う理由は何一つないと思うが >>988
> 今どきApacheを積極的に使う理由は何一つないと思うが
何故？ 設定が簡単で.htaccessも使えるからApache使ってるわ Apacheの方が情報量多いし馴染みがあるからなぁ
XAMPPなんかでローカルでも使えるし このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 39日 8時間 23分 12秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
