【PHP】Laravel【フレームワーク】 Part.8
■ このスレッドは過去ログ倉庫に格納されています
>>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だけで良いじゃない ■ このスレッドは過去ログ倉庫に格納されています
