【PHP】Laravel【フレームワーク】 Part.8
■ このスレッドは過去ログ倉庫に格納されています
>>679
そうだねマニュアルで事足りるからコードを読んだことはないかな
それはプロジェクトに参加してる方々が色々考えて設計が行われたり
充実したマニュアルがある結果なんだよ
なのにそんな人たちの苦労も無視して何のリスペクトも無しに君は
> だからcomposer嫌いなんだよ
> もう何でもかんでもcomposerで入れるようになってるからcomposerが動かなくなったら詰むのに割とよく動かなくなって詰む
こう言ったんだよ、これってとても酷いことだと思わない？
そんな人にどうして対等に会話したいって思えるんだろう
もうこの件に関しては書き込まないから君の勝ちでいいよ
最後に君の言うたまたまがどの程度の事を言っているのかわからないけど
俺は少なくとも3桁回数はインストールしてるしライブラリ作って公開したりしてる
だけどインストールできない時に原因があるのは必ず自分側で
composer側の不具合だったことなんて無い
ここまで言ってわからないのであれば
この職業向いてないと思うから別の職業を模索した方が君の為になる
決断は早い方が選択肢増えるから一度考えてみてね >>680
どう考えもcomposerの不具合だろ issuesにあがってるし composerのバグのせいなのに会社や顧客は修正を待ってくれない
待ってくれないどころかcomposerの存在なんか知らない
すべてアプリ開発者のせい issueがーー！言ってるやつは具体的にどのissueがやばいの？
いくつあるとかそんなんはあまり意味ない composer使えないくんの問題をエスパーするとlararelのバージョンは上げずに他のものだけバージョン上げようとしてるとかだろ多分 就職活動のバグのせいなのに親や兄弟は就職を待ってくれない
待ってくれないどころか就職活動の存在なんか知らない
すべて俺のせい >>684
issueってのは、要望もあるけど大抵は利用者から見て謎エラーなわけ
別にどれがやばいって話じゃなくて「そもそも謎のエラーwなんて無いしw 」って言うなら全部解消して還元してやれってのが、OSS利用者ってもんでしょ issueガーて言ってる人居るけど、あれらは根本的にソフトウェア側の不具合と認定されたものでもない。特に長い間残ってるやつてのは大抵他の人間では再現不可能なもの。
だからissueをピックアップして解決してみろとかいう反論はお粗末すぎると思う。 >>689
bugタグ付いてるのがあるだろ
お前はホントバカだなぁ >>680
わかったcomposerの開発者や提供者には敬意を払うよ
でも人が作ったものに完璧なものなんてないし不具合に悩まされたのも確か
特にバージョン1の頃は完成度低かったと思う、2に移行する時も問題起きた
【エンジニア用語解説】
「完全に理解した」
製品を利用をするためのチュートリアルを完了できたという意味。
「なにもわからない」
製品が本質的に抱える問題に直面するほど熟知が進んだという意味。
「チョットデキル」
同じ製品を自分でも１から作れるという意味。または開発者本人。
俺はなにもわからない人だが、完全に理解したレベルの人がここには多そう >>690
誰がbugタグの話しているんだ？俺はissueの話をしてるんだが？issue = bugではないってことを言ってるのだけど、お前は理解できないんだな。バカはどっちだよ？ >>692
issueの中にbugとしてソフトウェア側の不具合と認定されたものが少なからずあるってことだろ
ごちゃごちゃ言ってないで解消してこいよアホ
反論がおそまつすぎるわ 嫌なら使うなw
それで終わる話
使いたい奴だけ使え PHPエンジニアやっててcomposer使わないって無理じゃないの >>695
嫌ならプルリク出せ
がまともなエンジニアの発想 >>696
遊びじゃないんだからそんな悠長な事を言ってられない
やはり自社フレームワーク回帰しそうな流れだな
WEB系は開発環境を特定のバージョンで構築できない
一度選んだらその開発環境の最新（もしくはサポート内の）バージョンを追い続けるしかない
セキュリティはともかく開発環境すら再現できないのがWEB系の弱点
VB6なんていまだに開発できるのに・・・ >>967
開発環境ってOSの事？ライブラリとかの事？php の事？
いずれにせよ全部固定バージョンで開発可能なんだけど、そういう事がいいたい訳じゃないのか？ おい>>967聞いてるか？壮大な前フリが投下されたぞ 安価も付けられない奴って普段から手動でやらなくていいこと手動でやってミスばかりしてそう 一体何なの？昨日からの流れは
もしかしてこのネタでR-1出ようとしてんのか？
一回戦落ちになるからやめた方がいいぞ composerのおかげで楽になったよ
ほんとありがたいわ symfonyは脱composerを目指しているみたいだけど
symfonyベースのフレームワークであるlaravelもそのうち脱composerしちゃうのかな $curl- コマンドだけでインストールできると思ってたら
それに加えて「composer install」が必要ってことを知り悩みが解決した俺が通りますよ >>709
複数のlaravel動かしたい場合どうやってインストールするつもりだよw composer自体はaptでもインストールできるよ
composerで管理できるパッケージはaptからはインストールできないよ
なぜならaptが使えるプラットフォームは限定されているから composerの役割を分かってないやつが居るようなw symfonyはそういえばaptでインストールできたな VagrantとDockerだとどっち使う事が多い？
俺は100%VagrantでDockerは使ってない Windowsで直環境 AWSのt2.medium Docker良いね。逆にvagrantのメリットは？ Dockerはかなり前にWindowsに入れようとしてうまくいかなくて
それ以来積極的に追ってないのが現状なので
OS含めたほぼ同じ環境構築ができる
どのPCだとしても同一性が担保されてる
複数台立ち上げてローカルPC内でサーバー間の通信テストができる
この辺が可能なら乗り換えたいかなーと
Vagrantはとにかく重いのよ
特に案件毎にbox作ってるから容量も食うし >>716
面倒くさいからwindowsならvagrantの方が楽
homesteadあるし MacだがVagrant+Paralles+CentOS7がお気に入り
Dockerでも良いんだけれど、Macだとボリュームマウンとすると
パフォーマンスが出にくくて使いにくいし、
本番環境でまだDocker導入できてないのもあるし
Dockerの手軽さも魅力的だけどね WinでDocker Desktopてやつ使ったけど、重くて不安定でイマイチ ただ一つだけ、シンボリックリンク張れないのだけなんとかならないすかね あれ？Vagrantって言ってる人はhomestead？ >>723
Windows環境で/vagrant以下でシンボリックリンク張ろうとするとコケるのよ コンポーサークソダーコンポーサークソダーコンポーサークソダー windowsにvirtualbox+vagrantで作った仮想環境にDocker入れてLaravel動かしてる >>727
特にない
Dockerの勉強したかっただけ dockerの仕組みがいまいちわからないんだけど
その時使ってるコンテナにredisが足りないってなったらコンソールで入れて
エクスポートみたいな事する感じなの？ 開発環境作るだけなのに面倒くさいよな
その点xamppはよかった
なんでこんなにやること増えたんだろう vagrantならboxエクスポートするか
provisionの時スクリプトで入れたりする
>>730
構築にかかるコストを最初に払うかデプロイ時に払うかの違いかなーって思ってる
デプロイ時にミスった時の方が圧倒的にコスト上がるから俺としては助かってる homesteadなら最初はboxのダウンロードなどに時間がかかるけど
XAMPPとかでLaravel動かすよりは遥かに楽かと
これで環境作れないようなら厳しい
xdebugの設定はまた別にいるけど DockerでOSごとイメージをAWSにデプロイするのがいいのか
LaravelとかのソースだけAWSのAmazonLinux2もしくはubuntuにデプロイするのがいいのか
決めどころがわからんのだけどみんなどうしてるんですか？ スクリプト言語なんだからgit pullだけで良いじゃない >>733
試してないんだけどvagrantの機能で手元にあるboxをEC2にprovisionできるぽいのよね
けど最近はlaravel forge使ってるけど
圧倒的に管理が楽になった
>>734
エクステンションとか、付随するサービス(supervisorとか)の設定とかその辺りは自動でやりたい >>733
そもそもサーバーレスにするかしないかみたいな話だから、Laravelとは別問題かと。個人的にはEC2に慣れてしまってるせいでそっち使ってるけど、次のプロジェクトはサーバーレスにしよっかて思ってる。 >>735
そういえばforgeあったね
料金高いけど
>>736
サーバーレスってLambdaだとデフォルトではphp対応してない
どのへんをサーバーレスって言ってる？
サーバーレスは曖昧な言葉だから >>737
俺もphpってLambdaで使えなかった気がしてちょっとググったら
サーバーレスLAMPスタックってアプローチ方法でLaravel動かせるって初めて知った
けどコスト考えたら怖くて使えないかなぁ
Lumenにして超軽量仕様にしてから検討のテーブルに乗せるレベル >>738
サーバーレスはそもそもLaravelとかには向いていない
Laravelから切り出した軽量なファンクションで処理順を担保しないものをLambdaにすべきでサーバーレスの仕様に合わせた設計が必要 >>739
ああ、そういう意味でいうと今作ってるやつが
フロントでリクエスト受けてSQSにキュー入れるだけのマイクロサービス仕様だから
考えてたイメージで認識は合ってるはずよ >>737
ECSのことだよ。dockerの話してたでしょ？ >>738
lambda使うならbrefと組み合わせるか、有償だけどLaravel vapor使うんじゃないかな。後者は海外だと商用サービスで使われているはず。ただ今回は単にdockerから繋がってる話だから、サーバーレス=ECSのつもりだったよ。 >>735
laravelタスクスケジュールじゃダメなの？ >>741
なるほど、了解
サーバーレスは意味が広めだから最近悩む Supervisor使ったりSQS使ったりってLaravelじゃなくても良いんじゃないの？
非同期実行自体はPHP8.1でFiberが採用されたら良いなあって程度の状況だし >>746
処理したい内容によって何使うか決めるのも仕事だと思うけどJavaかPythonになるんじゃないかな >>745
うん？Laravelのキュー使った実装はそれ専用の解説書が出ている程度には海外でも使われている
日本だとオープンロジがLaravelキューで実装しているよ
Fiberみたいな話とは根本的に違うでしょ、非同期処理したいわけじゃなくてCQRSアーキテクチャで実装したいのでは？ CQRSならSpring Bootでチャチャっと作っちゃうんじゃない？多分 >>740 は俺が書いたんだけどSQS使う基本的な理由はこれ
もう一つの理由が能力不足と怠慢だろって話なんだけど
Laravel(php)で作った完成物のクオリティを他言語で担保できないってのがある
やっぱりphp3から使ってるだけに言語そのものに対する理解度が他言語とは比べ物にならないから
他言語だと正常に動作するものは作れたとしても
自分が納得できる品質の完成物を作成できる自信がないのよね >>751
わかる
俺も手続き型言語なら何でも良いとは思ってるけど
特定の言語に詳しくなるほどその罠にはまるんだよなぁ
フレームワークもしかり >>751
すげぇよく分かるw
ただ、マイクロサービスとかのインフラとphpってあんまり相性良くないんだよなぁ >>753
さすがにそこまでは行ってないけど
中学の入学祝に中古のPC-9801VM2買ってもらったくらいの年齢よ >>752
>>755
共感してくれる人がいた！ありがてぇ
スキルが足りないなら勉強しろって煽り散らかされるかと思った >>755
高校の入学祝にX68000買ってもらった俺より上か ここって極端に若いかリタイア目前のジジイしかいないんじゃ PHPでダイナミックプロパティ禁止でタイプヒンティングも書いてるなら
他言語いっても同様の品質で書けるしむしろ見通しよく書けるケースも多い
昔のスタイルのままなら手を出さないほうがいい >>756
それで煽るやつが居るとしたら、まともに一つの言語を極めたことないやつだと思う
スキルシートとかで、複数の言語に最高評価つけている奴いるけど、全く信用できないなっていつも思ってる >>759
そんなレベルの話じゃないと思うぞ
phpならキャラクタコードを気をつけなきゃいけない関数を熟知してるけど、他言語だといちいち調べ直してそれでも不安とか
phpならjson_encodeそのまま使うとRFC準拠してないの知ってるけど、他言語だといちいち調べ直してそれでも不安とか
多分そんなレベルの話 >>761
それな
言語の癖みたいなものまで熟知してしまってると、
単にシンタックスが似てるからといって
同じような品質でコードを書けるて思えないんだよな
まぁ実際はそこいらのエンジニアよりマシなコード書けるんだろうけど 例えばこういう部分って他言語との違いを考えたんだけど
他言語でそこまでちゃんと理解してる言語がないから
そもそも例とか出せないんだったわ
例えばPHP限定での例で、配列を連結する場合
$arr = [1,2,3] ;
$arr1 = array_merge( $arr , [9,8,7] ) ; // 大体こっち使いがち
$arr2 = [ ...$arr ,9,8,7] ; // こっちのが早い PHP7.4以降
こういうやつ phpってjavascriptっぽくなってきたよな spring bootでlaravel書いたほうがいいような気がしてきた >>765
それはspring boot以外知らないからそう思えるんじゃない？ いま世界で使われているフレームワークのシェアNo1がspring bootなんだっけ？
そんなにいいフレームワークなのかな？ いいと言うよりオブジェクト思考で作るサービスを提供・利用するのに言語的にJavaが向いてて割と簡単に導入しやすいとか
利用者の多い言語だから欲しいライブラリが既に作られてるとかそんな理由だと思う。
百人以上の規模で作る時に人を集めやすいとか JAVAが向いてる？
たまたま時代的なタイミングが良かっただけ
今更コンパイルしないと動かないようなものとか小規模にはマジでいらない
開発効率悪すぎでしょ コンパイルは透過的に動くから気にせんけど
IDEの支援があるとはいえコードが野暮ったくて使いたくない コードの野暮ったさを言ったらPHPが1番じゃないの >>769
spring-boot-devtools使うとコード変更すると即座に反映されるぞ これからLaravel使い始めようとしてるんだけどサラっとここ見たらハマりやすそうなフレームワークだね ここでJavaの話を出してるようなKYは職場でもKYなんだろう >>774
最近spring bootがphpの実行をサポートしたからじゃない？ ■ このスレッドは過去ログ倉庫に格納されています
