元スレ【PHP】Laravel【フレームワーク】 Part.6
php覧 / PC版 /みんなの評価 :
601 = :
半分くらいは実際に仕事で使ってそうだけど
残り半分は趣味とかやろな
602 = :
ここにいる全員がその半分に属してるんだよ
603 = :
ほんとにバカしか居ねぇなぁ…。
604 = :
お前だってそうだろ
605 = :
アプリ側で時間管理して超過したら強制ログアウトでええやろ
606 = :
>>596
ロードバランサ使ったりAWSで複数インスタンス使ってるような構成だとDBでセッション管理してると思う
だから今回のような疑問が出てくる時点でおそらくシステム構成を理解できてない
もしくは既存システムをいじりたくないのであれば別途監視アプリを作って常駐させる
C言語使えるならこっちのほうが楽かもね
607 = :
>>589
独自FW作るのはLaravel以前からやってる案件
cakeの頃に独自FW作るのが流行った
codeigniterに皮かぶせて独自FWっていってるのもあったな
とにかく一世代前の話
昔からやってる人は慣れてる独自FWで揃えたいっていうのもあるだろう
会社として複数FWを利用すると教育コストがかかっちゃうから一度採用したFWは変えられないという都合もある
ただ、新陳代謝が一巡してるであろう今の時期になってもまだ独自FWのままっていうのは
特殊な事情があるのか、もしくは開発者が入れ替わってない(高齢化)のか、もしくは開発者のレベルが低すぎて
言われたままやる人しかおらずもはやFW入れ替えなんていうことをするパワーがないのだろう
独自FWっていうのは下請け企業が他社に仕事を取られない為の難読化テクニックの一つ
608 = :
>>606
DBってリレーショナルDBのことか?
そんなとこでセッション管理しないだろ
今までの現場はほぼRedisだわ
609 = :
>>608
どっちでもいいんちゃう?
DBでも大して遅くはならんやろ
610 = :
>>608
インフラ設計したことある?IaaSとかで売上の立たない業務システム作るときは、月額のインフラコスト少しでも減らしたいからKVSじゃなくてDB使うケースはありえるでしょ。
わざわざセッションドライバやキャッシュドライバにDBが用意されているのはなぜか考えような。
613 = :
> ロードバランサ使ったりAWSで複数インスタンス使ってるような構成だとDBでセッション管理してると思う
↓
> IaaSとかで売上の立たない業務システム作るときは、月額のインフラコスト少しでも減らしたいからKVSじゃなくてDB使うケースはありえるでしょ。
615 = :
>>613
いやさすがに別人だろ…
同一人物だったら笑うが、ワッチョイ無いのが悔やまれるな
616 = :
>>607
自前FWでドキュメントもある所もあった。自前FWを作ったコストを相殺できるくらいには各種案件に使おうとしてるようだった
617 = :
>>616
独自FWだと下請けに出すときに困るんだよ
というか出された下請けが困る
つまりワイが困る
618 = :
独自FWはバージョン管理で破綻しやすい
パブリックなFWだと案件のほうをあわせるしかない
しかし、独自FWだとFWを案件にあわせていく
案件の数だけ枝がわかれた独自FWなんてただの悪夢だ
621 = :
>>613
何が言いたいのか詳しく。ちなみに>>606は俺じゃないけどな。
622 = :
業務に使ってるRDBMSを使いまわしたってかまわないし
セッション用にNOSQLを使う場合もあるだろう
細かい条件を決めてベストを尽くすのがおまえらの仕事
ここで何も聞かずにベストプラクティスが決まるようならおまえらの仕事は不要だよ
予算ないならRDBMS1台とロードバランサー1台、インスタンス1台の構成で
アクセス増えてきたら動的にインスタンス起動ってところじゃないのかな
本当に金かけたくないならインスタンス1台に全盛りでスケーラビリティなしだ
623 = :
ロードバランサーの用途を負荷分散のためだけとか思ってる奴が何人か居るんだな。冗長化必須の場合もロードバランサーで複数のインスタンス使うよ。
業務システムだと負荷は無くても落としたらしばかれるからそういう構成になる。まぁ零細だと多少落ちてもそんなもんだって許されるのかもしれないが。
626 = :
>>624
OSSの思想と真逆のアプローチをとるんだな
公開して皆で脆弱性を見つけて修正できるという思想、
非公開にすれば脆弱性を見つけるのが難しくなるという思想。
日本らしいといえば日本らしいな。
627 = :
毎日のようにSQLインジェクションくさいアクセスログを見ている身としては、非公開FWのほうが安全てのは思考停止すぎるよとだけ言っておく。
628 = :
composerでどうにかなる程度の枝しか作ってないと思ってるのか?
案件ごとに独自進化する地獄を見せつけてやりたい
案件バージョンとFWバージョンのグリッドを見て涙するがいい
629 = :
なんでドヤ顔でバッドノウハウ自慢してるんだ
630 = :
囚人はつながれた鎖の大きさでマウントをとる
631 = :
なにそれいい言葉だなどこで覚えたの
632 = :
自前FW作ってる所はVPCで業務に使ってるとかそんなのだった気がする。確かに案件毎の別バージョンは地獄っぽかった
633 = :
>>627
それ言うほど問題か?SQLインジェクションなんて真っ先に対策するじゃん
XSSとかCSRFとかある程度の脆弱性対策してから開発するだろ
635 = :
>>633
その対策がガバガバだったらどうするの?
636 = :
>>635
そんなレベルのやつはOSSフレームワーク使っても脆弱なシステムしか作れんよ
根っこが理解できてないんだから
637 = :
>>633
そういうことではなくて、独自だろうが何だろうが、外に出す以上は一定の脅威に晒されることに変わりがなく、コードから脆弱性を見つけられないという点は何ら安全を保証するものでもないし、公開しているFWより安全であることの証明にもならないって指摘。
638 = :
Web公開したらまっさきに攻撃してくるのがトレンドマイクロ
639 = :
20年ぐらい前のペーペーの頃、SQLインジェクション(実際には実行できない)があるって
見知らぬ奴がわざわざお問合せフォームから連絡してきたっけ
当時は不正アクセス防止法とかないから、攻撃しようと思えばできたろうけど
単に教えてくるって良いやつだったんだな
640 = :
>>633
一般的な会社は画面に「データを返してほしかったらビットコインをよこせ(意訳)」って表示されてから対策をはじめるんだよ
641 = :
>>636
さすがにそれは違うだろ
少なくともオレオレFWで作るよりははるかに安全
642 = :
>>634
海外の有名FWと公開したところで誰も使わないであろう弊社FWを比較するのはちょっと違和感を感じる
643 = :
>>638
githubを巡回してるロボいるよな
あれAWS社は有名だけどあとはどこが巡回してるんだ
644 = :
>>640
え、お前の会社が日本の標準なの?
645 = :
>>644
社名に日本って入ってるし
646 = :
LaravelでFWの素の状態を知ってから他のFWを触ると面白いよね。
あーこの部分をこうしてるんだーってFW制作者の工夫が分かるようになる。
そんでもってやっぱSymfonyとCakeは勉強になるチューニングしてあって評価の高さも納得できる。
647 = :
Cakeももう少し頑張ってくれたら良いんだけどね
648 = :
cakeはなぜ廃れたんだ?
オフィシャルサイトは良さげなのに
649 = :
Laravelが使いやすいから
みんなの評価 :
類似してるかもしれないスレッド
- 【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.5 (568) - [98%] - 2021/5/1 22:00
- 【PHP】Laravel【フレームワーク】 Part.12 (314) - [96%] - 2023/1/30 18:45
- 【PHP】Laravel【フレームワーク】 Part.3 (983) - [96%] - 2021/2/12 4:00
- 【PHP】Laravel【フレームワーク】 Part.10 (446) - [96%] - 2022/6/6 19:30
- 【PHP】Laravel【フレームワーク】 Part.11 (870) - [96%] - 2022/8/28 15:45
- 【PHP】Laravel【フレームワーク】 Part.4 (460) - [96%] - 2021/4/4 4:00
- 【PHP】Laravel【フレームワーク】 Part.2 (917) - [96%] - 2019/9/10 9:15
- 【PHP】Laravel【フレームワーク】 (887) - [84%] - 2019/4/23 21:00
- 【PHP】フレームワーク Akelos (129) - [56%] - 2019/5/9 7:46
トップメニューへ / →のくす牧場書庫について