元スレ【PHP】Laravel【フレームワーク】 Part.5

php覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

101 = :

>>86
Cakeだと何するにも有志の作ったプラグインを探して入れるのが当たり前だったが
Laravelだとデフォでなんでも入ってるのがいいと思った

102 = :

Laravelの場合公式のマニュアルが有用なので、本なんか要らないと思うぞ。

103 = :

今年出る9がLTSだから、それに合わせて数冊本は出るだろうね

104 = :

でも機能的にはcodeigniter4に劣る気がする

106 = :

>>104
例えば何？

107 = :

>>90

おれ、Laravel って使った事なくてさ、
Rails、Cake、CodeIgniter でも、簡単なプロジェクトなら別にどれでもいいんだよな。所謂『WEBアプリ』って言ってるレベルの物。
これが、『WEBシステム』になったときに Laravel プロジェクトだとどうなるのかな？　と思ってさ。
例えばWEB業務システムERPです、管理画面です、大メニューが10個、サブメニューが全部で50個、アプリケーションとしてのエントリポイントは総計で1000個超えます、
みたいになった時に、
Laravelプロジェクトのディレクトリ構造、どうなるんだろうな？　と思って。
それが『laravelは基本的にdirectory構造を自由に設計できるって聞いた』を上げた理由。
Rails、Cake、CodeIgniterあたりでやってると、確実に崩壊するんだよな。
そういう用途で使ったLaravelプロジェクト、見たことある奴居る？

108 = :

ただまぁ、Laravel も 8 にもなって、流石にそろそろ安定してきただろうから、
いい機会なので使ってみようかとは思ってるんだけどな。
今、身動き取れない状態だから時間割りとあるし。
4とか5の頃から『しょっちゅう仕様変わる』って聞いてたから、
必要性が無い間は触らなくていいや、って、今に至ってる。

Vue.jsの最初のヴァージョンも、使い始めてやっと覚えたってところで、
2 になると仕様がごそっと変わります、とか言われて『えー！？』ってなってそれっきり。
実は、正しい使い方してれば jQuery が最強なんだよ。（データバインディングを考慮しない場合）
結局、実装してる奴が無知・無能だから大抵崩壊してるだけだからな、どのプロジェクト見ても。

109 = :

>>107
それは単に、たくさんの機能を追加するうちにFWの想定してない例外的なフォルダー構成にせざるを得ないケースが出てきてるだけであって、規模と本質的に関係ないことじゃないか？

110 = :

エントリポイント1000超えるシステムをモノリシックで運用するのが辛いみたいな話になるから、Laravelであっても他のFWと大して変わらんだろとしか。

111 = :

公式のマニュアルが優秀って話があるが、
日本向けの公式マニュアルは情報が遅れてないか？

勉強しようと思って見たら、1バージョン過去のもので諦めた覚えがあるわ

112 = :

>>111
8もあるぞ。まぁオススメは英語マニュアルをgoogle翻訳かけて読む事だけども。8のマニュアルも何度か改訂されてるから、日本語の非公式マニュアルは少し遅れている。

http://readouble.com/laravel/8.x/ja/installation.html

http://readouble.com/jetstream/1.0/ja/introduction.html

http://readouble.com/livewire/2.x/ja/quickstart.html

113 :

>>109

まぁ、そのとおりだな。
システム開発って結局、作ってるうちに、運用してるうちに、コロコロ仕様変わってくし、
システム作る事が目的じゃなくて作ったシステムで世の中を便利にしてく事が目的だから、当然、そうなるんだよな。

そん時に、結局、最初にどんだけ柔軟性を考慮して設計したかが全てです、ってなるなら、
やっぱ、Laravel も他のフレームワークと五十歩百歩じゃん、てなるんだよ。想定してるシステム規模がでかいと。

114 = :

このスレでそんな話してもな
何がしたいんや？

115 = :

だから、みんな『良い』って言ってんだから、良い事は間違い無いんだろうけど、
世間の皆さんって、PHPでデカいシステム作る事あんまり無いからさ。大体そういうエンタープライズ用途は『Javaです』とか言って何十人規模でコードがゴミ溜まりみたいになってんじゃん。Javaって、何するにもめんどくさい言語だから。

もぅ、そういうの、辞めねぇ？って思ってんだけど、まぁ、無理なんだろうな。

117 = :

>>116
Laravelは魔法の道具でないぞ

118 = :

速度面ではあくまでインタプリタだし昔に比べたら早くはなったけどLaravelは速度とかよりは開発のしやすさの方を重視していると思うので
どうしても高速でないと駄目とか言うなら選択肢には入らないのでは？
どっちにしてもDBに接続するならそこまで速度がどうのこうのは関係なさそうだけど

119 = 113 :

>>118

いや。Twitter作りたい訳じゃないから、Javaの速度は、ほとんどの環境では流石に要らないよ。
一般的な用途なら、PHPのJITコンパイラで十分になるだろうって話。

120 = 113 :

>>117

やっぱ、そうなるか。
そうすっと、小さいWEBアプリ用と割り切って使うのが結局のところの正解になるんだろうな。

121 = :

日本語マニュアルはページ内リンクもないし読みにくい
本家と同じデザインでレイアウトで文章だけ若くに差し替えるだけのほうがメンテナンスしやすそうな気もするし
本家に取り込んでもらえる気がするんだよな

122 = :

それなりの規模は作れると思うけどね
Laravelじゃないけどグラブルみたいな超絶にアクセスがあるゲームですらPHPで捌けているし
アプリケーションサーバーはロードバランサとかで分散できてもDBはそのへん中々大変だろうから
結局はPHPというよりインフラの設計とかそっちも重要かと

123 = :

お前らって英語わかんないの？
日本語だけで技術者なんて、やっていけないと思うんだけど

124 = :

十分やっていけますよ

125 = :

ジャップランドはIT技術後進国
低レベルしかいないし、この先どうなんだろ

126 = :

>>120
どんなFWでも、その規模になると設計する側の腕次第だぞ。一方でLaravelの場合バージョンアップへの追従が大変という側面を忘れてはいけない。Laravel-shiftである程度楽はできるだろうけど。

大規模案件でパフォーマンスを要求されるようになるとそれはそれでツラミがあるけど、OPcache前提ならそこらのFWと大して変わらんだろ。

その上で最近ベータリリースされたlaravel-octaneがswooleやroadrunnerを簡単に導入できるパッケージなので、速度面はむしろ他より速くなる可能性もある。

127 = :

きみあちがよく使うライブラリを教えて下しあ

128 = :

中央区の図書館は良く行くな

129 = :

Laravelで開発した有名サイトってどれ？
ランサーズとかBASEがCakeなのは知ってる

130 = :

知ってどうする？

131 = :

どういう設計か確認したい。URLからでもだいたいわかるし

132 = :

> ランサーズがCakeなのは知ってる

しょっちゅうバグってCakeのエラー画面出るからな。
あれ、エラー画面変えられないんだっけ？

Apacheのエラー画面そのまま出てるのも脱力するけど、
Cakeのエラー画面も似たようなもんだな。

133 :

>>132

ごめん、ランサーズの事、間違えて悪く言った。
おれが指摘したかったのは teratail の方。

あっこ、システムエラー、多すぎ。
ランサーズはエラー画面出てるのは見たことないな。
秋好さん、結構がんばってんだなぁ…、と思うわ。

134 = :

>>132
普通にエラー画面変えられるよ
デフォルトが出てくるのは、単に設定してないだけじゃないかな

135 = :

>>134

ですよねー

136 = :

エラー画面変えられないフレームワークはヤバいだろ

137 = :

本番環境でフレームワークのエラー出すとか考えられんだろ
phpのエラーも非表示にするし、一度もそんな所でミスったことないわ

138 = :

本番環境と開発環境ってそれぞれにファイルアップロードしないといけない？

139 = :

>>137

盛大な teratail ディス、ありがとうございますｗ

あっこ、技術者のコミュニティを謳ってるはずなのに、
運営が技術力全く無いですって、
ちょっとひど過ぎるわ。

141 = :

できないよ。複合主キーサポートすべきだｔってissues作られたけど却下された
http://github.com/laravel/framework/issues/5355

142 = :

大人しくサロゲートキー使っとこ。

143 = :

テラ何とかって質問自体異様にレベル低くてその割にまともな回答も付いてなくて
検索の邪魔になるだけのクソサイトだよな
ぐぐってもURL見て開かずに自然に避ける癖がついちまってる

144 = :

.envコミットするしないで議論に決着がつかなかったこのスレほどではないわｗｗ

145 = :

あれは単に愉快犯に荒らされてただけだろ
本気でコミットしようとしてる奴なんておらんよ

146 = :

.envをコミットするという発言に対して誰も論破できないのは草だった
それぐらい論破しろよ・・

147 = :

実際.envをコミットするという発言を論破することって不可能じゃないか？

148 = :

負けを認めない奴を論破するのは不可能
安倍や自民党見てるとよくわかるだろ

149 = :

.envはコミットしたほうがメリットデカいと思うけどな
node_modulesやvendorコミットしているやつは馬鹿だけど

150 = :

いや.envをコミットするやつはアホ
node_modulesやvendorのコミットはむしろ推奨
なぜならnpmやcomposerで外部からパッケージを取得できない環境でも
アプリを動かすことができるから

前へ 1 2 3 4 5 6 7 8 9 10 11 12 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ

類似してるかもしれないスレッド

• 【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.6 (745) - [98%] - 2021/6/21 6:30
• 【PHP】Laravel【フレームワーク】 Part.12 (314) - [96%] - 2023/1/30 18:45
• 【PHP】Laravel【フレームワーク】 Part.10 (446) - [96%] - 2022/6/6 19:30
• 【PHP】Laravel【フレームワーク】 Part.4 (460) - [96%] - 2021/4/4 4:00
• 【PHP】Laravel【フレームワーク】 Part.3 (983) - [96%] - 2021/2/12 4:00
• 【PHP】Laravel【フレームワーク】 Part.2 (917) - [96%] - 2019/9/10 9:15
• 【PHP】Laravel【フレームワーク】 Part.11 (870) - [96%] - 2022/8/28 15:45
• 【PHP】Laravel【フレームワーク】 (887) - [84%] - 2019/4/23 21:00
• 【PHP】フレームワーク Akelos (129) - [56%] - 2019/5/9 7:46