のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:126,368,705人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレ【PHP】フレームワークについて語るスレ12【総合】

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    151 = :

    雇って育ててるのは相当余裕がある会社ということか。
    プログラマ堅気を見抜けるエスパーが社に一人いると便利だよ。

    152 = :

    即戦力なんてほとんどいない
    特に新卒とか

    153 = :

    Rubyの習得コストが低いって嘘はどっから出てきたんだ
    まさか日本人が作った言語だから日本人に解りやすいとでも思ったのか

    154 = :

    まぁ、派遣メインの場合、本当は戦力じゃないPGを、
    ねじ込んでしまえば、人材という商品にはなれちゃうからな。
    とりえずphpかJavaできますと言って、嘘にならなければ戦力。

    今となっては、というお話だったとさとしか言えんがw

    155 = :

    金融なんかは人月稼いでなんぼみたいな所あるからね
    どれだけ大人数で時間書けてやったかがリーダーの実績みたいなw
    だからコンサルファームはとにかくスキル関係なく人を入れたがる

    156 = :

    問題化しないギリギリまで長期化させて、
    ギリギリ成功といえる状態で、案件を終わらせるのが、
    優れたリーダーってことか。
    とても楽しくなさそうだ。

    157 = :

    客が怒る寸前まで常駐させて貰うのがキモです
    運用は儲からないんです

    158 = :

    フレームワークスレでも土方さん多いのな。
    そんなもんか。

    159 = :

    お前はアホか

    160 = :

    Yiiいいじゃん

    161 = :

    >>160
    そうなの?

    163 = :

    ZendFW使ってるけど、他の使ってない俺から見ればこれで十分な気ガス

    169 = :

    信者w

    170 = :

    >>162はmemcacheって言いたかっただけじゃないかと
    ActiveRecordをシンプルに使えてちょっといい感じだけどな > Yii
    ただ、拡張をどうすればいいのかちょっとまだよくわからん

    171 = :

    ペドなんか使うなよ

    172 = :

    最近、イスラエルがたくさん人を殺しているというニュース
    どっちもどっちなのかもしれないけど、ほめられたことじゃないな

    Zendはそんなイスラエルの会社
    PHP以外でWEBアプリを作ったことがない俺

    はぁ~、PHPでプログラミングしていると軽く鬱になる(=これはイスラエルとは関係ないかもしれんwww)
    plugger(Perl)、Google App Engine(Python)でもやってみるかな?

    173 = :

    なんだよその上っ面だけの意見は

    174 = :

    PHPER=ユダヤ人
    そう考えたら色々納得いくぜ!

    175 = :

    イスラエルで納得っていうと差別されたり、虐殺されたり、病院爆撃したりっていうこと?
    あと金持ち属性もあるか。

    PHPERは差別はされてるかもしれないけど、虐殺はされてないし、
    病院ごとテロリストをぶっとばすのもしてないぞ、なにより金持ちでもないし。

    ...いや、この先IT不況が来たら大量に首を切られて虐殺されるかも...

    176 = :

    PHPはもうダメポと思った俺は開発をPerlに切り替えたのだが、
    顧客の多くはPHP指定してくる。今のところ予想は外れたまま。
    ええ、結局PHP書いてますよ。

    177 = :

    >>172
    そこまで考えるんならさぁ。

    欧米由来の言語って一切つかえなくね?

    178 = :

    >>176
    なんで思ったの?

    179 = :

    >>168
    Yii使いならメモとかドキュメントとかその他なんでもいいから晒してくれ

    180 = :

    Javaの企業需要はまだなくならない
    ASP.NET系も同じく糞ゲイツ派企業の鉄板
    PHPはなんだかんだでライトユーザーシェアはなくならない
    ---かべ---
    PerlはもうすでにWebProgのCOBOL
    Rubyは永遠に下火

    そのた:話題に上らないほどにマイナー


    >>176
    PHPがだめぽってのはすごく理解できるが、
    そこで何ゆえPerlなんかを選んでしまった理由を聞いてみたいw

    181 = :

    つうか、web屋ならPerl、PHP、Rubyあたりは一通り理解できて然るべきだろ。
    軽量言語如きで信者論争とか、アホらしいっつうかアホそのものだ。

    182 = :

    理解できるのと実際組めるのとは別物だよなぁ。
    昔、簡単な物ならPerlで書けたけど、今はうpロダでさえ作れないかも。

    PHPしか書けないWeb屋が居てもいいよねw

    183 = :

    そりゃ理解できるし組めるが、できることなら糞言語は使いたくないんだ。

    184 = :

    組めないってことは理解できてないんだろ

    185 = :

    調べてみたけどいまいち情報が無いので聞かせてください。
    フレームワークのSSL対応ってどうなっているのでしょうか?

    単純にページをhttps://以下に置けばSSL対応になるとかいうのではありません。
    http://以下の特定のページに着たらhttps://以下にリダイレクトするというものでもありません。

    私が聞きたいのは、SSLページと非SSLページにまたがったアクションで
    情報がどのようにセキュアに扱われているかということです。

    具体的に言えば、たとえばAmazonなど、非SSLページでカートに入れて、そこからSSLページにとんで
    住所などの個人情報とカートの情報を結びつけて会計処理を行えます。
    また逆に個人情報を入れてからカートに追加と言う処理もあります。

    SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
    こういう部分をフレームワークは解決してくれているのでしょうか?
    解決してくれているとしたら、どういった設計になっているのでしょうか?

    186 = :

    そこまで気にするならセッションIDなんてアクセス毎に変えればいいじゃん

    187 = :

    というかセッションIDを取れたからってどうなるというのか

    188 = :

    あらためて、明確にしておきます。

    私が知りたいのは、フレームワークで
    この問題をどう解決しているのか?
    または解決していないのか?

    ということです。

    189 = :

    百聞は一見にしかず、実際に見てみるのが早かろう

    190 = :

    所詮PHPプログラマ的なやりとりでワロタw

    PHPはアンセキュアな糞フレームワークばかり
    secure属性もしらなそうだな。

    191 = :

    フレームワークでって言われても何のフレームワークの話なのか
    PHPにフレームワーク1つしかないと思ってるんだろうか

    192 = :

    セキュアなシステムを組んだ経験が浅い子の戯言です。
    気にしないでやってください。
    なぜなら、フレームワークに依存するレベルの話じゃない。
    フレームワークを使ってどう実装するかという設計の問題です。

    193 = :

    Yiiはこんな感じ
    http://www.yiiframework.com/doc/guide/topics.security

    194 = :


    >>185,188

    195 = :

    >>194
    俺には結構まっとうかつこのスレにふさわしい質問だと思うんだが。
    >>193で端的に答えられているが、それ以外はわざとか限界か知らんが
    ことごとくピントはずれでいい感じだなw

    で、そのYiiのようなクッキーValidationは他のフレームワークにもあったような。

    196 = :

    って書いたが、これはCookieの改竄はチェックできてもそもそものセッションキーを盗まれた
    場合には意味ないね。
    考えられるシンプルな対策で、非セキュアなページではセッションを使わない、もしくは
    セキュアページと共有しないってのは正味ありえないか

    197 = :

    非セキュアなページと、セキュアなページを同一セッションで結ぶのはユーザーの利便性の問題。
    セキュアなページに入ってきたら、必ず一度はそのユーザーの有効性を確認するように実装するのが当然。
    その上で、承認後はセッションIDを毎ページ切り替えるってのが普通。

    非セキュアなゾーンでセッションキーを盗んでも、匿名の個人情報が見れるだけで
    実害はほとんどない。

    これはフレームワーク層じゃなくて、ビジネスロジック層で実装するもんだよ。

    198 = :

    だからアクセス毎にセッションID変えればええやん

    199 = :

    YOU全部HTTPSでやっちゃいなよ

    200 = :

    俺には結構まっとうかつこのスレにふさわしい質問だと思うんだが。 (キリッ


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

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


    トップメニューへ / →のくす牧場書庫について