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

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

1:nobodyさん
08/12/23 00:36:15
PHPのフレームワークに関する話題用のスレッド

●国外産●
symfony
　URLﾘﾝｸ(www.symfony-project.com)
code igniter
　URLﾘﾝｸ(codeigniter.com)
Zend Framework
　URLﾘﾝｸ(framework.zend.com)
CakePHP
　URLﾘﾝｸ(www.cakephp.org)
Yii Framework　←New!! (Dec 03, 2008)
　URLﾘﾝｸ(www.yiiframework.com)

●国産
ちいたん
　URLﾘﾝｸ(php.cheetan.net)
Ethna
　URLﾘﾝｸ(ethna.jp)
guesswork
　URLﾘﾝｸ(classic.guesswork.jp)
maple
　URLﾘﾝｸ(kunit.jp)

●前スレ
【PHP】フレームワークについて語るスレ10【総合】 ※実質11
ｽﾚﾘﾝｸ(php板)

2:nobodyさん
08/12/23 00:36:35
●過去スレ一覧
【PHP】フレームワークについて語るスレ10【総合】 ※実質11
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ10【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ9【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ8【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ7【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ6【総合】
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ5[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ4[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ３[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ２[総合]
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ【総合】
ｽﾚﾘﾝｸ(php板)

3:nobodyさん
08/12/23 04:20:21
おつ

4:nobodyさん
08/12/23 15:47:46
guessworkのPHP5用ってﾏﾀﾞｰ?

5:nobodyさん
08/12/23 19:49:58
2ちゃんだとcakeのスレが一番伸びてるみたいだが、
実際はどうなん？

6:nobodyさん
08/12/23 20:11:14
Cakeの対象にしてるユーザーが2chねらーと一致してるってことだろうな。
おれは、Bakerじゃないけど

7:nobodyさん
08/12/24 02:40:46
関連しそうなスレ
【PHP】フレームワーク CakePHP　5ホール目【v1.2】
ｽﾚﾘﾝｸ(php板)
【PHP】 Smarty 隔離スレ【テンプレート】
ｽﾚﾘﾝｸ(php板)
[PHP][フレームワーク]CodeIgniterスレ
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークMapleに舌鼓
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワーク Akelos
ｽﾚﾘﾝｸ(php板)
【PHP】Ethna part.2【国産フレームワーク】
ｽﾚﾘﾝｸ(php板)
2ch有志がPHPフレームワークを作るスレ
ｽﾚﾘﾝｸ(php板)

PHP総合雑談スレ
ｽﾚﾘﾝｸ(php板)

8:nobodyさん
08/12/24 08:08:43
>>7 に追加。

ZendFramework Part2
ｽﾚﾘﾝｸ(php板)

Vs.Phpのv2.5ぐらいからZFの簡単なスケルトンコードを吐くようになってる。
けど、もうちょっと便利にならんかなぁ。ZS for Eclipseの方がいいかな?

9:nobodyさん
08/12/24 10:41:53
補足thx　phpでソートしたて拾ったから見落としてた

10:nobodyさん
08/12/24 11:32:06
フランチョスとsymfony
ｽﾚﾘﾝｸ(php板)

symfony忘れんな。うじ虫。

11:nobodyさん
08/12/24 12:16:54
なんか言葉の感覚が違うんだろうな。
>>10は日本語が不自由ですか？

12:nobodyさん
08/12/24 17:13:04
>>8
両方とも有料だけどなんでこうフリーでZFに完全対応してくれるフレームワークって無いのかね

13:nobodyさん
08/12/25 02:33:24
>>12
完全対応してくれる"IDE"の間違いじゃね?。
PDTなんかにさらにFWごとにカスタマイズ出来るプラグイン追加って出来たらいいのだろうけど。

俺は今のところZFしか使ってないけど、IDEの対応も普及に貢献すると思うんだが、他のFWはどぉなんだろう。

14:nobodyさん
08/12/25 03:17:52
すまん頭が血迷ってた
どんな環境でZF使ってる？

15:nobodyさん
08/12/25 04:04:54
>>14
開発環境かな? 運用環境じゃないよね。

ZFを使うときはVs.Phpにしている。2.4止まりのアシアルはやる気なさそげなので、
英語版を試用してみたが、英語版で十分だな。そろそろ2.6が正式リリースしそうなので
そうなったら移行するつもり。円高で新規でも1ﾏｿ切ってるしなーw。

俺々FWのﾌﾞﾂはPDT使ってた。今でもメンテで使ってる。ZS4Eに手を出せないのは、
そのうちPDTでもZFをサポートし出すんじゃないかと思ってみたり。

16:nobodyさん
08/12/25 13:43:50
>>15
VS.Phpの使い心地ってどんな感じ?

よかったら詳しいレポ頼む。

17:nobodyさん
08/12/25 23:33:30
>>16
そこまで書くとｽﾚ違いになちゃうな。
以前はIDEｽﾚがあったけど。

PDTと比べると一長一短。デバッガなど全体的には軽快に動く。
C#なんかと比べると、やっぱりもどかしい。
2.6で補完範囲が改善されそうなので期待している。

好みもあるだろうから、30日間試用してみるのが一番いいと思うよ。

18:nobodyさん
08/12/25 23:44:29
ｽﾚ違いﾈﾀ続きでｽﾏｿ。
日本語版も含めてなんか出てきた。
URLﾘﾝｸ(www.jcxsoftware.com)
ただ、リンク先の証明書が無効だと火狐で警告が出ます。

19:nobodyさん
08/12/25 23:51:17
>>18
WEBプログラム言語用のIDEの配布？に、何このずさんな証明書使い回し
ってかそれでなんでSSL掛けてるのか意味不明。

20:nobodyさん
08/12/26 09:54:44
ってかリンク切れしとるんだけど・・・SSLのせい？

21:nobodyさん
08/12/27 01:31:19
フレームワークまったく使ったことないけどなんなん？
使うとどんな感じなん？

22:nobodyさん
08/12/27 01:55:26
>>21
なんか下半身がもぞもぞします

23:nobodyさん
08/12/27 12:41:38
>>21
なんやろねー

24:nobodyさん
08/12/29 15:26:56
fooというディレクトリがおかしいので、一回削除してsvnからリポジトリを持って来たいのですが
リポジトリの部分だけを持ってくるコマンドラインがわかりません。単純な質問だと思いますが
どうしてもわからず、ご教授のほどお願いいたします。

25:nobodyさん
08/12/29 15:37:33
誤爆しました。すみません。

26:nobodyさん
08/12/29 20:34:55
PHP → Zend → イスラエル → パレスチナ → 爆撃 → 誤爆？

27:nobodyさん
08/12/29 20:36:32
HP → Zend → イスラエル → パレスチナ → 爆撃 → 誤爆→PHP脂肪ｗｗｗ

28:nobodyさん
09/01/01 09:20:32
新年あけましておめでとう→PHP脂肪ｗｗｗ

29:nobodyさん
09/01/01 13:10:51
guesswork for PHP5をお年玉にお願いします

30:nobodyさん
09/01/02 01:48:51
>>26
まあ徴兵制だろうね。
終戦前に成人した世代と戦後世代の日本人を見比べれば一目瞭然。

31:nobodyさん
09/01/02 12:39:17
今年一番来るフレームワークはどれだ?
2009 PHPフレームワークダービー

出走場受付中

32:nobodyさん
09/01/02 12:44:31
>>31
>出走場受付中

出走馬ではないの？

33:nobodyさん
09/01/03 18:39:59
>>32
2chでそんな細かいこと言ってると嫌われちゃうぞー

34:nobodyさん
09/01/06 14:44:09
サーバサイド(PHP)とクライアントサイド(JavaScript)の両方でバリデーションをしたいと思うのですが、
同じコードをPHPとJavascriptの両方で書くのはちょっと面倒です。
なんかうまい方法はありませんか。あるいはそのようなフレームワークやライブラリがあれば紹介してください。
お願いします。

35:nobodyさん
09/01/06 17:59:40
そんなつごうのいいのはない

36:nobodyさん
09/01/06 18:25:39
>>32
うひー、ほんとだ(汗
typoご容赦。

んでみんなは今後どのFW使っていくの?
俺はもうZendでいいかと思い始めてる・・・

>>34
jQueryのajaxformプラグインを使ってサーバにリクエストを投げて、
コールバックでエラー表示処理。

37:nobodyさん
09/01/06 19:22:42
そんなことする価値あるの？

38:nobodyさん
09/01/06 19:36:39
クライアントサイドはユーザに負担掛けないリアルタイムな入力チェック
サーバサイドはhiddenの値が改ざんされたときの保険
って感じじゃないの
まぁ値をhidden渡しじゃなくてセッションに突っ込めばクライアント側だけでいい気もするけど

39:nobodyさん
09/01/06 19:38:50
JavaScriptオフの環境への対応でもある

40:nobodyさん
09/01/06 19:47:32
このサイトはInternetExplorer6.0でのみ確認しています

ってエラーメッセージ出せばよくね？

41:nobodyさん
09/01/06 19:53:28
>>36のやり方だと、結局レスポンス待ちだから画面遷移しないってだけであんまり、ねえ。
まあありっちゃありか。
やるとするなら、最初からエラーチェックのJavaScriptを吐き出すか読み込んでおくような形に
するほうがまだスマートな気もするけど。
そういうライブラリあるのかどうかは知らないけど、XMLか何かで、鯖・クラ共用するものは作れそう

>>38
んで、そのセッションに突っ込むデータはどこから飛んでくるんだｗ
>>39の言うとおり、クライアント側のみの検証はあり得ない
処理するデータが無検証の可能性があるってのは、DBに突っ込む時のみならず後々いろいろまずい、はず。
JavaScriptの検証をスルーしてPOSTデータが飛んでこないっていう保証があるんならいいけど。

42:nobodyさん
09/01/06 20:10:38
ネタレスなんだけどさ、
JSでチェックするスクリプトを書く
そのチェックスクリプトをインクルードしてバリデートして返すページを作っておく。
サーバー上のチェックはそのページにCURLでPOSTして結果を取得する。

これなら、バリデーターはJSだけで済む。

43:nobodyさん
09/01/06 20:21:09
>>42
それ、JavaScript動くの？JSのエンジンはどこにあるんだろう・・・

44:nobodyさん
09/01/06 20:24:31
昔ここで見た
サーバサイドもJavaScriptで書いちゃえばいいんだよ！
ってネタレスを思い出した。

その時に聞いたJavaScriptインタプリタなんだったかな？

45:nobodyさん
09/01/06 20:27:27
あ、そか。JSのエンジンが必要だった。逆に、それがあればCURLは関係ないなｗ
サーバーサイドJavaScriptを使うしかないか。

46:nobodyさん
09/01/06 20:30:15
rinoとか

47:nobodyさん
09/01/06 20:36:03
SpiderMonkeyのPHPバインディングとか、サーバサイドJavaScriptの選択肢もいくつかあるよ

48:nobodyさん
09/01/06 21:48:54
俺ならバリデーション規則だけJSONで書いて、それを適用する関数をJavaScriptとPHPで別箇に実装するに留める。
バリデーションルールのデータフォーマット設計が面倒だが、Kwalifyとかを丸パクリかな。

49:nobodyさん
09/01/06 21:58:01
YiiのJPフォーラムに投稿があってうれしい

50:nobodyさん
09/01/06 22:25:49
最近サーバサイドJSも現実的な選択肢になってきたみたいね
故にPHP脂肪ｗｗｗ

51:nobodyさん
09/01/06 23:00:54
>>41
そうなんです、できれば>>36の方法じゃなくて、クライアントサイドでできるチェックはクライアントサイドだけで完結させたいです。

>そういうライブラリあるのかどうかは知らないけど、XMLか何かで、鯖・クラ共用するものは作れそう
残念、ご存じないですか。需要はあると思うんですけど、思ったほど作られてないようですね。
Railsでも探したんですけど、やっぱりないみたいです。

>>48
>俺ならバリデーション規則だけJSONで書いて、それを適用する関数をJavaScriptとPHPで別箇に実装するに留める。
あーつまり、JSONで書かれた規則をPHPで読み込んで、フォーム入力がそれに従っているかどうかをチェックするという感じですか。
そして同じことをJavaScriptでもやると。なるほど。頭いいですね。

>バリデーションルールのデータフォーマット設計が面倒だが、Kwalifyとかを丸パクリかな。
Kwalifyって何ですか？

52:48
09/01/06 23:36:43
>51
バリデーションを行なうライブラリ。配列やJSON、YAMLなどのバリデーションを行なう。RubyとかPerlしかないが。
まあ、こんなデータフォーマットだとそれなりに漏れなく表現できるよってだけの意味。単なるサンプルに過ぎない。
自分でバリデーションルール用のJSONのフォーマット考えられるなら忘れておｋ。
（まあ、データフォーマットとかいちいち考えず、正規表現をJSONに格納しておけば十分っちゃ十分なのだが…）

53:36
09/01/07 00:37:15
>>39
そう、Progressive Enhancementというやつです。

>>47
Jaxerというのもある。

54:nobodyさん
09/01/07 00:57:38
VBでクライアントアプリケーション作ってサーバサイドアプリと通信しなよ

55:nobodyさん
09/01/07 08:08:02
>>34
今は亡きｗ HTML_QuickFormに、一応JavaScriptコードの自動出力機能がついてたなあ

56:nobodyさん
09/01/07 10:01:31
DBｸｴﾘｰ必要なﾊﾞﾘﾃﾞｰｼｮﾝもある

57:nobodyさん
09/01/07 22:34:19
それ、バリデーションって言うか？

58:nobodyさん
09/01/07 23:01:29
IDの重複チェックや郵便番号の存在チェックとかだろ

59:nobodyさん
09/01/08 10:31:01
それは普通にAjaxでやればいいわけで

60:nobodyさん
09/01/08 10:39:22
Ajaxっていったって、DB内のIDと重複するかチェックするなら(ry

61:nobodyさん
09/01/08 11:31:26
>>59
まさか郵便番号何十万件もJSの配列につっこんどくつもりか

62:nobodyさん
09/01/08 11:32:22
クライアントレベルでは簡易的なチェックでいいんだから問題なし

63:nobodyさん
09/01/08 11:40:10
> 簡易的なチェックでいいんだから問題なし

へぇ。そうなんですか。メモっとこ。

64:nobodyさん
09/01/08 12:08:22
ん？なんでAjaxでJSの配列？

65:nobodyさん
09/01/08 12:44:42
AjaxからDBにクエリ投げて検証した結果のIDをhiddenなりtextなりに突っ込んでPOSTし
POST先のサーバコードでまたDBにクエリ投げて検証してってやるわけですね

まあPOSTする前、画面遷移せずにエラー警告文が出せるというのが利点か。

66:nobodyさん
09/01/08 15:02:15
なんなのこの低ﾚﾍﾞﾙｗ

67:nobodyさん
09/01/08 15:51:12
>>64
DBアクセスしないで何処からデータ持ってくるんだ

68:nobodyさん
09/01/08 16:23:15
DBアクセスとJSの配列になんの関係が？

69:nobodyさん
09/01/08 16:51:55
なんなのこの超低ﾚﾍﾞﾙｗ

70:nobodyさん
09/01/08 19:17:03
>>68

71:nobodyさん
09/01/08 21:05:54
Ajax万能説かｗ

72:nobodyさん
09/01/08 21:47:23
隙を見せないように要点を得ない短文ばかりで話すらかみ合ってない

73:nobodyさん
09/01/09 04:32:42
>要点を得ない

74:マジレス希望
09/01/09 12:19:55
皆さん、JavaScriptはどうやって勉強されましたか？
・オススメの勉強方法
・オススメの解説書
・オススメのサイト
があれば是非ご紹介ください。m(__)m

75:nobodyさん
09/01/09 13:04:59
ぐぐる

76:nobodyさん
09/01/09 13:27:38
>>74
一撃必殺

77:nobodyさん
09/01/09 19:17:31
>>74
スレチだろ、よそで聞いたほうがまともな答えが返ってくると思うぞ。

78:nobodyさん
09/01/11 12:53:52
ストリームベースのフレームワーク
URLﾘﾝｸ(lll-framework.hikosha.jp)

なんだこれ

79:nobodyさん
09/01/12 00:02:56
>>78
「解凍して、public_html/にアクセスするだけで、すぐに使えます！」
解凍したファイルをドキュメントルート以下に置いてpublic_html/にアクセスすると
Fatal error: LLL_Template::require()とでて真っ白の画面になった。
PieceFrameworkを思い出したよ。

ﾎﾟｨ(ﾟ△ﾟ)ﾉ⌒ ﾟ凵

80:nobodyさん
09/01/12 11:46:05
>>79
すまない。orz

不具合を修正しました。
URLﾘﾝｸ(lll-framework.hikosha.jp)

81:nobodyさん
09/01/12 22:55:46
>>75-77
ありがとうございます。
一撃必殺JavaScript～お気に入りに保存しました。
JavaScriptは中途半端な理解で十分に使いこなせていなかったので、PHPフレームワークの次はJavaScriptの習得を目指します＾＾

82:nobodyさん
09/01/12 23:03:14
>>80
2chで釣りとか
作者必死だな・・・

83:nobodyさん
09/01/12 23:12:01
>>78
知らないフレームワークがまだあったか。
とりあえず捕捉した。

84:nobodyさん
09/01/13 00:52:46
>>78
ネタが増えるのはいいことだけど・・・
ざっくりサイトだけ読んでみて

> PHP4,PHP5両方で動作する事。
またか。

サイトにしろFWにしろ、これから新しくものを作るんならいい加減、PHP4を切り捨てた方が
すっきりといいものができるように思うのはおれが怠惰すぎるのだろうかね

85:nobodyさん
09/01/13 01:01:58
今まではレンタル鯖に入ってるバージョンの都合ってのもあったけど
去年でPHP4もサポート終わったんじゃなかったっけ

86:nobodyさん
09/01/13 01:26:26
試してみることもないからどっちでもいいよ

87:nobodyさん
09/01/13 02:22:51
php4はさっさと切ってほしいな。
メソッドにアクセス修飾子がないといらいらする。

88:nobodyさん
09/01/14 00:02:14
そんな事どうでもいいけどな

89:nobodyさん
09/01/14 02:16:40
アクセス修飾子があるスクリプト言語の方が少ない

90:nobodyさん
09/01/14 02:30:44
>>89
PerlにもRubyにもありますが

91:nobodyさん
09/01/14 02:34:16
少ないね

92:nobodyさん
09/01/14 02:35:52
protectedがあるスクリプトは少ない

93:nobodyさん
09/01/14 05:57:49
protectedがないとtemplate methodが分かりにくいよな
その点で他のLLは糞

94:nobodyさん
09/01/14 10:09:53
どうしようもないばかだな

95:nobodyさん
09/01/14 15:21:39
>>94
自分への嘆きかｗ

96:nobodyさん
09/01/14 21:39:54
Pythonのように
「全部public、ただし先頭にアンダーバーがついてたらよいこのみんなは呼ばないようにしようね」
というのもそれはそれでいいと思うけどな。
どうせprivateとprotectedとpublicで命名規則を変える事が多いわけだし。

97:nobodyさん
09/01/14 21:47:37
本末転倒だな

98:nobodyさん
09/01/16 16:43:30
URLﾘﾝｸ(jibun.atmarkit.co.jp)
林氏：Javaを勉強した後、RubyやPerl、Pythonの文法が面白くて眺めてました。

↓

参考材料にもならないPHPは脂肪(＞＜)ｗｗｗ

99:nobodyさん
09/01/16 18:21:10
文法が面白くてPHP使ってるんじゃないしな
CやJavaと殆ど同じようなもんだし

100:nobodyさん
09/01/16 18:26:35
Perlの文法の何が面白いのかわからん

101:nobodyさん
09/01/16 18:27:40
＞CやJavaと殆ど同じようなもんだし

おいおい、お前らのレベルってこのくらいなの？

102:nobodyさん
09/01/16 18:38:04
大きく間違ってはいないと思うけど？
つーか、そこにツッコミ入れる奴って…３年ROMってｒ（ｒｙ

103:nobodyさん
09/01/16 18:58:53
CとJavaとPHPは意図的に似せて作ってるからな
その上で林さんって人はそれと全く文法が違う
Ruby、Perl、Pythonを面白がったってだけだろ

104:nobodyさん
09/01/16 19:10:15
$とか.とかはPerl由来だったり、C系のポピュラーな言語に似せてあるよね。
（Perl由来の部分は単にPersonal Home Page Tools時代の名残かもしれないけど）

105:nobodyさん
09/01/16 19:10:48
ＰＨＰはウェブありきで作られた言語だから面白みを問われたらちょっとな・・

Ｃ言語の有名サイトにこんなものがある
URLﾘﾝｸ(www.kojima-cci.or.jp)

106:nobodyさん
09/01/16 19:25:15
Perlはelsifみたいなどうでもいい省略さえなければもっと使いやすいのに
逆に打ち間違うわ

107:nobodyさん
09/01/16 19:27:33
そしてその不評な省略形式を丸々真似てしまったRuby

108:nobodyさん
09/01/16 20:43:49
elsifだとどんなメリットがあるんだ？

109:nobodyさん
09/01/16 23:54:23
else if
elsif

やったぁ！2文字もタイプ量が減るぞ！！

110:nobodyさん
09/01/16 23:55:15
最初に触ったのがPerlだったせいで、
いまでもときどき elsif と elseif と else if がごっちゃになって困るｗ

111:nobodyさん
09/01/17 00:12:33
シェルも触るとelifまで候補に入ってさらにカオスw

112:nobodyさん
09/01/17 00:29:45
うわあああ

113:nobodyさん
09/01/19 01:23:11
rubyやpythonも嫌いじゃないがタイプヒンティングがないのはどうにかならんのか
引数リスト見ても何投げたらいいから分からなくてまいっちんぐ

114:nobodyさん
09/01/19 09:58:52
つコメント

115:nobodyさん
09/01/19 12:07:45
>>113
vimになかったか？

116:nobodyさん
09/01/19 22:45:12
何だかんだ言って一番馬鹿にされてるPHPが最強言語だよね(´・ω・`)

117:nobodyさん
09/01/19 22:51:44
ラズベリー賞しかり、イグノーベル賞しかり。

118:nobodyさん
09/01/20 10:49:51
>>116
Webで便利なだけでしょ。Web以外はPerl使ってるよ。最近PHPにも懲りてWebもPerlも使い出した。
Catalystマンセー

119:nobodyさん
09/01/20 11:49:35
>>118
Catalystもそうだけど、CPAN万歳になるのが初動でのネックだと感じてる。
導入だけ、って考えるならPHPのフレームワークのほうがよほど楽。

結局は目的次第じゃないかと。

120:nobodyさん
09/01/20 12:00:08
>>119
そう。PHPはWeb以外では殆ど使い物にならないから、
最強言語だよねとか言われると困る。

ちなみにこのネタは宗教論争を呼ぶので早めに切り上げたい。

121:nobodyさん
09/01/20 12:23:13
PHPはWebでしか使えないというけど別に使えるんだけどな普通のスクリプトとしても

122:nobodyさん
09/01/20 12:26:00
使えないとは言ってないよ。使わないけど。

123:nobodyさん
09/01/20 12:26:09
ちょっとしたスクリプトもPHPで作ってる
普段使ってるから作りやすくて楽

124:nobodyさん
09/01/20 12:58:05
*nixの管理ツールなどでPHPで作られたものなんて見たことない。
使われているのはPerl、Python、Rubyのどれかだろ。

125:nobodyさん
09/01/20 13:08:13
PHPはmod_php以外だとはっきり言って魅力ないからな

126:nobodyさん
09/01/20 13:15:22
>>124
たまにＰＨＰ自作ツール見かけて「ぷっ」と思う。
なんかそんなイメージ。

127:nobodyさん
09/01/20 13:17:21
>>124
shを忘れないで下さい。

128:nobodyさん
09/01/20 13:22:10
cronで回しているウェブ用データ整理はCLI
自作ライブラリ使い回せるし

129:nobodyさん
09/01/20 13:31:39
>>128
他人がいじれない確率が高いのがネックだな。

130:nobodyさん
09/01/20 13:37:08
>>128
それはWEBアプリの一部ではないのだろうか。

まあ一般論だとしても、これは実は結構大きいんだけどね。
WEBでPHPを使ってるんなら、CPANとかいちいち使い方調べるのは効率悪いとも思う。

でも、それをやっとくと比較的汎用的なスキルにはなってそうな気もするから迷う。
（自作ライブラリが陳腐化した時とか、そもそも違う環境で作業しなきゃいけないとか）

結局得意な言語が１～２個あり、その他も好き嫌いしないで使えるってのが理想では
あるんだけど。

131:nobodyさん
09/01/20 14:53:10
>>124
監視しない方ですか

132:nobodyさん
09/01/20 15:09:20
>>124
RubyはないだろJK
いや少しはあるかもしれんが、
基本はPerlかPython。

133:nobodyさん
09/01/20 15:15:18
おれの基本はbash

134:nobodyさん
09/01/20 15:52:58
OSやM/W自体の監視と、そこで動くアプリケーションの監視を混同してないか？

前者ならPerlが多いと思うし、後者でDBも監視するなら
そのアプリケーションで使ってるライブラリ使ってDBアクセスしたほうがいいだろうし。

135:nobodyさん
09/01/20 19:57:05
>>132
言っちゃダメーｗｗｗｗ

本人はPerlかPythonに並ぶメジャー言語だって思ってんだからｗｗｗ

136:nobodyさん
09/01/20 20:29:13
は？puppetなんかはrubyで書かれてますが何か
今時perlなんて類人猿しか使ってねーし

137:nobodyさん
09/01/20 22:54:13
このスレでそんなこと言ってもねぇ

138:nobodyさん
09/01/21 00:00:34
Agaviの次のリリースではコマンドラインからの呼び出しがサポートされるよ。
URLﾘﾝｸ(trac.agavi.org)

139:nobodyさん
09/01/21 00:07:16
agavi静かに進んでたんだなｗ

140:nobodyさん
09/01/21 03:12:08
実際、Rubyは厳しいんじゃないかな。ウェブ系のスクリプト言語でPHPの優位は今後も変わらないでしょう。
サブの言語というか、ちょっとしたツールなら、Perlで十分だし、海外じゃPythonもあるわけで。
日本でRuby使うって、Railsを使うって言うのとイコールだと思うけど、当初はともかく、今となっては特別圧倒的に優位なウェブフレームワークじゃないし。

141:nobodyさん
09/01/21 03:25:00
Rubyは立ち位置が微妙だよな
ニッチ言語でもないし

142:nobodyさん
09/01/21 07:20:17
なんというか利点がないんだよな。Ruby使う

143:nobodyさん
09/01/21 08:54:04
Ruby/RoRのModelで関連テーブルが扱えないのは治ったのか？
俺はあれでRoRって使えねーって思ったんだが。

144:nobodyさん
09/01/21 10:38:16
企業からすれば、習得のためのコストは少ないほうが良いに決まっている。

145:nobodyさん
09/01/21 11:00:58
>>144
出来る人間なら習得コストは同じだよ。何でもすぐ覚える。勝手に覚える。
知らない間にPerlとかに手を出してる。

PHP手取り足取り教えてやっと使い物になるような人材は嫌だなあ。

146:nobodyさん
09/01/21 11:03:52
嫌とか嫌じゃないかの問題じゃなく、
コストの問題でしょ

147:nobodyさん
09/01/21 11:16:40
>>146
教材は何でもいいよ。ダメなら切るだけ。だからコストは一緒。
出来る人間がPHP覚えるのもPerl覚えるのも大差ない。

148:nobodyさん
09/01/21 11:27:19
出来る人間だけ揃えられる企業ならともかく、
能力にばらつきがあるのが世の常でしょ

149:nobodyさん
09/01/21 11:30:39
>>148
まあその辺は会社によって違うかもな。
PHPは教材としてイニシャルコストは安いと思う。
どの言語も結局は同じくらいのコストがかかるんだがな。

150:nobodyさん
09/01/21 12:27:49
求人するのタダじゃないんだぞ。
そう簡単に切ったり雇ったりできるか！
言語を教材なんて言ってる時点で仕事じゃない
コスト考えるなら即戦力。即戦力を考えたら普及している言語が有利に決まってるだろ。
今話題の派遣とかが会社にとって効率がいい

151:nobodyさん
09/01/21 13:08:07
雇って育ててるのは相当余裕がある会社ということか。
プログラマ堅気を見抜けるエスパーが社に一人いると便利だよ。

152:nobodyさん
09/01/21 13:38:39
即戦力なんてほとんどいない
特に新卒とか

153:nobodyさん
09/01/22 03:26:59
Rubyの習得コストが低いって嘘はどっから出てきたんだ
まさか日本人が作った言語だから日本人に解りやすいとでも思ったのか

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

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

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

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

157:nobodyさん
09/01/22 05:37:45
客が怒る寸前まで常駐させて貰うのがキモです
運用は儲からないんです

158:nobodyさん
09/01/23 02:44:44
フレームワークスレでも土方さん多いのな。
そんなもんか。

159:nobodyさん
09/01/23 08:09:25
お前はアホか

160:nobodyさん
09/01/27 00:00:53
Yiiいいじゃん

161:nobodyさん
09/01/27 23:42:06
>>160
そうなの？

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

163:nobodyさん
09/01/28 00:05:19
ZendFW使ってるけど、他の使ってない俺から見ればこれで十分な気ｶﾞｽ

164:nobodyさん
09/01/28 00:12:52
PDOをPear側で準備・・・？

165:nobodyさん
09/01/28 00:26:31
ああごめん
PDOがPearじゃなくて"とか"をPearで用意する必要があるものもあるって事ね
CakeとかZendとかPearフリーじゃん
それの対比でYiiは違うよと

166:nobodyさん
09/01/28 00:52:28
PDOとかをPearで準備・・・？

167:nobodyさん
09/01/28 00:55:30
ZendFWでのDB接続は基本PDOだけど・・・

168:nobodyさん
09/01/28 01:01:34 VWeywu5Y
>>162
memcacheは必須じゃないでしょ？
逆にCakeでもZendでもキャッシュのバックエンドにmemcacheを使うなら
サーバ側で用意するのは一緒。

> あと結構依存するライブラリたくさんある
例えば？

> フレームワークの意味あんのか
依存するライブラリの多寡とフレームワークの意味は関係ない概念だと思います。

169:nobodyさん
09/01/28 07:10:16
信者ｗ

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

171:nobodyさん
09/01/28 08:19:43
ペドなんか使うなよ

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

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

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

173:nobodyさん
09/01/28 11:22:29
なんだよその上っ面だけの意見は

174:nobodyさん
09/01/28 12:50:21
PHPER=ユダヤ人
そう考えたら色々納得いくぜ！

175:nobodyさん
09/01/28 15:17:58
イスラエルで納得っていうと差別されたり、虐殺されたり、病院爆撃したりっていうこと?
あと金持ち属性もあるか。

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

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

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

177:nobodyさん
09/01/28 22:52:50
>>172
そこまで考えるんならさぁ。

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

178:nobodyさん
09/01/28 23:53:34
>>176
なんで思ったの？

179:nobodyさん
09/01/29 00:07:10
>>168
Yii使いならメモとかドキュメントとかその他なんでもいいから晒してくれ

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

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

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

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

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

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

183:nobodyさん
09/01/29 01:41:58
そりゃ理解できるし組めるが、できることなら糞言語は使いたくないんだ。

184:nobodyさん
09/01/29 01:51:42
組めないってことは理解できてないんだろ

185:nobodyさん
09/01/29 18:23:40
調べてみたけどいまいち情報が無いので聞かせてください。
フレームワークのSSL対応ってどうなっているのでしょうか？

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

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

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

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

186:nobodyさん
09/01/29 18:26:56
そこまで気にするならセッションIDなんてアクセス毎に変えればいいじゃん

187:nobodyさん
09/01/29 18:31:21
というかセッションIDを取れたからってどうなるというのか

188:nobodyさん
09/01/29 18:42:10
あらためて、明確にしておきます。

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

ということです。

189:nobodyさん
09/01/29 20:08:05
百聞は一見にしかず、実際に見てみるのが早かろう

190:nobodyさん
09/01/29 20:15:44
所詮PHPプログラマ的なやりとりでワロタｗ

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

191:nobodyさん
09/01/29 20:45:27
フレームワークでって言われても何のフレームワークの話なのか
PHPにフレームワーク1つしかないと思ってるんだろうか

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

193:nobodyさん
09/01/29 21:12:16
Yiiはこんな感じ
URLﾘﾝｸ(www.yiiframework.com)

194:nobodyさん
09/01/29 22:59:54

>>185,188

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

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

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

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

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

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

198:nobodyさん
09/01/30 00:47:54
だからアクセス毎にセッションID変えればええやん

199:nobodyさん
09/01/30 00:56:28
YOU全部HTTPSでやっちゃいなよ

200:nobodyさん
09/01/30 02:29:11
俺には結構まっとうかつこのスレにふさわしい質問だと思うんだが。（ｷﾘｯ

201:nobodyさん
09/01/30 03:47:52
煽ってるとこすまんが、同意するよ。
PythonやらRubyやらPerlがphpと比べてどうのとか、
ぜんぜん関係なかったし。

202:nobodyさん
09/01/30 08:04:53
>>197
>セキュアなページに入ってきたら、必ず一度はそのユーザーの有効性を確認するように実装するのが当然。

これがわからん。どうやって確認するの？
例えばユーザでログインした後、トップページからお問い合わせフォーム（もしくはその確認画面）に進んだだけで
パスワード入力を求められるようなサイトは現実的かな？
Amazonみたいに、重要な操作の前にいちいちパスワード入力を求めるっていう感じかな。

それとも、セッションに頼らない確認方法があるんだろうか。
流行の一時トークンも、ぶっちゃけクッキーやらPOSTだったら一緒に盗まれるんじゃないの。

203:nobodyさん
09/01/30 08:27:30
だから、個別のサービス思想に絡んだ設計の問題なわけでそ。

アマゾンのように、長いセッションを維持するサイトでは、重要な操作の前に、
必ずパスワードを確認させて、セキュアなセッションは短くしている。

Yahooでもクッキーを数種類使いつつ、クラムというフォーム追跡を埋め込んで、
通常ログイン状態とセキュアログイン状態を識別、追跡している。
だから、パスワードの再確認を求められるケースとそうじゃないケースがある。

そういうギミックを持ってないところは、ショップなどのように金銭が絡むところは
まるっとHTTPSで実装する。

> 流行の一時トークンも、ぶっちゃけクッキーやらPOSTだったら一緒に盗まれるんじゃないの。

それはどういうレイヤーで話をしてるの？
プロトコルの欠陥？ネットワーク盗聴？ブラウザーのバグ？

204:nobodyさん
09/01/30 08:44:58
>>202
盗まれても良いための「ワンタイム」トークンじゃないの？

205:nobodyさん
09/01/30 10:08:00
>>203
クッキーが盗まれる、っていう現象で想定のメインは「ネットワーク盗聴」じゃね？
他にもあるのか俺は知らんが。
例えばXSSで盗まれるのであればSSLなんて関係ないわけだし

>>204
毎回セッションIDを変えるってので兼用できてそうな気がするから、併用して
冗長にしてチェック、かな？
どのみちタイムアウトの設定次第の様な気がする。

206:nobodyさん
09/01/30 10:33:33
>>205
ネットワーク盗聴ならSSL下では問題ないって前提でいいわけだよな。
(SSL下でも解読できるとか行っちまったら元もこもない）
SSL下でsecure属性をつけたクッキーを出すのが普通なんで、
復路の盗聴はないし、ワンタイムトークンを使う限り
タイムアウトはセキュアセッションと同等でいいよな。

あんまりにも普通なこと過ぎて書くのが恥ずかしくなってきたわ。

207:nobodyさん
09/01/30 10:39:58
>>203
> だから、個別のサービス思想に絡んだ設計の問題なわけでそ。
そういう場合に、どっちの方式をとるかは設計の問題だね。

だけどフレームワークの意味をもう一度思い出してほしい。

汎用的で複雑な処理を簡単に実装できることだ。
重要な操作の前に確認したいのなら、
プロパティ一つ程度の簡単なコードですむようにしてくれるものだろう？

YAHOOのパスワードの再確認を求められるケースとそうじゃないケースを
作る為のサポート機能。それこそフレームワークが提供するべきものだろう？

あと、毎回セッションIDを変える方法は、
別ウインドウを出したとき問題になる。

208:nobodyさん
09/01/30 10:43:17
>>197
> 匿名の個人情報が見れるだけで実害はほとんどない。

これは笑う所かいな？ｗ

個人情報＝本名・住所等

匿名の本名・住所等が見れるだけで実害はほとんどない。

匿名になってないじゃないか～い。

209:nobodyさん
09/01/30 10:46:19
>別ウインドウを出したとき問題になる。

AmazonやYahooでいつ別ウインドウが出るってんだ
その手のサイトでログイン後に別ウインドウとかアホ設計だろうに

210:nobodyさん
09/01/30 10:49:28
>>209
別ウインドウってのは人間が出すんだよ。
ネットワークが遅いから、過去の履歴の詳細をいくつも別ウインドウで開くとか
（一つのウインドウの内容を見ている間に、他のページの読み込みが終わっている）

211:nobodyさん
09/01/30 10:51:55
>>208
もしかしてそこが笑うところ？
> 個人情報＝本名・住所等

そんな決めつけでよくやってられるな。
たとえば、性別とか好みとかカートの中身とか、クリック動向とか
個人を特定できないが個人に関係する情報も個人情報だろが

212:nobodyさん
09/01/30 10:52:36
>>207
あと、毎回セッションIDを変える方法は、
別ウインドウを出したとき問題になる。

ない。

213:nobodyさん
09/01/30 10:55:22
毎回セッションIDを変える方法は
連続でリロードすると問題になる。

サーバーでは値が変わっているが、
クライアントでは新しい値を受け取っていないなど。

214:nobodyさん
09/01/30 10:55:54
>>207
> だけどフレームワークの意味をもう一度思い出してほしい。
> 汎用的で複雑な処理を簡単に実装できることだ。

セキュアセッションは汎用的でも複雑でもないだろ。
関数一発挟むだけなのに、それをプロパティで設定しろってか。

215:nobodyさん
09/01/30 10:57:40
>>213
あほ？

別ウインドウを出したり、連続リロードで動作しちゃいけないのがセキュアゾーン

216:nobodyさん
09/01/30 10:57:52
セキュアページに入る前に
必ず認証が必要だというが、
Amazonはそうなっていない。

これを実現できるフレームワークは皆無ってことでおｋ？

217:nobodyさん
09/01/30 11:00:03
>>215
だが、Amazonは別ウインドウを出しても、連続リロードしても問題ない。

これを実現できるフレームワークは皆無ってことでおｋ？

218:nobodyさん
09/01/30 11:01:38
>>216
アマゾンはそうなってるよ。
すでにセキュアトークンを持ってれば別

フレームワーク乞食乙

219:nobodyさん
09/01/30 11:04:46
>>218
それは、ブラウザ起動して初めてログインした場合だろ。

一度ログインしていれば、非セキュアページから
セキュアページに入るときにパスワードは要求されない。

一度注文履歴を見たあとで、トップに戻れ。

トップから、もう一度注文履歴を見る間にパスワードを聞かれるか？

220:nobodyさん
09/01/30 11:12:49
>>214
> 関数一発挟むだけなのに、それをプロパティで設定しろってか。

関数一発挟むだけじゃないな。
Windowsプログラミングじゃあるまいし。
パスワード入力ダイアログを出して終わりじゃないんだよ。

認証が必要になった場合に、他のページに飛ばさないといけない。
そこから戻らないといけない。

一回目（認証前）と戻ったときの二回目（認証後）で違う処理をしないといけない。
必ずパスワードを出すというわりに、認証後はパスワードを出さないという風に矛盾している。

221:nobodyさん
09/01/30 11:23:06
>>207
> あと、毎回セッションIDを変える方法は、
> 別ウインドウを出したとき問題になる。

ただ単に、どっちかのセッションが使えなくなるだけじゃない？
問題なし

222:nobodyさん
09/01/30 11:24:24
>>219
それで何が不満なの？
なにかセキュリティ上の問題があるなら指摘してください

>>220
よーくわかった。(ry

223:nobodyさん
09/01/30 11:25:39
>>219
> すでにセキュアトークンを持ってれば別
ってちゃんと書いてるだろ。

224:nobodyさん
09/01/30 11:39:10
そもそもAmazonはJavaで独自実装だから
PHPフレームワークスレでこんな機能が全て実現できるフレームワークは
PHPにないよね！って言われた所でなんなんだっていう
ちなみにPerlでもJavaでもASPでもそんなフレームワークはない
その辺は自分で実装する

225:nobodyさん
09/01/30 12:33:45
>>207
>だけどフレームワークの意味をもう一度思い出してほしい。
>
>汎用的で複雑な処理を簡単に実装できることだ。
>重要な操作の前に確認したいのなら、
>プロパティ一つ程度の簡単なコードですむようにしてくれるものだろう？
>
>YAHOOのパスワードの再確認を求められるケースとそうじゃないケースを
>作る為のサポート機能。それこそフレームワークが提供するべきものだろう？

これがフレームワークが提供すべき汎用的な機能かと言うとどうだろうね？

226:225
09/01/30 12:35:02
追記：
「Webアプリケーションフレームワークが」提供すべきかどうか、ね。

227:nobodyさん
09/01/30 12:46:45
重大なセキュリティに絡む部分をオープンなフレームワークで吸収したら
そこにバグがあったらそれ使ってるシステムみんな死亡じゃん
クリティカルな部分は独自に実装するからバグがあってもなんとななるわけで

228:nobodyさん
09/01/30 13:17:58
>>227
んなこといったら、プレースホルダ使いたい、使わせたい為だけにPEAR::DB使ってた人間とか涙目だろ。
実際そういった判断は、凡PGに任せるより遙かにセキュアだったと思うがな

フレームワーク（というか基底ライブラリ）の有用性の一面を完全否定っすか。

229:nobodyさん
09/01/30 13:34:34
>>227
問題はバグがどうたらじゃないよ
設計や計画にはちゃんとした理解が必要だが、コーディングが難しかったり
面倒だったりするわけじゃないからFWに任せる内容じゃないってことだよ。

コーディングの助けっていう意味程度なら、どのFWにもセキュアセッション
を扱う機能や、ワンタイムトークンを自動でハンドリングするフォーム要素とか
一通りのものは揃ってる。

が、ページ遷移設計まで自動化してほしいとは思わないけどな。

PieceFrameworkあたりなら、その辺はすでに実装済みかもしれんけど。

230:nobodyさん
09/01/30 13:36:33
CakePHPは実際AuthComponentで誰でもログインできるってバグ出して死亡したけどなｗ
ああいうのはFWで吸収しない方がいい

231:nobodyさん
09/01/30 13:38:02
>>229
きちんと実装されるかどうかじゃなくて、フレームワークの場合は
そういうバグがありましたって公開されちゃうから、フレームワーク使ってるのバレると
悪用されるってことじゃないの？
独自実装ならクソみたいな実装でも中はどうなってるかアタックするまで解らんのだし

232:nobodyさん
09/01/30 13:43:38
>>230
言ってみれば各フレームワークも、それぞれの独自実装の固まりだからな
ある程度のライブラリくらい共用して欲しいような気もする今日この頃。
APIも統一されるし。

233:nobodyさん
09/01/30 13:53:53
cookieのsecure属性を理解してないヤツが混じってる予感。

次ページ