【PHP】Laravel【フレームワーク】 Part.8
■ このスレッドは過去ログ倉庫に格納されています
>>473 cakeなんかはクソ雑魚が実装したらセキュリティホールだらけになるじゃん?Laravelは雑魚が作っても問題が起きにくいから大丈夫じゃね? POSTのときはCSRF強制されるし、eloquent使えばSQLiも起きにくい。bladeを普通に使ってりゃXSSも防げる。ハッシュ化もHASHファサード使えば、ソルトとストレッチングもお任せだしな。 認証も標準の使ってりゃ、セッション固定の問題も起こさないだろうし。 cookie周りのデフォルト値が若干緩い気もするが、まぁ無知なやつでもある程度のセキュリティは確保できてるでしょ。 8使ってる方はわかってると思いますが 今のバージョンではもうuiは使いませんよ 使うことはできますけど >>468 使えています。 >>469 >>470 そうなんですね。 階層変えて試してみます。 ありがとうございました。 Laravelは学習コスト低いのがいいやね オレンジ色のサイトも1日あれば読める PHP自体のを除けば罠も少ない しかし、Laravelはフォルダ・ファイル構成がぐっちゃぐちゃだな…。 Bladeは、ちょっとした物をつくるには手軽で便利かな。 templateの中で直接PHPのクラスを扱えるのは便利。 機能性ではやはりTwigFunctionやTwigFilterのあるTwigが何でも出来てパワフル。 テストはダメかな。 use書き忘れてClass Not Foundしてるはずなのにメッセージが握りつぶされて原因が分かりずらい。 Migrationは全然ダメだな。 foreign key制約とかでQueryException発生するとどうにも身動き取れなくなる。 rollbackもできない。down()だけ実行できないのかえ? 結果、手動で追加したカラム削除しかなさそう…。つらみ。 うーん、AuthがControllerで提供されてるのか。 それこそServiceで提供すべき機能じゃないのかなぁ…? うーん、入力値のバリデーション時に一緒に既存ユーザのメールアドレスのuniqueチェックまで一緒に行うのか…。 「便利でっしゃろ?」ってつもりだろうけど、それは一緒の概念じゃ無いぞ…。 バリデーションって不正な入力値を弾く為の物であって、登録済みのmailaddressは別に不正な入力値じゃないぞ…。 というか、リクエストのバリデーション中にDBにアクセスするの、キモい。 >>486 バリデーションはこう実装すべきだという仕様を決めようとしている国際標準策定委員会だと ユニークチェックもバリデーションの一種として含まれているぞ といっても2015年ぐらいまではこの委員会もユニークチェックはバリデーションでやるべきではないって意見だったけどね >>483 まじで?俺の開発環境だとテスト時のClass Not Foundも出力されるぞ? といっても自分のバージョンはlaravel6での話だからlaravel8だとでないのかな? >>484 djangoも確か結局全部消して作り直すのが早いって結論になってしまった気がするし、Laravelに限った話でもないような? そもそもそんなエッジケースを挙げて、migration全然ダメて結論導き出せるのある意味凄いな。 なんとなく気づいた。 Cakeはarray地獄だったけど、Laravelはcallable地獄なんだ。 こんにちはっす。今日も予定開いちゃったのでLaravelいじってます。 >>488 それ、どうなんだろう? あんまり賛同できねっす。 >>489 こっちも6.20.34なんだけど、ダメなんすよ。 Requestクラス継承したバリデーション用のクラスをuseしてなかったんすけど、 ✘ Status should be within defined numbers ┐ ├ Session is missing expected key [errors]. ├ Failed asserting that false is true. だそうっす。しばらく悩んだっすよ。 >>490 いやいやいやいや、だって、既にあるMigrationファイルのdrop()メソッドだけ実行させてもらえればそれでいいじゃないっすか。 あと、そのためにDBのトランザクションがあるんだからExceptionでrollbackじゃないっすか。 おかしいっす。絶対におかしいっす。 新フレームワーク作れないのは勿論のこと課題解決パッチを作ることすらできない人 ほー、middlewareって何なのかようやっと分かったけど、名前悪いよなぁ…。 基本的にLaravelは色々なところで命名下手くそなんだよなぁ…。 うーん、完全にRails臭がしてきた。敷かれたレールに沿ってみんな同じコードを書こう!というスローガンが聞こえる。 Mailのbodyについて、view内のファイルを使うのは無理筋じゃないかい? 絶対ちがうって。 にゃーるほど。まぁ、Auth周りはRailとしては不完全だなぁ。 だからバージョン上がるたびに新しい認証機構が実装され続けてるのか。 >>497 なに言ってるかイミフだが、無理筋でもなんでもない Eloquentを一切使用しなくなったけどバリバリ使ってる人のほうが多いの? 複雑なリレーションもモデルで行ってるの? >>492 javaのフレームワークでも全部消して作りなおせって結論ですね >>486 今世に出ている大多数のフレームワークはバリデーションでユニークチェックすることになってるな javaのsprng frameworkについてはバリデーションじゃなくて自分でユニークチェック実装しろって方針だけど Laravelのソースを読み込んでみましたが結構酷い作りですね・・ 例えばどこ? 酷いっていってもオープンソースだからissueで指摘されて直すもんだよね? このフレームワーク、完全にcakeの劣化じゃん・・・ アンチオートインクリメントおじさん、Laravelくさすのが目的になってるから、だいたい針小棒大な欠点の指摘ばっかりになるし、他のフレームワークでもそうなっているってオチなんだよな。 >>491 地獄っていうほどの実装にはまずならないと思うけど、実コード見たいね。書いてるやつのスキルの問題な気がする。 気に入らないなら使わなきゃいいのに 文句言うためだけにソース見るとか気持ち悪い奴だ >>498 まるで完全なauthとやらを知ってるかのような言い方だな。具体的にどういう仕様なら完全なの? たとえCakeの劣化であっても、 Cakeより普及してるんだからLaravelを使うしかないと思うの Laravel使ってるとド素人認定されてバカにされる Rails使ってると時代遅れと言われる Django使ってると一目おかれfastAPIだと先進的と思われる expressだとプロだと思われる わけわからん。 railsはちょっと古臭いとは思うが… 何でDjangoだと一目置かれるん? どんなフレームでも極めれば一目置かれると思うが わりと>>520 の意見って業界のスタンダードな意見じゃないか? 使うものでプロだとかそうじゃないとか一括りにするやつが一番の素人だと思う その場合の道具とはエデイタなどのツールのことでしょ。建築の世界で言うと、フレームワークは、工法や造りに該当する。 作ることの本質は変わらないのだから、どのフレームワークを使っても、標準的なエンジニアよりも高い品質でものを作れるのが本当のプロフェッショナルというものだろう。 あと、運用フェーズでのチームの拡大や自分が誰かに引き継いで別のプロジェクトに移ることまで考えるなら、利用者の多いフレームワークを選ぶ方が合理的だよ。 Laravelはフレームワーク界のWordPressだからなあ Laravelでwordpress実装してくれたら面白いのにね WordPress → プラグイン多数 → データベースゴミ → セキュリティガバガバ → 初心者向け Laravelと同じだった >>530 君みたいなプロフェッショナルは何を使ってるの? Laravel使ってるっていうと恥ずかしいよな DjangoがfastAPIだろ 何が悲しくてPythonでサイト作らないといけないんだよ どういう理由でチョイスするのか興味あるわ 世界ではphp自体がもはや廃れていく方向 日本だけガラパゴス化 webはpythonかjs(node)が主流 ここまで具体例の無い批判してて恥ずかしくねーのかw Django使ってみたけど何でLaravelなら簡単に出来る事がこんなに面倒なの?と言う場面が結構あった。 複数のマイクロサービスを立ち上げるのに良いかなってくらい webをpythonかjs(node)で構築する案件の規模ってどれくらいが主流なの?ぴんきり? そもそも日本でwebをpython+djangoで始めるのはビジネス状のリスクがデカすぎるんだよね。趣味でやってろって思う。一番のネックは、エンジニアを市場から調達するのが難しくて、サービスが成長したときにすげー苦労すんだよね。過去2件ほどそういう残念なプロジェクト見かけたわ。 なぜ少ない日本のエンジニア市場でエンジニアを確保しようと思うんだろうか 世界中にエンジニアがいるのに 世界中のエンジニアって・・・ 発注した事あるのか? 言語の違い、生活習慣の違いがどれだけ完成物に影響出すかしらないだろ >>545 オフショア開発やったことあんの?どの国? インドとかいうんだろ? ラマダンの時に当たった時あんのか?お祈りの時間に会議になった時あんのか? ベトナムとかあの辺が最近多いらしいけど結局は意思疎通が出来る日本人の現地マネージャ次第かと すべてリモートは無理がある >>546 オフショア開発したこと何回もあるがブリッジエンジニアがいるし現地にも日本語話すPMがいるんだよ ていうかこんなの当たり前すぎだろ しかも顧客は日本だけじゃなく世界的にやってるところも多い Laravelerってこんなことすら知らないのか >>549 そりゃお前が底辺で参加してるからだなw 少しでも上流かマネジメントに関わっていれば、オフショアは地獄 オフショア開発で上がってくるのは出来の悪いモノが多い >>549 いや、俺はオフショア開発数年経験してるし、現地の会社数社の経営層と品質改善等に関して議論したこともあるが?ぶっちゃけ、オフショア開発本当に使ったことあるなら、そういう感想にはならないと思うんだが。 オフショアが良いか悪いか、モノと体制次第と言うしかない >>542 結局、日本のエンジニアが一番優秀で一番安い NECや富士通がオフショアで10年以上失敗続けてるのに なんでおまえがやれば成功すると思ったんだ? 複雑なアルゴリズムを含むようなものはインド人とかにやらせた方が良いんでないか?あと東欧とか数学気質のある所。 日本人だと面倒な事言ってきそう >>553 こちらも現地までいってるから知ってるけど経営者やPMは日本人または日本で10年以上働いていた人 実際の開発は学生みたいな若いのが多いがピンキリ 品質低いなんて最初から織り込み済みで最初の準備と中間レビューで十分なんだが 任せっぱなしだとお前みたいにヒーヒー言うんだろうが >>558 あー、品質低くて当たり前の底辺に生きる人か。そりゃ会話にならんわ。品質の低さがビジネスの成長の阻害要因になることも分かってなさそうだな。 >>558 何の記事読んだんだよw 実際経験した事ないやつが書きそうな内容だな 学生さんかな? >>554 開発効率や内容の話をするのがエンジニアってもんだが、 ここの奴らはそれ以前の段階だからな Laravelが良いか否か、必要か必要じゃないかって、ここで話すようなことかよ いやそれだとQuoraになっちゃうから、ここはこれで良い 具体的な話をするとQuoraになるからこのままでいい指摘すら意味が分からない なんかLaravelerが変な方向でモめ始めて訳わからんけど、ヨシやれ! >>562 この内容が飛躍しすぎだと思っている時点でわかってないね >>566 低くなりがちだからチェックして事前準備して中間チェックで品質あげとるんだが? 読めねえガイジならレスすんなボケ 品質ってバグじゃなくて技術的負債の話なんだけどそれ伝わってる?オフショア開発の場合、負債の増加が早くてベロシティ悪化してくじゃん?中間レビューでそれを防ゲルと思ってるの? 負債ってなんだよ? こちらが設計した技術なのに負債もクソもないだろ おめえのところは検収すらしないのかよ ゴミ会社乙だな >>570 それはさすがに煽るにしても筋が悪いよ そもそも技術的負債は何にもしなくとも溜まっていくよ 根本的に練り直してから煽りなさいな やり直し >>571 検収することが煽りで筋が悪いってことか? 意味わかんねえんだが で技術的負債がゼロの開発を教えてくれるか? 技術的負債の増加が早いことを指摘しているのに、他のやつのツッコミに対して技術的負債ゼロの開発を教えろやって言ってるあたり、読解力も底辺なのかな? アホの集まりだな オフショアになるとなんで技術的負債が増えるんだ? 例えばLaravel8を選んだとしてどこに技術的負債が早くなるのかオフショア開発と日本の開発で比較してくれ 設計や技術選定は同じ指定だ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる