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

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

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

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

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

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

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

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

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

お前はアホか

Yiiいいじゃん

>>160
そうなの？

サーバ側でmemcacheとか用意しないとならんけどな
DBアクセスするならPDOとかもPear側で準備しとかないとならん
あと結構依存するライブラリたくさんある
フレームワークの意味あんのか

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

PDOをPear側で準備・・・？

ああごめん
PDOがPearじゃなくて"とか"をPearで用意する必要があるものもあるって事ね
CakeとかZendとかPearフリーじゃん
それの対比でYiiは違うよと

PDOとかをPearで準備・・・？

ZendFWでのDB接続は基本PDOだけど・・・

信者ｗ

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

ペドなんか使うなよ

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

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

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

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

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

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

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

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

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

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

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

>>176
なんで思ったの？

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ということです。

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

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

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

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

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

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

>>185,188

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

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

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

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

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

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

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

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

俺には結構まっとうかつこのスレにふさわしい質問だと思うんだが。 （ｷﾘｯ