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

1 ：nobodyさん：2008/12/23(火) 00:36:15 ID:???

PHPのフレームワークに関する話題用のスレッド

●国外産●
symfony
　ttp://www.symfony-project.com/
code igniter
　ttp://codeigniter.com/
Zend Framework
　ttp://framework.zend.com/manual/ja/index.html
CakePHP
　ttp://www.cakephp.org/
Yii Framework　←New!! (Dec 03, 2008)
　ttp://www.yiiframework.com/

●国産
ちいたん
　ttp://php.cheetan.net/
Ethna
　ttp://ethna.jp/
guesswork
　ttp://classic.guesswork.jp/
maple
　ttp://kunit.jp/maple/

●前スレ
【PHP】フレームワークについて語るスレ10【総合】 ※実質11
http://pc11.2ch.net/test/read.cgi/php/1219581817/

2 ：nobodyさん：2008/12/23(火) 00:36:35 ID:???

●過去スレ一覧
【PHP】フレームワークについて語るスレ10【総合】 ※実質11
http://pc11.2ch.net/test/read.cgi/php/1219581817/
【PHP】フレームワークについて語るスレ10【総合】
http://pc11.2ch.net/test/read.cgi/php/1202521438/
【PHP】フレームワークについて語るスレ9【総合】
http://pc11.2ch.net/test/read.cgi/php/1197383840/
【PHP】フレームワークについて語るスレ8【総合】
http://pc11.2ch.net/test/read.cgi/php/1192604501/
【PHP】フレームワークについて語るスレ7【総合】
http://pc11.2ch.net/test/read.cgi/php/1181350116/
【PHP】フレームワークについて語るスレ6【総合】
http://pc11.2ch.net/test/read.cgi/php/1171896620/
[PHP]フレームワークについて語るｽﾚ5[総合]
http://pc10.2ch.net/test/read.cgi/php/1159579507/
[PHP]フレームワークについて語るｽﾚ4[総合]
http://pc8.2ch.net/test/read.cgi/php/1151706907/
[PHP]フレームワークについて語るｽﾚ３[総合]
http://pc8.2ch.net/test/read.cgi/php/1145971945/
[PHP]フレームワークについて語るｽﾚ２[総合]
http://pc8.2ch.net/test/read.cgi/php/1135847024/
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/

3 ：nobodyさん：2008/12/23(火) 04:20:21 ID:???

おつ

4 ：nobodyさん：2008/12/23(火) 15:47:46 ID:???

guessworkのPHP5用ってﾏﾀﾞｰ?

5 ：nobodyさん：2008/12/23(火) 19:49:58 ID:???

2ちゃんだとcakeのスレが一番伸びてるみたいだが、
実際はどうなん？

6 ：nobodyさん：2008/12/23(火) 20:11:14 ID:???

Cakeの対象にしてるユーザーが2chねらーと一致してるってことだろうな。
おれは、Bakerじゃないけど

7 ：nobodyさん：2008/12/24(水) 02:40:46 ID:???

関連しそうなスレ
【PHP】フレームワーク CakePHP　5ホール目【v1.2】
http://pc11.2ch.net/test/read.cgi/php/1229669539/
【PHP】 Smarty 隔離スレ【テンプレート】
http://pc11.2ch.net/test/read.cgi/php/1201879269/
[PHP][フレームワーク]CodeIgniterスレ
http://pc11.2ch.net/test/read.cgi/php/1177683436/
【PHP】フレームワークMapleに舌鼓
http://pc11.2ch.net/test/read.cgi/php/1122105465/
【PHP】フレームワーク Akelos
http://pc11.2ch.net/test/read.cgi/php/1187333485/
【PHP】Ethna part.2【国産フレームワーク】
http://pc11.2ch.net/test/read.cgi/php/1186096518/
2ch有志がPHPフレームワークを作るスレ
http://pc11.2ch.net/test/read.cgi/php/1172328149/

PHP総合雑談スレ
http://pc11.2ch.net/test/read.cgi/php/1200314111/

8 ：nobodyさん：2008/12/24(水) 08:08:43 ID:???

>>7 に追加。

ZendFramework Part2
http://pc11.2ch.net/test/read.cgi/php/1204726884/

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

9 ：nobodyさん：2008/12/24(水) 10:41:53 ID:???

補足thx　phpでソートしたて拾ったから見落としてた

10 ：nobodyさん：2008/12/24(水) 11:32:06 ID:???

フランチョスとsymfony
http://pc11.2ch.net/test/read.cgi/php/1201177567/

symfony忘れんな。うじ虫。

11 ：nobodyさん：2008/12/24(水) 12:16:54 ID:???

なんか言葉の感覚が違うんだろうな。
>>10は日本語が不自由ですか？

12 ：nobodyさん：2008/12/24(水) 17:13:04 ID:???

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

13 ：nobodyさん：2008/12/25(木) 02:33:24 ID:???

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

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

14 ：nobodyさん：2008/12/25(木) 03:17:52 ID:???

すまん頭が血迷ってた
どんな環境でZF使ってる？

15 ：nobodyさん：2008/12/25(木) 04:04:54 ID:???

>>14
開発環境かな? 運用環境じゃないよね。

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

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

16 ：nobodyさん：2008/12/25(木) 13:43:50 ID:???

>>15
VS.Phpの使い心地ってどんな感じ?

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

17 ：nobodyさん：2008/12/25(木) 23:33:30 ID:???

>>16
そこまで書くとｽﾚ違いになちゃうな。
以前はIDEｽﾚがあったけど。

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

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

18 ：nobodyさん：2008/12/25(木) 23:44:29 ID:???

ｽﾚ違いﾈﾀ続きでｽﾏｿ。
日本語版も含めてなんか出てきた。
ttp://www.jcxsoftware.com/jcx/node/2525
ただ、リンク先の証明書が無効だと火狐で警告が出ます。

19 ：nobodyさん：2008/12/25(木) 23:51:17 ID:???

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

20 ：nobodyさん：2008/12/26(金) 09:54:44 ID:???

ってかリンク切れしとるんだけど・・・SSLのせい？

21 ：nobodyさん：2008/12/27(土) 01:31:19 ID:???

フレームワークまったく使ったことないけどなんなん？
使うとどんな感じなん？

22 ：nobodyさん：2008/12/27(土) 01:55:26 ID:???

>>21
なんか下半身がもぞもぞします

23 ：nobodyさん：2008/12/27(土) 12:41:38 ID:???

>>21
なんやろねー

24 ：nobodyさん：2008/12/29(月) 15:26:56 ID:???

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

25 ：nobodyさん：2008/12/29(月) 15:37:33 ID:???

誤爆しました。すみません。

26 ：nobodyさん：2008/12/29(月) 20:34:55 ID:???

PHP → Zend → イスラエル → パレスチナ → 爆撃 → 誤爆？

27 ：nobodyさん：2008/12/29(月) 20:36:32 ID:???

HP → Zend → イスラエル → パレスチナ → 爆撃 → 誤爆→PHP脂肪ｗｗｗ

28 ：nobodyさん：2009/01/01(木) 09:20:32 ID:???

新年あけましておめでとう→PHP脂肪ｗｗｗ

29 ：nobodyさん：2009/01/01(木) 13:10:51 ID:???

guesswork for PHP5をお年玉にお願いします

30 ：nobodyさん：2009/01/02(金) 01:48:51 ID:???

>>26
まあ徴兵制だろうね。
終戦前に成人した世代と戦後世代の日本人を見比べれば一目瞭然。

31 ：nobodyさん：2009/01/02(金) 12:39:17 ID:???

今年一番来るフレームワークはどれだ?
2009 PHPフレームワークダービー

出走場受付中

32 ：nobodyさん：2009/01/02(金) 12:44:31 ID:???

>>31
>出走場受付中

出走馬ではないの？

33 ：nobodyさん：2009/01/03(土) 18:39:59 ID:???

>>32
2chでそんな細かいこと言ってると嫌われちゃうぞー

34 ：nobodyさん：2009/01/06(火) 14:44:09 ID:???

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

35 ：nobodyさん：2009/01/06(火) 17:59:40 ID:???

そんなつごうのいいのはない

36 ：nobodyさん：2009/01/06(火) 18:25:39 ID:???

>>32
うひー、ほんとだ(汗
typoご容赦。

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

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

37 ：nobodyさん：2009/01/06(火) 19:22:42 ID:???

そんなことする価値あるの？

38 ：nobodyさん：2009/01/06(火) 19:36:39 ID:???

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

39 ：nobodyさん：2009/01/06(火) 19:38:50 ID:???

JavaScriptオフの環境への対応でもある

40 ：nobodyさん：2009/01/06(火) 19:47:32 ID:???

このサイトはInternetExplorer6.0でのみ確認しています

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

41 ：nobodyさん：2009/01/06(火) 19:53:28 ID:???

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

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

42 ：nobodyさん：2009/01/06(火) 20:10:38 ID:???

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

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

43 ：nobodyさん：2009/01/06(火) 20:21:09 ID:???

>>42
それ、JavaScript動くの？JSのエンジンはどこにあるんだろう・・・

44 ：nobodyさん：2009/01/06(火) 20:24:31 ID:???

昔ここで見た
サーバサイドもJavaScriptで書いちゃえばいいんだよ！
ってネタレスを思い出した。

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

45 ：nobodyさん：2009/01/06(火) 20:27:27 ID:???

あ、そか。JSのエンジンが必要だった。逆に、それがあればCURLは関係ないなｗ
サーバーサイドJavaScriptを使うしかないか。

46 ：nobodyさん：2009/01/06(火) 20:30:15 ID:???

rinoとか

47 ：nobodyさん：2009/01/06(火) 20:36:03 ID:???

SpiderMonkeyのPHPバインディングとか、サーバサイドJavaScriptの選択肢もいくつかあるよ

48 ：nobodyさん：2009/01/06(火) 21:48:54 ID:???

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

49 ：nobodyさん：2009/01/06(火) 21:58:01 ID:???

YiiのJPフォーラムに投稿があってうれしい

50 ：nobodyさん：2009/01/06(火) 22:25:49 ID:???

最近サーバサイドJSも現実的な選択肢になってきたみたいね
故にPHP脂肪ｗｗｗ

51 ：nobodyさん：2009/01/06(火) 23:00:54 ID:???

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

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

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

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

52 ：48：2009/01/06(火) 23:36:43 ID:???

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

53 ：36：2009/01/07(水) 00:37:15 ID:???

>>39
そう、Progressive Enhancementというやつです。

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

54 ：nobodyさん：2009/01/07(水) 00:57:38 ID:???

VBでクライアントアプリケーション作ってサーバサイドアプリと通信しなよ

55 ：nobodyさん：2009/01/07(水) 08:08:02 ID:???

>>34
今は亡きｗ HTML_QuickFormに、一応JavaScriptコードの自動出力機能がついてたなあ

56 ：nobodyさん：2009/01/07(水) 10:01:31 ID:???

DBｸｴﾘｰ必要なﾊﾞﾘﾃﾞｰｼｮﾝもある

57 ：nobodyさん：2009/01/07(水) 22:34:19 ID:???

それ、バリデーションって言うか？

58 ：nobodyさん：2009/01/07(水) 23:01:29 ID:???

IDの重複チェックや郵便番号の存在チェックとかだろ

59 ：nobodyさん：2009/01/08(木) 10:31:01 ID:???

それは普通にAjaxでやればいいわけで

60 ：nobodyさん：2009/01/08(木) 10:39:22 ID:???

Ajaxっていったって、DB内のIDと重複するかチェックするなら(ry

61 ：nobodyさん：2009/01/08(木) 11:31:26 ID:???

>>59
まさか郵便番号何十万件もJSの配列につっこんどくつもりか

62 ：nobodyさん：2009/01/08(木) 11:32:22 ID:???

クライアントレベルでは簡易的なチェックでいいんだから問題なし

63 ：nobodyさん：2009/01/08(木) 11:40:10 ID:???

> 簡易的なチェックでいいんだから問題なし

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

64 ：nobodyさん：2009/01/08(木) 12:08:22 ID:???

ん？なんでAjaxでJSの配列？

65 ：nobodyさん：2009/01/08(木) 12:44:42 ID:???

AjaxからDBにクエリ投げて検証した結果のIDをhiddenなりtextなりに突っ込んでPOSTし
POST先のサーバコードでまたDBにクエリ投げて検証してってやるわけですね

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

66 ：nobodyさん：2009/01/08(木) 15:02:15 ID:???

なんなのこの低ﾚﾍﾞﾙｗ

67 ：nobodyさん：2009/01/08(木) 15:51:12 ID:???

>>64
DBアクセスしないで何処からデータ持ってくるんだ

68 ：nobodyさん：2009/01/08(木) 16:23:15 ID:???

DBアクセスとJSの配列になんの関係が？

69 ：nobodyさん：2009/01/08(木) 16:51:55 ID:???

なんなのこの超低ﾚﾍﾞﾙｗ

70 ：nobodyさん：2009/01/08(木) 19:17:03 ID:???

>>68

71 ：nobodyさん：2009/01/08(木) 21:05:54 ID:???

Ajax万能説かｗ

72 ：nobodyさん：2009/01/08(木) 21:47:23 ID:???

隙を見せないように要点を得ない短文ばかりで話すらかみ合ってない

73 ：nobodyさん：2009/01/09(金) 04:32:42 ID:???

>要点を得ない

74 ：マジレス希望：2009/01/09(金) 12:19:55 ID:???

皆さん、JavaScriptはどうやって勉強されましたか？
・オススメの勉強方法
・オススメの解説書
・オススメのサイト
があれば是非ご紹介ください。m(__)m

75 ：nobodyさん：2009/01/09(金) 13:04:59 ID:???

ぐぐる

76 ：nobodyさん：2009/01/09(金) 13:27:38 ID:???

>>74
一撃必殺

77 ：nobodyさん：2009/01/09(金) 19:17:31 ID:???

>>74
スレチだろ、よそで聞いたほうがまともな答えが返ってくると思うぞ。

78 ：nobodyさん：2009/01/11(日) 12:53:52 ID:???

ストリームベースのフレームワーク
http://lll-framework.hikosha.jp/

なんだこれ

79 ：nobodyさん：2009/01/12(月) 00:02:56 ID:???

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

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

80 ：nobodyさん：2009/01/12(月) 11:46:05 ID:???

>>79
すまない。orz

不具合を修正しました。
http://lll-framework.hikosha.jp/release/lll-framework-0.1.3.tar.gz

81 ：nobodyさん：2009/01/12(月) 22:55:46 ID:???

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

82 ：nobodyさん：2009/01/12(月) 23:03:14 ID:???

>>80
2chで釣りとか
作者必死だな・・・

83 ：nobodyさん：2009/01/12(月) 23:12:01 ID:???

>>78
知らないフレームワークがまだあったか。
とりあえず捕捉した。

84 ：nobodyさん：2009/01/13(火) 00:52:46 ID:???

>>78
ネタが増えるのはいいことだけど・・・
ざっくりサイトだけ読んでみて

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

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

85 ：nobodyさん：2009/01/13(火) 01:01:58 ID:???

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

86 ：nobodyさん：2009/01/13(火) 01:26:26 ID:???

試してみることもないからどっちでもいいよ

87 ：nobodyさん：2009/01/13(火) 02:22:51 ID:???

php4はさっさと切ってほしいな。
メソッドにアクセス修飾子がないといらいらする。

88 ：nobodyさん：2009/01/14(水) 00:02:14 ID:???

そんな事どうでもいいけどな

89 ：nobodyさん：2009/01/14(水) 02:16:40 ID:???

アクセス修飾子があるスクリプト言語の方が少ない

90 ：nobodyさん：2009/01/14(水) 02:30:44 ID:???

>>89
PerlにもRubyにもありますが

91 ：nobodyさん：2009/01/14(水) 02:34:16 ID:???

少ないね

92 ：nobodyさん：2009/01/14(水) 02:35:52 ID:???

protectedがあるスクリプトは少ない

93 ：nobodyさん：2009/01/14(水) 05:57:49 ID:???

protectedがないとtemplate methodが分かりにくいよな
その点で他のLLは糞

94 ：nobodyさん：2009/01/14(水) 10:09:53 ID:???

どうしようもないばかだな

95 ：nobodyさん：2009/01/14(水) 15:21:39 ID:???

>>94
自分への嘆きかｗ

96 ：nobodyさん：2009/01/14(水) 21:39:54 ID:???

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

97 ：nobodyさん：2009/01/14(水) 21:47:37 ID:???

本末転倒だな

98 ：nobodyさん：2009/01/16(金) 16:43:30 ID:???

http://jibun.atmarkit.co.jp/ljibun01/rensai/genius/03/02.html
林氏：Javaを勉強した後、RubyやPerl、Pythonの文法が面白くて眺めてました。

↓

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

99 ：nobodyさん：2009/01/16(金) 18:21:10 ID:???

文法が面白くてPHP使ってるんじゃないしな
CやJavaと殆ど同じようなもんだし

100 ：nobodyさん：2009/01/16(金) 18:26:35 ID:???

Perlの文法の何が面白いのかわからん

101 ：nobodyさん：2009/01/16(金) 18:27:40 ID:???

＞CやJavaと殆ど同じようなもんだし

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

102 ：nobodyさん：2009/01/16(金) 18:38:04 ID:???

大きく間違ってはいないと思うけど？
つーか、そこにツッコミ入れる奴って…３年ROMってｒ（ｒｙ

103 ：nobodyさん：2009/01/16(金) 18:58:53 ID:???

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

104 ：nobodyさん：2009/01/16(金) 19:10:15 ID:???

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

105 ：nobodyさん：2009/01/16(金) 19:10:48 ID:???

ＰＨＰはウェブありきで作られた言語だから面白みを問われたらちょっとな・・

Ｃ言語の有名サイトにこんなものがある
ttp://www.kojima-cci.or.jp/fuji/mybooks/cdiag/cdiag.14.6.html

106 ：nobodyさん：2009/01/16(金) 19:25:15 ID:???

Perlはelsifみたいなどうでもいい省略さえなければもっと使いやすいのに
逆に打ち間違うわ

107 ：nobodyさん：2009/01/16(金) 19:27:33 ID:???

そしてその不評な省略形式を丸々真似てしまったRuby

108 ：nobodyさん：2009/01/16(金) 20:43:49 ID:???

elsifだとどんなメリットがあるんだ？

109 ：nobodyさん：2009/01/16(金) 23:54:23 ID:???

else if
elsif

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

110 ：nobodyさん：2009/01/16(金) 23:55:15 ID:???

最初に触ったのがPerlだったせいで、
いまでもときどき elsif と elseif と else if がごっちゃになって困るｗ

111 ：nobodyさん：2009/01/17(土) 00:12:33 ID:???

シェルも触るとelifまで候補に入ってさらにカオスw

112 ：nobodyさん：2009/01/17(土) 00:29:45 ID:???

うわあああ

113 ：nobodyさん：2009/01/19(月) 01:23:11 ID:???

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

114 ：nobodyさん：2009/01/19(月) 09:58:52 ID:???

つコメント

115 ：nobodyさん：2009/01/19(月) 12:07:45 ID:???

>>113
vimになかったか？

116 ：nobodyさん：2009/01/19(月) 22:45:12 ID:???

何だかんだ言って一番馬鹿にされてるPHPが最強言語だよね(´・ω・`)

117 ：nobodyさん：2009/01/19(月) 22:51:44 ID:???

ラズベリー賞しかり、イグノーベル賞しかり。

118 ：nobodyさん：2009/01/20(火) 10:49:51 ID:???

>>116
Webで便利なだけでしょ。Web以外はPerl使ってるよ。最近PHPにも懲りてWebもPerlも使い出した。
Catalystマンセー

119 ：nobodyさん：2009/01/20(火) 11:49:35 ID:???

>>118
Catalystもそうだけど、CPAN万歳になるのが初動でのネックだと感じてる。
導入だけ、って考えるならPHPのフレームワークのほうがよほど楽。

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

120 ：nobodyさん：2009/01/20(火) 12:00:08 ID:???

>>119
そう。PHPはWeb以外では殆ど使い物にならないから、
最強言語だよねとか言われると困る。

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

121 ：nobodyさん：2009/01/20(火) 12:23:13 ID:???

PHPはWebでしか使えないというけど別に使えるんだけどな普通のスクリプトとしても

122 ：nobodyさん：2009/01/20(火) 12:26:00 ID:???

使えないとは言ってないよ。使わないけど。

123 ：nobodyさん：2009/01/20(火) 12:26:09 ID:???

ちょっとしたスクリプトもPHPで作ってる
普段使ってるから作りやすくて楽

124 ：nobodyさん：2009/01/20(火) 12:58:05 ID:???

*nixの管理ツールなどでPHPで作られたものなんて見たことない。
使われているのはPerl、Python、Rubyのどれかだろ。

125 ：nobodyさん：2009/01/20(火) 13:08:13 ID:???

PHPはmod_php以外だとはっきり言って魅力ないからな

126 ：nobodyさん：2009/01/20(火) 13:15:22 ID:???

>>124
たまにＰＨＰ自作ツール見かけて「ぷっ」と思う。
なんかそんなイメージ。

127 ：nobodyさん：2009/01/20(火) 13:17:21 ID:???

>>124
shを忘れないで下さい。

128 ：nobodyさん：2009/01/20(火) 13:22:10 ID:???

cronで回しているウェブ用データ整理はCLI
自作ライブラリ使い回せるし

129 ：nobodyさん：2009/01/20(火) 13:31:39 ID:???

>>128
他人がいじれない確率が高いのがネックだな。

130 ：nobodyさん：2009/01/20(火) 13:37:08 ID:???

>>128
それはWEBアプリの一部ではないのだろうか。

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

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

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

131 ：nobodyさん：2009/01/20(火) 14:53:10 ID:???

>>124
監視しない方ですか

132 ：nobodyさん：2009/01/20(火) 15:09:20 ID:???

>>124
RubyはないだろJK
いや少しはあるかもしれんが、
基本はPerlかPython。

133 ：nobodyさん：2009/01/20(火) 15:15:18 ID:???

おれの基本はbash

134 ：nobodyさん：2009/01/20(火) 15:52:58 ID:???

OSやM/W自体の監視と、そこで動くアプリケーションの監視を混同してないか？

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

135 ：nobodyさん：2009/01/20(火) 19:57:05 ID:???

>>132
言っちゃダメーｗｗｗｗ

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

136 ：nobodyさん：2009/01/20(火) 20:29:13 ID:???

は？puppetなんかはrubyで書かれてますが何か
今時perlなんて類人猿しか使ってねーし

137 ：nobodyさん：2009/01/20(火) 22:54:13 ID:???

このスレでそんなこと言ってもねぇ

138 ：nobodyさん：2009/01/21(水) 00:00:34 ID:???

Agaviの次のリリースではコマンドラインからの呼び出しがサポートされるよ。
http://trac.agavi.org/ticket/480

139 ：nobodyさん：2009/01/21(水) 00:07:16 ID:???

agavi静かに進んでたんだなｗ

140 ：nobodyさん：2009/01/21(水) 03:12:08 ID:???

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

141 ：nobodyさん：2009/01/21(水) 03:25:00 ID:???

Rubyは立ち位置が微妙だよな
ニッチ言語でもないし

142 ：nobodyさん：2009/01/21(水) 07:20:17 ID:???

なんというか利点がないんだよな。Ruby使う

143 ：nobodyさん：2009/01/21(水) 08:54:04 ID:???

Ruby/RoRのModelで関連テーブルが扱えないのは治ったのか？
俺はあれでRoRって使えねーって思ったんだが。

144 ：nobodyさん：2009/01/21(水) 10:38:16 ID:???

企業からすれば、習得のためのコストは少ないほうが良いに決まっている。

145 ：nobodyさん：2009/01/21(水) 11:00:58 ID:???

>>144
出来る人間なら習得コストは同じだよ。何でもすぐ覚える。勝手に覚える。
知らない間にPerlとかに手を出してる。

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

146 ：nobodyさん：2009/01/21(水) 11:03:52 ID:???

嫌とか嫌じゃないかの問題じゃなく、
コストの問題でしょ

147 ：nobodyさん：2009/01/21(水) 11:16:40 ID:???

>>146
教材は何でもいいよ。ダメなら切るだけ。だからコストは一緒。
出来る人間がPHP覚えるのもPerl覚えるのも大差ない。

148 ：nobodyさん：2009/01/21(水) 11:27:19 ID:???

出来る人間だけ揃えられる企業ならともかく、
能力にばらつきがあるのが世の常でしょ

149 ：nobodyさん：2009/01/21(水) 11:30:39 ID:???

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

150 ：nobodyさん：2009/01/21(水) 12:27:49 ID:???

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

151 ：nobodyさん：2009/01/21(水) 13:08:07 ID:???

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

152 ：nobodyさん：2009/01/21(水) 13:38:39 ID:???

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

153 ：nobodyさん：2009/01/22(木) 03:26:59 ID:???

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

154 ：nobodyさん：2009/01/22(木) 03:33:43 ID:???

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

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

155 ：nobodyさん：2009/01/22(木) 04:44:46 ID:???

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

156 ：nobodyさん：2009/01/22(木) 04:53:28 ID:???

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

157 ：nobodyさん：2009/01/22(木) 05:37:45 ID:???

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

158 ：nobodyさん：2009/01/23(金) 02:44:44 ID:???

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

159 ：nobodyさん：2009/01/23(金) 08:09:25 ID:???

お前はアホか

160 ：nobodyさん：2009/01/27(火) 00:00:53 ID:???

Yiiいいじゃん

161 ：nobodyさん：2009/01/27(火) 23:42:06 ID:???

>>160
そうなの？

162 ：nobodyさん：2009/01/28(水) 00:04:30 ID:???

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

163 ：nobodyさん：2009/01/28(水) 00:05:19 ID:???

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

164 ：nobodyさん：2009/01/28(水) 00:12:52 ID:???

PDOをPear側で準備・・・？

165 ：nobodyさん：2009/01/28(水) 00:26:31 ID:???

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

166 ：nobodyさん：2009/01/28(水) 00:52:28 ID:???

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

167 ：nobodyさん：2009/01/28(水) 00:55:30 ID:???

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

168 ：nobodyさん：2009/01/28(水) 01:01:34 ID:VWeywu5Y

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

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

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

169 ：nobodyさん：2009/01/28(水) 07:10:16 ID:???

信者ｗ

170 ：nobodyさん：2009/01/28(水) 08:17:44 ID:???

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

171 ：nobodyさん：2009/01/28(水) 08:19:43 ID:???

ペドなんか使うなよ

172 ：nobodyさん：2009/01/28(水) 11:10:45 ID:???

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

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

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

173 ：nobodyさん：2009/01/28(水) 11:22:29 ID:???

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

174 ：nobodyさん：2009/01/28(水) 12:50:21 ID:???

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

175 ：nobodyさん：2009/01/28(水) 15:17:58 ID:???

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

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

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

176 ：nobodyさん：2009/01/28(水) 15:47:25 ID:???

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

177 ：nobodyさん：2009/01/28(水) 22:52:50 ID:???

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

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

178 ：nobodyさん：2009/01/28(水) 23:53:34 ID:???

>>176
なんで思ったの？

179 ：nobodyさん：2009/01/29(木) 00:07:10 ID:???

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

180 ：nobodyさん：2009/01/29(木) 01:00:41 ID:???

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

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

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

181 ：nobodyさん：2009/01/29(木) 01:21:22 ID:???

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

182 ：nobodyさん：2009/01/29(木) 01:35:52 ID:???

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

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

183 ：nobodyさん：2009/01/29(木) 01:41:58 ID:???

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

184 ：nobodyさん：2009/01/29(木) 01:51:42 ID:???

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

185 ：nobodyさん：2009/01/29(木) 18:23:40 ID:???

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

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

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

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

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

186 ：nobodyさん：2009/01/29(木) 18:26:56 ID:???

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

187 ：nobodyさん：2009/01/29(木) 18:31:21 ID:???

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

188 ：nobodyさん：2009/01/29(木) 18:42:10 ID:???

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

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

ということです。

189 ：nobodyさん：2009/01/29(木) 20:08:05 ID:???

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

190 ：nobodyさん：2009/01/29(木) 20:15:44 ID:???

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

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

191 ：nobodyさん：2009/01/29(木) 20:45:27 ID:???

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

192 ：nobodyさん：2009/01/29(木) 20:52:01 ID:???

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

193 ：nobodyさん：2009/01/29(木) 21:12:16 ID:???

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

194 ：nobodyさん：2009/01/29(木) 22:59:54 ID:???

>>185,188

195 ：nobodyさん：2009/01/29(木) 23:22:59 ID:???

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

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

196 ：195：2009/01/29(木) 23:33:39 ID:???

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

197 ：nobodyさん：2009/01/29(木) 23:48:44 ID:???

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

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

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

198 ：nobodyさん：2009/01/30(金) 00:47:54 ID:???

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

199 ：nobodyさん：2009/01/30(金) 00:56:28 ID:???

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

200 ：nobodyさん：2009/01/30(金) 02:29:11 ID:???

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

201 ：nobodyさん：2009/01/30(金) 03:47:52 ID:???

煽ってるとこすまんが、同意するよ。
PythonやらRubyやらPerlがphpと比べてどうのとか、
ぜんぜん関係なかったし。

202 ：nobodyさん：2009/01/30(金) 08:04:53 ID:???

>>197
>セキュアなページに入ってきたら、必ず一度はそのユーザーの有効性を確認するように実装するのが当然。

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

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

203 ：nobodyさん：2009/01/30(金) 08:27:30 ID:???

だから、個別のサービス思想に絡んだ設計の問題なわけでそ。

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

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

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

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

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

204 ：nobodyさん：2009/01/30(金) 08:44:58 ID:???

>>202
盗まれても良いための「ワンタイム」トークンじゃないの？

205 ：nobodyさん：2009/01/30(金) 10:08:00 ID:???

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

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

206 ：nobodyさん：2009/01/30(金) 10:33:33 ID:???

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

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

207 ：nobodyさん：2009/01/30(金) 10:39:58 ID:???

>>203
> だから、個別のサービス思想に絡んだ設計の問題なわけでそ。
そういう場合に、どっちの方式をとるかは設計の問題だね。

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

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

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

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

208 ：nobodyさん：2009/01/30(金) 10:43:17 ID:???

>>197
> 匿名の個人情報が見れるだけで実害はほとんどない。

これは笑う所かいな？ｗ

個人情報＝本名・住所等

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

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

209 ：nobodyさん：2009/01/30(金) 10:46:19 ID:???

>別ウインドウを出したとき問題になる。

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

210 ：nobodyさん：2009/01/30(金) 10:49:28 ID:???

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

211 ：nobodyさん：2009/01/30(金) 10:51:55 ID:???

>>208
もしかしてそこが笑うところ？
> 個人情報＝本名・住所等

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

212 ：nobodyさん：2009/01/30(金) 10:52:36 ID:???

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

ない。

213 ：nobodyさん：2009/01/30(金) 10:55:22 ID:???

毎回セッションIDを変える方法は
連続でリロードすると問題になる。

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

214 ：nobodyさん：2009/01/30(金) 10:55:54 ID:???

>>207
> だけどフレームワークの意味をもう一度思い出してほしい。
> 汎用的で複雑な処理を簡単に実装できることだ。

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

215 ：nobodyさん：2009/01/30(金) 10:57:40 ID:???

>>213
あほ？

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

216 ：nobodyさん：2009/01/30(金) 10:57:52 ID:???

セキュアページに入る前に
必ず認証が必要だというが、
Amazonはそうなっていない。

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

217 ：nobodyさん：2009/01/30(金) 11:00:03 ID:???

>>215
だが、Amazonは別ウインドウを出しても、連続リロードしても問題ない。

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

218 ：nobodyさん：2009/01/30(金) 11:01:38 ID:???

>>216
アマゾンはそうなってるよ。
すでにセキュアトークンを持ってれば別

フレームワーク乞食乙

219 ：nobodyさん：2009/01/30(金) 11:04:46 ID:???

>>218
それは、ブラウザ起動して初めてログインした場合だろ。

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

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

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

220 ：nobodyさん：2009/01/30(金) 11:12:49 ID:???

>>214
> 関数一発挟むだけなのに、それをプロパティで設定しろってか。

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

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

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

221 ：nobodyさん：2009/01/30(金) 11:23:06 ID:???

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

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

222 ：nobodyさん：2009/01/30(金) 11:24:24 ID:???

>>219
それで何が不満なの？
なにかセキュリティ上の問題があるなら指摘してください

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

223 ：nobodyさん：2009/01/30(金) 11:25:39 ID:???

>>219
> すでにセキュアトークンを持ってれば別
ってちゃんと書いてるだろ。

224 ：nobodyさん：2009/01/30(金) 11:39:10 ID:???

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

225 ：nobodyさん：2009/01/30(金) 12:33:45 ID:???

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

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

226 ：225：2009/01/30(金) 12:35:02 ID:???

追記：
「Webアプリケーションフレームワークが」提供すべきかどうか、ね。

227 ：nobodyさん：2009/01/30(金) 12:46:45 ID:???

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

228 ：nobodyさん：2009/01/30(金) 13:17:58 ID:???

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

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

229 ：nobodyさん：2009/01/30(金) 13:34:34 ID:???

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

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

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

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

230 ：nobodyさん：2009/01/30(金) 13:36:33 ID:???

CakePHPは実際AuthComponentで誰でもログインできるってバグ出して死亡したけどなｗ
ああいうのはFWで吸収しない方がいい

231 ：nobodyさん：2009/01/30(金) 13:38:02 ID:???

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

232 ：nobodyさん：2009/01/30(金) 13:43:38 ID:???

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

233 ：nobodyさん：2009/01/30(金) 13:53:53 ID:???

cookieのsecure属性を理解してないヤツが混じってる予感。

234 ：nobodyさん：2009/01/30(金) 13:57:42 ID:???

>>230
それは、バグがあるのがわるいだけだろｗ

235 ：nobodyさん：2009/01/30(金) 14:24:52 ID:???

ごっつい根本的な質問で恐縮ですが
PHPって複数のセッションを同時に利用することってできるの？
それができるかできないかで、ものすごく話が変わってくるような。

・・・できないんだろうな。$_SESSION だもんな・・・

236 ：nobodyさん：2009/01/30(金) 14:32:51 ID:???

>>235
微妙にスレチだぞ＞くだすれ行けって感じだが・・・

無理やりFWレイヤーの話に持ってくると、Zend_Sessionではセッションの配列で
ネームスペース的な扱いをして、使い分けている。
でも、そういう意味じゃなくて、上の流れで、セキュアセッションと平文セッションを
分割して持てるか？って話をしたいわけだよな？
PHPが受け入れるセッションID自体は一つ。それは正しい。

解は二つ。
クッキーと独自のバックエンドを使って、自前でセッション機構を作る。
セッションを理解してれば、簡単。
ちなみにYahoo!はPHPでこの方式を採用してる。

もう一つは、セッションそのものは永続化しておいて、セッションネームスペース内
に侵入を許す際に、そのネームスペースに対する適切なアクセスかどうかを個別のクッキーで検証する。
ZFで実装してるやつはたぶんこれがFA

237 ：nobodyさん：2009/01/30(金) 14:42:03 ID:???

>>234
いや
これがCakePHPだから、セキュリティ情報として全世界にこういうバグありますよって公開されちゃうわけよ。
その情報を見てクラッカーが仕掛けてくる可能性が高い。
もし仮に自分で全て実装したものに同じバグがあったとしても、よっぽどしっかりクラックされない限り、誰にも知られることはない。

238 ：nobodyさん：2009/01/30(金) 14:47:27 ID:???

>>236
> でも、そういう意味じゃなくて、上の流れで、セキュアセッションと平文セッションを
> 分割して持てるか？って話をしたいわけだよな？

ですです。それができれば、盗聴（非SSL）でセッションハイジャックされたとしても
その中には非セキュア用の情報しかないし、セキュア用のセッション（ログイン状態）等と
簡単に切り分けできるなーと。

ただ、他の言語の実装をみても、「セッション」ってもの自体の考え方が、どうやらサーバ-
クライアントで1対1っぽい？

＞解は二つ。
もう一つ、セッションはあくまでsecureで利用して、非セキュアな情報はみんなCookieに
放り込めばいいじゃない！ってふと思いついた。
最低4KB×20(50？)個なら、とりあえず普通に使えそうとか。

239 ：nobodyさん：2009/01/30(金) 14:54:52 ID:???

Cookie切ってる奴多いのに通用するのかそれ
セキュリティソフトのせいで動きませんみたいなサイトになるぞ

240 ：nobodyさん：2009/01/30(金) 15:02:01 ID:???

Cookie切ってる奴多い？
根拠は？

241 ：nobodyさん：2009/01/30(金) 15:09:40 ID:???

>>239
もしかしてセッションIDをフォームに手で埋めるのが標準？
まじでか

242 ：nobodyさん：2009/01/30(金) 15:14:39 ID:???

>>239
Cookie切ったら普通にセッション動かないけど？

243 ：nobodyさん：2009/01/30(金) 15:15:10 ID:???

みなさ～ん、そろそろスレチですよっと。

244 ：nobodyさん：2009/01/30(金) 15:18:00 ID:???

ほかの言語の話になってるよりましだし、いいんじゃないの？

245 ：nobodyさん：2009/01/30(金) 15:32:12 ID:???

SSLの話題が出ているので便乗質問。

共有SSLに対応しているフレームワークってある？

http://www.aaa.com/
https://www.rental-server.com/~aaa.com/

こうなっているときに、ドメイン名違うし、パス違うしで
セッション保てないわで、困るんだよね。

246 ：nobodyさん：2009/01/30(金) 15:33:30 ID:???

クッキー切ってるような変人相手にする必要なし
むしろブラクラに飛ばしてやれ

247 ：nobodyさん：2009/01/30(金) 15:34:14 ID:???

Cookie切ってセッション動かないとかどんなクソ実装だよ
それじゃ携帯サイト対応できねーじゃん

248 ：nobodyさん：2009/01/30(金) 15:39:41 ID:???

うーん。セキュリティ周りをちゃんと説明しているサイトが見つからない。

クッキー切っている場合（携帯対応）のセッションで
cookieにsecure属性をつけた場合の動作と同じことを
ちゃんとやっているのか確証を得たいが見つからない。

249 ：nobodyさん：2009/01/30(金) 15:48:16 ID:???

Cookieが普通で携帯が異常なだけだろ。

250 ：nobodyさん：2009/01/30(金) 15:54:21 ID:???

DoCoMoの携帯がクッキー非対応で異常だからってことで、
非対応にしてるサイトってあんまないけどな。
結局Cookie使わなくてもセッションは維持できる。

251 ：nobodyさん：2009/01/30(金) 16:09:01 ID:???

>>247
携帯サイト、なんて、そりゃぁもう。機種ごとにハンドメイドだよ。
これを解決してるオープンソースのフレームワークはない。

PerlならMobaSifがあるけどなぁ。

252 ：nobodyさん：2009/01/30(金) 16:17:17 ID:???

>>245
>>236,238の流れから言うと、まさにセキュアと非セキュアでセッションが
分離出来てていいじゃないかｗ
分離されすぎてクッキーすらデータの受け渡しに使えないけどな
どうやってフレームワークに組み込めばいいんだろう

クッキー切ってる人相手にシステム作ってる人なら、もともとドメイン関係ないし
素晴らしいフレームワークを持ってるんでは無かろうか

253 ：nobodyさん：2009/01/30(金) 16:23:31 ID:???

URLにセッションID差し込んでCookie使わない実装にするのなんて普通だろ
IDはアクセス毎に変える

254 ：nobodyさん：2009/01/30(金) 16:30:00 ID:???

>>253
これを言い出すと、もうセッションIDのクッキーをsecureにする意味もないな

255 ：nobodyさん：2009/01/30(金) 16:40:23 ID:???

>>253
PHPの$_SESSION自体そういう仕様になってなかったか？

256 ：nobodyさん：2009/01/30(金) 17:04:49 ID:???

use_trans_sid

257 ：nobodyさん：2009/01/30(金) 17:05:43 ID:???

まぁ、URLに差し込むだけじゃ携帯全機種対応は無理だけどな。

258 ：nobodyさん：2009/01/30(金) 18:19:42 ID:???

っていうか議論に問題だらけの端末の話を持ってくるのは暴論じゃないか？
携帯サイト対応ってそれだけで一仕事だよ。

259 ：nobodyさん：2009/01/31(土) 01:06:04 ID:???

SSL対応議論、参考になります！(ｷﾘｯ)
この手の話は、頭がこんがらがって十分に理解できていないです。
もっと勉強しなくちゃ、買い物サイトは作れないな～＞＜

260 ：nobodyさん：2009/01/31(土) 02:01:11 ID:???

誰も十分に理解できていないから、
はっきりとした答えが出せないんだろうな。

261 ：nobodyさん：2009/01/31(土) 02:27:29 ID:???

土日を利用して勉強してみましょう

継続を使ったWEBアプリ
http://www.thinkit.co.jp/article/74/1/

Kahuaは継続ベースのアプリケーションサーバ/フレームワーク
http://www.kahua.org/

セッションも良いけど継続もね☆

262 ：nobodyさん：2009/01/31(土) 04:23:52 ID:???

クッキーはサイズの制限があるから結局セッションを使うとして、
そのセッションをどうやって実現しているかだ。

セッションIDの格納にクッキーを使う場合。
非セキュアサイトでのセッションIDは盗聴されるから
非セキュアサイトでのセッションIDと、セキュアサイトのセッションIDは別に持たないといけない。
（セキュアサイトのセッションIDはセキュアサイトでしか送信されない。）

問題は、セキュアサイトでセッションに格納した情報が、非セキュアサイトとセキュアサイトの
セッションIDのどちらに関連付けられているかということ。

もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
盗聴して使えば、他人がセッションの情報を取得することが可能になる。

そもそも、セキュア、非セキュア、二つのセッションIDを持つことがPHP or フレームワークで可能なのか？という問題もある。

263 ：nobodyさん：2009/01/31(土) 07:40:31 ID:???

>>262
おまいさんの理解が浅いということだけはわかった。

何も書かないと単なる煽りと思われるので一つだけ例示すると、

> もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
> 盗聴して使えば、他人がセッションの情報を取得することが可能になる。

それは実装が甘いだけ。
非セキュアサイトに関連付けられたセッションIDを使いまわしたとしても、
たとえば、
「セキュアな情報を表示するためのトークンを持っていなければ表示しない」
という基本的なロジックでラップしてあればセキュアな情報を見ることはできない。

情報のキーになるのはセッションIDだけじゃない。普通にクッキー使うだろ。

264 ：nobodyさん：2009/01/31(土) 11:43:58 ID:???

>セキュアな情報を表示するためのトークン
それって一般にはセッションIDって呼ぶと思うの。

265 ：nobodyさん：2009/01/31(土) 11:53:41 ID:???

いいえ

266 ：nobodyさん：2009/01/31(土) 12:16:29 ID:???

おせっかいなオレが例を出したるわ。
・SSL下でログインに成功したら、トークン($uniq)を育成
・非セキュアなセッションでもいよいので$_SESSION['tokens'][] = sha1($uniq);
・$uniqをsecure属性をつけて、setcookie
・セキュアサイト内では、sha1($_COOKIE['uniq'])がセッションtokensに含まれるか検証。だめなら再認証に飛ばす

すくなくとも$uniqをセッションIDとは言わない。

267 ：nobodyさん：2009/01/31(土) 12:29:26 ID:???

>>266
で、これが有効な手段として、ここまでをライブラリ化して標準装備した
フレームワークは無いのか？無いとしたらどんな問題があるのってところで
やっと>>185,188の質問に戻るわけだし、このスレでの話題になるわけだな。
まあそれに関する議論？もちょろちょろあるが。

おれとしては、添付ライブラリとしてはあってもいいと思うな。くだらんヘルパーを
ごちょごちょつけてるんだから、ついでに。

268 ：nobodyさん：2009/01/31(土) 12:48:08 ID:???

なんで、1行で済む処理をライブラリかしたがるのか、いまだに疑問

269 ：nobodyさん：2009/01/31(土) 12:55:21 ID:???

そんなに欲しかったら開発リクエストすればいいんじゃない？
投票が集まればサクッと作るでしょ。

270 ：nobodyさん：2009/01/31(土) 13:09:29 ID:???

>>268
>>266の処理を一行で書かれたら絶対に読みたくない。

271 ：nobodyさん：2009/01/31(土) 13:31:24 ID:???

>>268が冗長なだけ

272 ：nobodyさん：2009/01/31(土) 13:32:03 ID:???

>>268じゃなくて、>>266

273 ：nobodyさん：2009/01/31(土) 15:14:35 ID:???

>>262-272
マジで参考になります＾＾（もっとやれ的な意味で）

274 ：nobodyさん：2009/01/31(土) 15:30:40 ID:???

フレームワークを勘違いしたひとが沸いて荒らしてくれたおかげでスレの進みが半端ネェ！
たまにこういうことがあるから面白い

275 ：nobodyさん：2009/01/31(土) 15:51:36 ID:???

>>274
フレームワークの話題も振れずかといって実装についての話もできないのに
レスするのって寂しくならないか？

276 ：nobodyさん：2009/01/31(土) 15:51:43 ID:???

>>266
そこら辺の処理をちゃんと説明している本って無い？

277 ：nobodyさん：2009/01/31(土) 15:55:18 ID:???

>>268
> なんで、1行で済む処理をライブラリかしたがるのか、いまだに疑問

それは、君が説明した事からも分かるように、実装の説明をする余地があるからだよ。
そしてこれは汎用的に使える処理であり、ビジネスロジックではない。

ビジネスロジックに集中できるようにしてくれるのがフレームワークのよいところ。

278 ：nobodyさん：2009/01/31(土) 16:03:23 ID:???

汎用的ではない。
インフラの扱いやサイトのセキュリティポリシーや集金ロジックに密接に関係する。

279 ：nobodyさん：2009/01/31(土) 16:04:02 ID:???

>>277
それはフレームワークのよいところを語りたかったわけ？

280 ：nobodyさん：2009/01/31(土) 16:10:55 ID:???

>>277
それが汎用的な処理だっていうんなら、汎用的なクラスを書いてここに貼ってくれ
みんな喜ぶ。

281 ：nobodyさん：2009/01/31(土) 16:45:58 ID:???

>>280
ヒントやるから実装は自分でやれな。

SSL_Login_Class

セキュアにするべきページの一覧や正規表現を設定配列に入れておく。

全てのコントローラのアクション実行前に、セキュアにするべきか一覧に入っているか調べる。
セキュアページにhttpでアクセスしていたら、httpsにリダイレクト

セキュアトークンを持っていなければ、ログインページにリダイレクト
ログインが許可されればセキュアトークンをセット（secure属性を負荷したクッキーを発行）し元のページに戻す。
ログインページはデフォで用意するがカスタマイズ可能。要するにscaffold（土台）

セキュアトークンのサーバー側のデータは、セッションでも独自のファイルやデータベースにも格納可能。
ハッシュはsha1でもそれ以外でも選択可能。

以上のことをやってくれるクラス。

使い方は簡単。CakePHP風に言えば共通のコントローラAppControllerの
componentsに上記のクラスを入れるだけ。これとセキュアページのリストさえあれば
具体的な実装を書かなくてすむ。

282 ：nobodyさん：2009/01/31(土) 16:52:07 ID:???

それのどこが汎用的なんだよ。個別実装べったりじゃん。
日本語の蘊蓄はいらないから、汎用的にするためのインターフェースでも示してくれ。

283 ：nobodyさん：2009/01/31(土) 17:04:17 ID:???

>>282
お前にとって汎用的とはどういうことを指す言葉なんだ？

例を出して説明したまえ。

284 ：nobodyさん：2009/01/31(土) 17:13:02 ID:???

セキュアにするためのロジックだよ。
>>266に書いてあるのは、セキュアなサイトを作る時のHelloWorld
実サイトでは、Yahooにしろamazonでも楽天でも>>266とは別のロジック。

そういうロジックを設定でインジェクションできないなら汎用的とは言わない。

285 ：nobodyさん：2009/01/31(土) 17:15:21 ID:???

>>284

>>281のはロジックの一つだよ。
別のロジックを使いたければ、別のロジックを実装したクラスを
AppControllerのcomponentsに設定すればいいだけ。

これで汎用的になりましたね（笑）

286 ：nobodyさん：2009/01/31(土) 17:18:05 ID:???

あほか、だったら、FWが持ってる認証クラスで十分やんけ

287 ：nobodyさん：2009/01/31(土) 17:20:51 ID:???

んだ。

288 ：nobodyさん：2009/01/31(土) 17:22:06 ID:???

>>286
本当に十分なのか？ FWが持っている認証クラスが
このようなロジックになっているのか？

>>266のロジックなのか？それともYahoo、Amazon、楽天のロジックのなのか？

それが、そもそもの>>185,188の質問だろうが。
> フレームワークのSSL対応ってどうなっているのでしょうか？

それで答えは？

289 ：nobodyさん：2009/01/31(土) 17:24:30 ID:???

>>288
結局、>>281に書いたクラスで、何かサービスを実装しようと思ったら、その
ロジックを実装したクラスを設定するわけだろ。
それなら、FWが持ってる認証クラスのアサーションにそのロジックを指定するだけ。

>> フレームワークのSSL対応ってどうなっているのでしょうか？
> それで答えは？

対応する必要なし。

290 ：nobodyさん：2009/01/31(土) 17:26:44 ID:???

>>289
> それなら、FWが持ってる認証クラスのアサーションにそのロジックを指定するだけ。

そのロジックをお前は毎回作るのか？
そのロジックは使いまわし出来るだろ？

それを汎用的という。

291 ：nobodyさん：2009/01/31(土) 17:27:35 ID:???

>>285
> >>281のはロジックの一つだよ。

うは、コンクリートじゃんおもいっきり

292 ：nobodyさん：2009/01/31(土) 17:28:05 ID:???

> 結局、>>281に書いたクラスで、何かサービスを実装しようと思ったら、その

考え方がおかしいね。 >>281のクラスを使ってサービスを実装するんじゃない。

なにかのサービスを実装したとき、>>281のクラスを利用する。

考え方が逆だよ。

293 ：nobodyさん：2009/01/31(土) 17:28:45 ID:???

>>291
コンクリートだねぇ。だからなに？

294 ：nobodyさん：2009/01/31(土) 17:29:28 ID:???

>>290
元はといえば、お前さんの書いたクラスのサンプルが汎用的じゃないわけだろ。
ロジックはサイトの管理ポリシーによって違うでしょ。
それをカバーできるようは汎用的な設計を示してから言ってくれ。

295 ：nobodyさん：2009/01/31(土) 17:30:02 ID:???

>>293
汎用的じゃないって、告白ありがとう

296 ：nobodyさん：2009/01/31(土) 17:31:17 ID:???

>>292

>>281のクラスじゃ実装できないサービスがてんこ盛りなんですが

297 ：nobodyさん：2009/01/31(土) 17:32:13 ID:???

>>294
お前はロジックという言葉の使い方がおかしい。
管理ポリシーは違っても、それを実装するロジック（数パターンある）は同じ。
ロジックと管理ポリシーは違うもの。

298 ：nobodyさん：2009/01/31(土) 17:35:29 ID:???

>>297
まぁ、そういうことだろうな。
数パターンしか思いつかないレベルならいいや。おまえさんすごいよ。

299 ：nobodyさん：2009/01/31(土) 17:38:04 ID:???

>>295
あのなぁ。お前、コンクリートと汎用的とは別の考え方だよ。
GUIの例で言えば分かるだろ。

テキストボックスはコンクリートクラスであるが、
汎用的に使われるパーツだ。

抽象クラスと汎用的つ使えるクラスをごっちゃにするなよ。

300 ：nobodyさん：2009/01/31(土) 17:40:29 ID:???

>>299
君の汎用的ってのは、１つのロジックを複数のサイトで使えるってことね。了解

301 ：nobodyさん：2009/01/31(土) 17:42:09 ID:???

ちょっと、みなさん、クールダウンしません？発散しすぎ

302 ：nobodyさん：2009/01/31(土) 17:42:45 ID:???

>>300
いや常識（笑）

汎用的なパーツは、一つのパーツを複数のサイトで使える物。

それ以外の意味なんて無いだろｗ

まさか今まで抽象クラスの話をしていたのか。驚きだｗ

303 ：nobodyさん：2009/01/31(土) 17:48:13 ID:???

やっぱおかしいと思ったんだよ。なんかずれてるって。

この質問をしたのは正しかった。　↓

> 282 ：nobodyさん：2009/01/31(土) 16:52:07 ID:???
> それのどこが汎用的なんだよ。個別実装べったりじゃん。
> 日本語の蘊蓄はいらないから、汎用的にするためのインターフェースでも示してくれ。
>
> 283 ：nobodyさん：2009/01/31(土) 17:04:17 ID:???
> >>282
> お前にとって汎用的とはどういうことを指す言葉なんだ？
>
> 例を出して説明したまえ。

この質問の時点で抽象クラスのことって言ってくれれば話は早かったんだが。

ちゃんと質問に答えてくれていれば
この時点で、君の汎用的ってのは抽象クラスのことね（笑）で終わっていた。

304 ：nobodyさん：2009/01/31(土) 17:53:26 ID:???

クールダウンして>>185,188の質問に戻ろうか？ｗ

> フレームワークのSSL対応ってどうなっているのでしょうか？

305 ：nobodyさん：2009/01/31(土) 17:53:36 ID:???

>>302
>>303 熱いねぇ

>>280は汎用的なクラスと書いてるなぁ。
>>281は個別実装でも別サイトで利用できたら汎用的なんだってさ。
汎用的なクラスといったら、抽象クラスに限定するわけじゃないが、
少なくともコンクリートのことじゃないと思うが、まぁ個人的な見解だからいいや。

それにしても、>>302は汎用的な"パーツ"って言い換えて苦しそうだねぇ。

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

さすが、こういうレベルの人の頭の中は面白い。

306 ：nobodyさん：2009/01/31(土) 17:55:15 ID:???

>>303

>>284でFAだが？

307 ：nobodyさん：2009/01/31(土) 17:55:39 ID:???

> 汎用的なクラスといったら、抽象クラスに限定するわけじゃないが、
> 少なくともコンクリートのことじゃないと思うが

それは無いｗ

308 ：nobodyさん：2009/01/31(土) 17:57:54 ID:???

>>305
> それにしても、>>302は汎用的な"パーツ"って言い換えて苦しそうだねぇ。

別に、分かりやすく言い換えただけで
汎用的なクラスという言い方でもいいが？

309 ：nobodyさん：2009/01/31(土) 17:59:46 ID:???

以　下　、「　汎　用　的　」　禁　止。

こんないい加減な言葉で喧嘩するなｗみっともない。

310 ：nobodyさん：2009/01/31(土) 18:02:05 ID:???

クールダウンして>>185,188の質問に戻ろうか？ｗ

> フレームワークのSSL対応ってどうなっているのでしょうか？

311 ：nobodyさん：2009/01/31(土) 18:06:32 ID:???

>>302
> いや常識（笑）
> 汎用的なクラスは、一つのクラスを複数のサイトで使える物。
> それ以外の意味なんて無いだろｗ

先生！複数のサイトで使えないクラスの方がめずらしいと思うんですが？

312 ：nobodyさん：2009/01/31(土) 18:07:49 ID:???

> 先生！複数のサイトで使えないクラスの方がめずらしいと思うんですが？

複数のサイトで使えないクラス。
それがビジネスロジックを記述したクラス

313 ：nobodyさん：2009/01/31(土) 18:39:23 ID:???

じゃ、>>281のロジックはどこのサイトでも使いようがないので、
>>302の定義でも汎用的ではないってことで落ち着きそうですね

314 ：nobodyさん：2009/01/31(土) 19:12:22 ID:???

基幹業務系の処理なんて再利用できるほうが珍しいｗ

315 ：nobodyさん：2009/01/31(土) 20:17:12 ID:???

>>313
そうか？
手法に致命的な欠陥がない限り多分そのまま普通に使えるし、使ったなりのシステムになると思うんだが。
ただ単に、>>313(とか>>282？)がそのやり方を使いたくないだけではないかとちょっと思った。

316 ：nobodyさん：2009/01/31(土) 20:31:55 ID:???

え、欠陥見えない？

317 ：nobodyさん：2009/01/31(土) 20:46:34 ID:???

>>316
リダイレクトがちょっと引っかかるがそこは適当な処理に読み替えるとして、
致命的な欠陥があるなら指摘してみたらいいじゃない。正直煽りうざい

318 ：nobodyさん：2009/01/31(土) 21:02:59 ID:???

致命的とは思わん、が、ショップじゃ使えないな。売り上げが落ちる。
煽り？どこが。

319 ：nobodyさん：2009/01/31(土) 21:03:44 ID:???

だから、使えないというのなら、その理由を指摘してみたらいいじゃない。

320 ：nobodyさん：2009/01/31(土) 21:05:32 ID:???

売上が落ちるから、でわからんの？

321 ：nobodyさん：2009/01/31(土) 21:06:31 ID:???

2段階ログインはありがちな処理だし、使いまわせないとは思わないな。
まあ、好みの問題はあるだろうが。
俺なら設定依存じゃなくてコントローラから明示的に呼び出す方式にするかな。
フレームワークにもよるだろうし、どっちの方法も一長一短だけど。

322 ：nobodyさん：2009/01/31(土) 21:06:54 ID:???

分かるわけ無いだろｗ
どういう理由で売り上げが落ちるんだよｗ

323 ：nobodyさん：2009/01/31(土) 21:07:36 ID:???

>>318
最初からそう書けば誰も煽りとは思わんよ
ああ、なんか違う話をしてる人がいるなーって思うだけでｗ

324 ：nobodyさん：2009/01/31(土) 21:08:19 ID:???

インフラと絡むが、セッション固定攻撃は可能だし

325 ：nobodyさん：2009/01/31(土) 21:08:37 ID:???

>>323
自演？

326 ：nobodyさん：2009/01/31(土) 21:10:24 ID:???

2段階もなにも、ログインを強要してる段階で売上減だな

327 ：nobodyさん：2009/01/31(土) 21:10:39 ID:???

>>324
じゃあ改良してセッション固定攻撃を防ぐようなコードにすれば
問題ないって話？

328 ：nobodyさん：2009/01/31(土) 21:12:42 ID:???

>>326
えっ？それだけの話？
それならログインを強要するかしないかの
オプションをつければ解決する話じゃない。

329 ：nobodyさん：2009/01/31(土) 21:13:06 ID:???

>>327
自分のサイトは防ぐようにしてますが何か？
今は、>>281のクラス？の問題だろ

330 ：nobodyさん：2009/01/31(土) 21:13:38 ID:???

>>328
ログインを強要しないで、>>281はセキュアにできるのかね？

331 ：nobodyさん：2009/01/31(土) 21:15:55 ID:???

ログインしなくてもセキュアに処理できなきゃ、この手のスクリプトは無意味だよな。

332 ：nobodyさん：2009/01/31(土) 21:18:24 ID:???

上のほうでは、一行でできるからフレームワークに入れるほどでもないと
いっているやつがいるかと思えば、話がすすんでみれば
結局、いろんなことを考えないといけないってことになってしまったな。

だからフレームワークに入れておいて簡単に使えるようにするべきだというのに。

333 ：nobodyさん：2009/01/31(土) 21:24:59 ID:???

ワラタ。
「汎用的なカレー調理器具を考案しました」って言ってる奴に
「それじゃボルシチには使えないから汎用的じゃねえよ」
「うちは蕎麦屋だから関係ねえよ」って言ってるようなもんだな。

334 ：nobodyさん：2009/01/31(土) 21:25:37 ID:???

>>281 がまあミスリーディングというか

> 全てのコントローラのアクション実行前に、セキュアにするべきか一覧に入っているか調べる。
> セキュアページにhttpでアクセスしていたら、httpsにリダイレクト

ここと、

> セキュアトークンを持っていなければ、ログインページにリダイレクト
> ログインが許可されればセキュアトークンをセット（secure属性を負荷したクッキーを発行）し元のページに戻す。
> ログインページはデフォで用意するがカスタマイズ可能。要するにscaffold（土台）

これは別の処理
で、どちらも実は元の流れの、セキュアセッションと非セキュアセッションの持ち方について、
直接は関係ないじゃないかｗ
どう発展させるつもりだったんだろうと気にはなるが

335 ：nobodyさん：2009/01/31(土) 21:28:00 ID:???

>>330
ようは、ゲスト会員の話をしているんだろ？
あんなの新規会員をその場で作成するのと同じことだよ。

336 ：nobodyさん：2009/01/31(土) 21:31:24 ID:???

>>333
挙句の果てに、
「それカレー調理器具じゃねーか。そんなの汎用的とはいえない。
いろんな調理器具をはめ込める規格を作れ。」

といっているやつまでいるから手に負えないｗ

337 ：nobodyさん：2009/01/31(土) 21:33:17 ID:???

汎用的な調理器具は鍋だろ

338 ：nobodyさん：2009/01/31(土) 21:34:26 ID:???

中華鍋だな

339 ：nobodyさん：2009/01/31(土) 21:36:42 ID:???

>>335
すばらしく重いサイトができそうですね

340 ：nobodyさん：2009/01/31(土) 21:37:11 ID:???

>>337-338
コンクリートクラスはだめだって誰かが言ってたｗ

341 ：nobodyさん：2009/01/31(土) 21:38:09 ID:???

>>339
それの解決策を君は思いつけたかな？

342 ：nobodyさん：2009/01/31(土) 21:38:55 ID:???

それはコンクリート批判の方が当りだと思うぞ

343 ：nobodyさん：2009/01/31(土) 21:39:20 ID:???

>>341
普通に実装してますが何か？

344 ：nobodyさん：2009/01/31(土) 21:40:03 ID:???

じゃあ問題ないじゃんｗ

345 ：nobodyさん：2009/01/31(土) 21:40:36 ID:???

おれにとっちゃ問題ない。
しかし、>>281は使えないよって話

346 ：nobodyさん：2009/01/31(土) 21:41:25 ID:???

じゃあ使えるようになおせばいいだけの話。

文句はいらない。改善したコードを示せ。

347 ：nobodyさん：2009/01/31(土) 21:41:57 ID:???

ぶｗ

348 ：nobodyさん：2009/01/31(土) 21:42:10 ID:???

なくなｗ

349 ：nobodyさん：2009/01/31(土) 21:43:24 ID:???

結局具体的な理由をちゃんと説明できないから
煽りだっていわれるんだよね。自業自得。

350 ：nobodyさん：2009/01/31(土) 21:44:50 ID:???

>>185があぁいう質問の仕方じゃなくて素直に質問してたら書いたかもな。

351 ：nobodyさん：2009/01/31(土) 21:45:21 ID:???

どうせ書いてないくせにｗ

352 ：nobodyさん：2009/01/31(土) 21:46:39 ID:???

いいや書いてたね

353 ：nobodyさん：2009/01/31(土) 21:47:05 ID:???

うそだなｗ

354 ：nobodyさん：2009/01/31(土) 21:47:22 ID:???

まじ書いてたって。

355 ：nobodyさん：2009/01/31(土) 21:47:50 ID:???

証拠は？

356 ：nobodyさん：2009/01/31(土) 21:48:28 ID:???

>>185にしても>>262にしても単なる教えて君だよな。
ロジックを知っててフレームワークでの解決状況を聞きたいんならまだしも。
ロジックを知らない奴がフレームワークに依存しようってのがみえみえ

ちなみに、>>266を書いたのは俺。
おまいさんは、>>281でそれをぱくっただけ。

まだ、煽って情報引き出そうってか。
つらの皮厚いのう

357 ：nobodyさん：2009/01/31(土) 21:49:08 ID:???

いいから証拠は

358 ：nobodyさん：2009/01/31(土) 21:50:05 ID:???

357 ：nobodyさん：2009/01/31(土) 21:49:08 ID:???
いいから証拠は

359 ：nobodyさん：2009/01/31(土) 21:50:14 ID:???

> ちなみに、>>266を書いたのは俺。

つまり、そもそも>>266に問題があるということか。

360 ：nobodyさん：2009/01/31(土) 21:50:46 ID:???

スレ読み直してみろよ。答え含んでるから

361 ：nobodyさん：2009/01/31(土) 21:51:05 ID:???

自分で読み返してそこの部分を引用しろ。

362 ：nobodyさん：2009/01/31(土) 21:52:14 ID:???

>>359
そうだよ。そういうサイトもありだが、それは一例にすぎない。
つまり、セキュアサイトの扱いはビジネスロジックそのものなんだよ。
セキュアサイトの扱いが数パターンって誰かが書いてたが、
数パターンなんてもんじゃない。それを知ってかいてるかどうかの違い

363 ：nobodyさん：2009/01/31(土) 21:52:18 ID:???

スレ伸びすぎワロタ

364 ：nobodyさん：2009/01/31(土) 21:52:54 ID:???

>>361
断る

365 ：nobodyさん：2009/01/31(土) 21:53:13 ID:???

>>362
つまり、ありなんだろ？

366 ：nobodyさん：2009/01/31(土) 21:53:34 ID:???

>>364
それ俺のせりふｗ

367 ：nobodyさん：2009/01/31(土) 21:53:43 ID:???

>>365
ありだ。しかし、極めて限定的なサイトの特殊ロジック

368 ：nobodyさん：2009/01/31(土) 21:54:18 ID:???

極めて限定的なサイトの特殊ロジックだがありだ。

このように書いてくれんか？ｗ

369 ：nobodyさん：2009/01/31(土) 21:55:19 ID:???

汎用的なクラスを求められて、特殊ロジックを埋め込む奴に言われたないわ

370 ：nobodyさん：2009/01/31(土) 21:55:26 ID:???

じゃあ、一般的なロジックを披露してほしいものだね。

それがビジネスロジックであろうがぜんぜんかまわないから。

371 ：nobodyさん：2009/01/31(土) 21:56:45 ID:???

断る

教えてほしいなら態度をわきまえんとな。
いまさら、取り返しはつかんが

372 ：nobodyさん：2009/01/31(土) 21:57:07 ID:???

結局いえないｗ

373 ：nobodyさん：2009/01/31(土) 21:57:30 ID:???

>>371
ごめんなさい謝りますから教えてください。

374 ：nobodyさん：2009/01/31(土) 22:01:21 ID:???

> じゃあ、一般的なロジックを披露してほしいものだね。

もう一回説明しとく。
だれでもハッピーな一般的なロジックなんてものはない。
ビジネスロジックそのものだから。

375 ：nobodyさん：2009/01/31(土) 22:01:47 ID:???

だから、ビジネスロジックでかまわないって書いたろｗ

376 ：nobodyさん：2009/01/31(土) 22:04:24 ID:???

たとえば、Yahoo!
複数のクッキーとフォームへの埋め込みを利用し、非ログインのユーザーであっても、
その経過を追跡できるように組んである。
ちなみに、PHPのソースではなく、Apache用のモジュールを独自開発して関数一つで使えるようになっている。

377 ：nobodyさん：2009/01/31(土) 22:05:54 ID:???

これをYAHOOパターンと名づけよう。

378 ：nobodyさん：2009/01/31(土) 22:07:36 ID:???

このYAHOOパターンは使いまわしできるものか？
それともYAHOOでしか使えないものなのか？

379 ：nobodyさん：2009/01/31(土) 22:07:41 ID:???

＞PHPのソースではなく、Apache用のモジュールを独自開発して関数一つで使えるようになっている
これがYahooのフレームワークですね

380 ：nobodyさん：2009/01/31(土) 22:08:52 ID:???

なんだ。結局Yahooのフレームワークに組み込まれているのかよ。
ぜんぜんビジネスロジックじゃないじゃん。

381 ：nobodyさん：2009/01/31(土) 22:09:02 ID:???

フレームワークとは呼ばん
Yahooでしか使えん

382 ：nobodyさん：2009/01/31(土) 22:09:37 ID:???

> Yahooでしか使えん
なんで？

383 ：nobodyさん：2009/01/31(土) 22:10:03 ID:???

ヤフーのユーザー認証インフラとべったりくっついてるから

384 ：nobodyさん：2009/01/31(土) 22:10:05 ID:???

>>381
>>378

385 ：nobodyさん：2009/01/31(土) 22:11:03 ID:???

>>383
じゃあ、ユーザー認証インフラごと、ほかで使いまわしできないのか？

386 ：nobodyさん：2009/01/31(土) 22:12:01 ID:???

その屁理屈が言いたいだけなら、スルーさせてもらう。

387 ：nobodyさん：2009/01/31(土) 22:12:21 ID:???

屁理屈と感じるのはなぜ？

388 ：nobodyさん：2009/01/31(土) 22:13:33 ID:???

インフラはPHPじゃない。スレチ

389 ：nobodyさん：2009/01/31(土) 22:14:45 ID:???

フレームワークかどうかの話にPHPが関係あるのか？

390 ：nobodyさん：2009/01/31(土) 22:15:04 ID:???

スレタイ

391 ：nobodyさん：2009/01/31(土) 22:15:27 ID:???

>>376 は、Yahooのシステムの詳細はもしかすると知っていても、抽象化という概念はあんまり
知らないのかもしれない
PHPで再現不可、その為現実的には流用は困難、そういう回答ならわからんでも無いんだが。
真偽はともかくとして

392 ：nobodyさん：2009/01/31(土) 22:16:03 ID:???

>>390
それこそ屁理屈だな。じゃあ最初っからPHPで実装されていないフレームワークの例を持ってくるなっつーの。

393 ：nobodyさん：2009/01/31(土) 22:16:36 ID:???

フレームワークの例なんて要求されてないだろ

394 ：nobodyさん：2009/01/31(土) 22:17:41 ID:???

>>393
ええと、Yahooパターンがビジネスロジックか、
それとも他で使い回しができるものかって話でしたっけ？

395 ：nobodyさん：2009/01/31(土) 22:18:39 ID:???

373 ：nobodyさん：2009/01/31(土) 21:57:30 ID:???
>>371
ごめんなさい謝りますから教えてください。

374 ：nobodyさん：2009/01/31(土) 22:01:21 ID:???
> じゃあ、一般的なロジックを披露してほしいものだね。

もう一回説明しとく。
だれでもハッピーな一般的なロジックなんてものはない。
ビジネスロジックそのものだから。

396 ：nobodyさん：2009/01/31(土) 22:18:59 ID:???

だから、ビジネスロジックでいいから説明しろってｗ

397 ：nobodyさん：2009/01/31(土) 22:19:29 ID:???

各会社で実装が異なるのが当然、その例を示したまで

398 ：nobodyさん：2009/01/31(土) 22:19:58 ID:???

各会社で・・・ってじゃあ、会社内では使いまわししているってことかよｗ

399 ：nobodyさん：2009/01/31(土) 22:20:08 ID:???

>>396
>>376

400 ：nobodyさん：2009/01/31(土) 22:20:28 ID:???

>>395
＞ビジネスロジックそのものだから。
一応言っておくと、その意見も別にここでまだそれほどの同意を得ている訳ではないし、
あんたも論証していない。ただ単に主張しているだけ。

401 ：nobodyさん：2009/01/31(土) 22:21:21 ID:???

>>399
それは具体的な話じゃない。セッションにクッキーを利用しているとかいう程度の簡単な概略。

402 ：nobodyさん：2009/01/31(土) 22:21:56 ID:???

やっぱり、こういうレベルの人は煽りのクオリティも(ry

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

403 ：nobodyさん：2009/01/31(土) 22:22:50 ID:???

なぁ。結局会社内では使い回ししている
フレームワークなんだろ？
いい加減認めろよ。

404 ：nobodyさん：2009/01/31(土) 22:24:13 ID:???

関数ひとつで一連の処理ができるようになっている以上
フレームワーク以外の何者でもないと思うんだがねぇ。

405 ：nobodyさん：2009/01/31(土) 22:24:21 ID:???

Yahooではそれをフレームワークとは呼んでない。
それでも、おまえさんがフレームワークだと呼びたいなら呼べよ。

406 ：nobodyさん：2009/01/31(土) 22:25:37 ID:???

フレームワークじゃなくてビジネスロジックとでも呼んでいるのか？

関数一行なのにビジネスロジック？

407 ：nobodyさん：2009/01/31(土) 22:27:01 ID:???

関数と呼んでいる
関数でビジネスロジックを実現してますが？

408 ：nobodyさん：2009/01/31(土) 22:27:41 ID:???

で、そういう関数の集まりをライブラリと呼んでいる。
フレームワークとは呼ばない

409 ：nobodyさん：2009/01/31(土) 22:28:08 ID:???

>>407
だからそれは他のサイト、システムには＊絶対に＊使い回せないのかと聞かれてるんじゃないか。
どんだけループしたいんだｗｗｗ

410 ：nobodyさん：2009/01/31(土) 22:28:24 ID:???

>>407
Apacheのモジュールとして実装された
関数の中身をビジネスロジックと呼んでいるのか？

411 ：nobodyさん：2009/01/31(土) 22:29:43 ID:???

>>408
ライブラリって普通使いませるものだよね？
ビジネスロジックとは呼ばないよね？

412 ：nobodyさん：2009/01/31(土) 22:29:54 ID:???

>>409
「絶対に」ってのが屁理屈だと言っている。
現実的には無理だ。

>>410
関数でビジネスロジックを実装している。

413 ：nobodyさん：2009/01/31(土) 22:31:11 ID:???

> 関数でビジネスロジックを実装している。

どっちの意味だ？

(Apacheモジュールとして実装された）関数を使ってビジネスロジックを実装しているのか
それとも関数の中身がビジネスロジックなのか。

414 ：nobodyさん：2009/01/31(土) 22:32:03 ID:???

>>411
ライブラリにビジネスロジックを実装することはある。

415 ：nobodyさん：2009/01/31(土) 22:32:13 ID:???

チャットすんなよ
ゆとり共

416 ：nobodyさん：2009/01/31(土) 22:32:50 ID:???

>>414
そんな可能性の話すんなよ。屁理屈じゃねーかｗ

この場合はどうなのかって話だ。

417 ：nobodyさん：2009/01/31(土) 22:33:36 ID:???

>>416
可能性じゃない。Yahooの場合はそうしているという話

おまえさん、壊れてきたね

418 ：nobodyさん：2009/01/31(土) 22:33:40 ID:???

>>415
誰が困るってわけでもねーだろｗ

419 ：nobodyさん：2009/01/31(土) 22:34:48 ID:???

>>417
つまり、Yahooの場合は、会社内で
ビジネスロジックであるライブラリを
使い回ししているということでいいんだよな？

420 ：nobodyさん：2009/01/31(土) 22:35:03 ID:???

>>415

すまん、ちょっとおもしろかったんで。もうやめるわ。飽きたし。
そこの
> SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
のひと、
さぁ、勝利宣言どうぞ！
↓↓

421 ：nobodyさん：2009/01/31(土) 22:35:41 ID:???

断る

422 ：nobodyさん：2009/01/31(土) 22:38:04 ID:???

使い回しできるってことは、Yahooにとっては
一般的なロジックってことになるんだけどね。

いろいろいっている事が矛盾しだしてるｗ

423 ：nobodyさん：2009/01/31(土) 22:40:33 ID:???

フレームワークじゃなくてライブラリだというが、
最近のフレームワークにはライブラリ相当のものが含まれているのが普通。

424 ：nobodyさん：2009/01/31(土) 22:42:02 ID:???

やっと頭がおかしいやつが消えたか？

425 ：nobodyさん：2009/01/31(土) 22:43:38 ID:???

おれは元の質問者ではないが、改めて。

> SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。

至極単純に実装した場合、これは真だと思うんだが、どうなんでしょう。
また、これを避けるために例えば>>236の様な対策が施され、実装されているのは、（割合的に）
一般的なんでしょうかね。

（そうだとすると、自分の（会社の）作っているシステムがかなり後進的ry）

426 ：nobodyさん：2009/01/31(土) 22:58:58 ID:???

ライブラリとフレームワークの違いは、「フレームワークとは何か？」って論争になりそうで触れたくねーけどな。
大雑把に言えば、SmartyとかPEARみたいに、特定の機能を提供するのがライブラリで、
アプリケーション全体の構造（MVC構造とか）を提供するのがフレームワーク。

フレームワークには複数のライブラリが含まれる事が多いけどな。
テンプレートライブラリとか、O/RマッパーみたいなDB中間層とか。

二重ログインを提供するだけならば、それは単なるライブラリ。
フレームワークの一部として組み込むと便利そうだ、というだけでな。

427 ：nobodyさん：2009/01/31(土) 23:00:50 ID:???

>>426
餌をやらないでください

428 ：nobodyさん：2009/01/31(土) 23:05:05 ID:???

>>426
んなもん、Yahooパターンか、それ以外かを
入れ替え可能な仕組みになっていれば
その程度でフレームワークになる。

そのフレームワークに沿ったつくりの
Yahooパターンクラスはなんになるんだろうな？
フレームワーク？プラグイン？

429 ：426：2009/02/01(日) 00:54:30 ID:???

>428
前半は意味が不明なので読み飛ばす。

そいつが存在しないとフレームワークが動かないならば、フレームワークの一部。
存在しなくとも動くならプラグイン。

430 ：nobodyさん：2009/02/01(日) 00:58:57 ID:???

正確にはフレームワーク標準のプラグイン

431 ：nobodyさん：2009/02/01(日) 00:59:12 ID:???

継続ベースのPiece Frameworkなら、HTTPとHTTPSのスキーム切替えは簡単なんじゃないでしょうか？

http://trac.piece-framework.com/piece-unity/ticket/137
フローIDによって別のフローに接続するビュースキーム
例えば、フローID /foo のフローにクエリ変数bar, bazをともなって接続するには下記のようにする。
flow:///foo.php?bar=baz&baz=qux
SSLで接続したい場合は、下記のようにする。
flows:///foo.php?bar=baz&baz=qux

たったこれだけでSSLにパッと切り替わるんですよね？

432 ：nobodyさん：2009/02/01(日) 01:04:47 ID:???

http://trac.piece-framework.com/piece-flow/wiki/ja/Start
Piece_Flowによって、実行中のフローの状態はHTTPリクエストをまたがって保持され、フローの状態遷移の順序は完全にコントロールされます。
このことは状態の保持を前提としてプログラムを書くことを可能にします。
さらに、Piece_Flowは不正リクエストやCSRF攻撃、セッション固定化攻撃から自動的にアプリケーションを保護します。

Piece Frameworkは使うときにやたらと設定ファイルをガシガシ書かなきゃいけないみたいだったので使おうと思ってなかったんですけど、
そういう仕込み作業って、Javaのフレームワークを使っている人にとっては、そんなに苦行じゃないですか？

433 ：nobodyさん：2009/02/01(日) 11:34:03 ID:???

>>431-432
なんか面白そうだけど、Piece使ったことないや
ドキュメントだけでも読んでみようと思ったが・・・無いじゃないかｗ

聞き慣れない概念や用語をがしがし取り込むのはいいけど、その説明をしないでは
多分理解しにくいしちょっと手が出せない感じ
ソース頑張って読んだらわかってくるのかもしれないけど。
Piece_Flowの最後のstableが去年の夏で、半年間もドキュメント整備しないとか
どうなんだろう。
実際に使ってる人ほとんどいないんじゃなかろうか。

434 ：nobodyさん：2009/02/01(日) 16:33:19 ID:???

>>433
Piece_Flowは単体でも使えるように設計されているけど、
普通はPiece_Unityを使うから存在を意識することはほとんどないよ。
フロー定義はPiece_IDEを使って作ると楽。

435 ：nobodyさん：2009/02/01(日) 17:11:42 ID:???

一時期、PHPプロ（アシアル）さんが押してたみたいですが、最近あまり話題を聞かない…
ドキュメントの誤字脱字チェックぐらいなら協力できると思います！！！
ピースの中の人、頑張ってください＾＾

http://trac.piece-framework.com/piece-doc/wiki/ja/Start
Piece Frameworkドキュメント

http://gihyo.jp/dev/serial/01/piece
連載　Piece Frameworkによるブログアプリケーションの作成

http://www.amazon.co.jp/gp/product/4844326368
Piece Frameworkで作る対話的なアプリケーション

436 ：nobodyさん：2009/02/01(日) 17:14:39 ID:???

　　　　　　　　　　　　　_,,..r'''""~~`''ｰ-.､
　　　　　　　　　　　 ,,.r,:-‐'''"""~~`ヽ､:;:;:＼
　　　　　　　　　　 r"r　　　　　　　　　ゝ､:;:ヽ
　　 r‐-､　　 ,...,,　|;;;;|　　　　　　　,,.-‐-:､ヾ;:;ゝ
　　 :i!　 i!　　|: : i! ヾ| r'"~~` :;:　::;",,-‐‐-　 `r'^!
　　　 !　 i!. 　|　 ;|　l| 　''"~~　　　､　　　　　　i' |
　　　 i!　ヽ　|　　|　|　　　 ,.:'"　　　､ヽ､　　　!,ﾉ　イェ～イ
　　　　ゝ　 `-! 　:|　i!　　.:;:　'~~ｰ~~'"　ﾞヾ　: : ::|　　ピースの中の人、
　　 r'"~`ヾ、　　　i!　i!　　 ,,-ｪェI二エﾌﾌ　: : :::ﾉ~|`　　頑張ってください＾＾
　　,.ゝ､　　r'""`ヽ､i!　`:､　　ー　-　'"　:: : :／ ,/
　　!､　 `ヽ､ー､　　ヽ‐''"`ヾ､.....,,,,＿,,,,.-‐'",..-'"
　　 | ＼ i:" ）　　　　 |　　　~`'''ー----''"~
　　　ヽ　`'"　　　　ノ

437 ：nobodyさん：2009/02/01(日) 17:26:04 ID:???

今連載記事飛ばし読み中
ピースフローは、ZFと組み合わせて使えるらしい。

http://gihyo.jp/dev/serial/01/piece/0002?page=2
Piece_Flowは汎用のフレームワークであり，他のフレームワークと容易に統合することが可能です
Zend Frameworkと統合したRevulo_Controller_Dispatcher_Flowがあります。

http://www.revulo.com/ZendFramework/Component/Piece_Flow.html
Piece_Flow を Zend Framework に組み込み、 Piece Framework と同様のステートフルなプログラミングができるようにします。

　　　　　　　　　　　　　,.,.,.,.,.,.,.,.,__
　　　　　　　　　　　,,;f::::::::::::::::::::::ヽ
　　　　　　　　　　　i::/'￣￣￣ヾi::l
　　　　　　　　　　　|::|　／　　＼,|::|
　　　　　　　　　　　|r-（・ );（・ )-|
　　　　　　　　　　　(　ヽ :::(__)..:: 　}　　＜・・・で、SSLは簡単になるの？
　　　　 ,＿＿__／ヽ　 -==-　/
　　　　 r'"ヽ　　 t､　　ヽ＿＿_/
　　　　/ ､､i　　　ヽ＿＿,,/
　　　 /　ヽﾉ　　j　,　　　j　|ヽ
　　　 |⌒`'､__ /　/　　　/r　 |
　　　 {　　　　￣''ｰ-､,,_,ﾍ＾　|
　　　　ゝ-,,,＿＿＿＿_）--､j
　　　 /　　＼__　　　　　　/

438 ：nobodyさん：2009/02/01(日) 17:32:07 ID:???

HTTPとHTTPSのスキーム切替えの対応方法を
>>1のテンプレFWのユーザーの皆様がご紹介ください！！！
トップバッターはシンフォニーでお願いします＞＜

↓↓↓

439 ：nobodyさん：2009/02/01(日) 17:47:35 ID:???

ピース連載記事、チラ見でYAMLの嵐…
頭が痛くなりそうだけど、IDEを使えばサクサク書けるのでしょうか？>>434

http://gihyo.jp/dev/serial/01/piece/0009?page=4
Piece_IDEのフローデザイナーはGUIベースのフロー定義を可能にします。
フローデザイナーを使うと複雑なフローでも混乱することなく開発を進められると思います。

http://trac.piece-framework.com/piece-ide/wiki/ja/Start
Piece_IDEは、Eclipse上に構築されたPiece Frameworkの統合開発環境です。

440 ：nobodyさん：2009/02/01(日) 17:59:41 ID:???

Gauche＋Kahuaで、ステートフルなWebアプリ作成を練習してみると、Piece Frameworkの利便性が分かるでしょうか？
http://www.thinkit.co.jp/article/74/1/
http://pc11.2ch.net/test/read.cgi/tech/1231856193

http://txqz.net/blog/2008/02/13/1626
httpプロトコルはステートレス。
COOKIEとかGETパラメータとかPOSTパラメータとか他のヘッダとかを使って擬似的にステートフルにできている。
ステートレスだけで処理しようとすると問題が起こる。
[入力]→[確認]→[完了]と画面が推移するとき、ユーザが入力した情報をhiddenパラメータなどでクライアントに返してしまうと、確認の前と完了の前とで2回データチェックする必要が出てくる。
HTTPプロトコルがステートレスなのにアプリがステートフルを要求している。
いまさらHTTPプロトコルは変えようがない。
そこのギャップをフレームワークがうまく解決してくれる。

HTTPの仕組みの上でWEBアプリを作るのは、PHPだけの悩みじゃないんですよね～＞＜

441 ：nobodyさん：2009/02/01(日) 18:01:34 ID:???

http://gihyo.jp/dev/serial/01/piece/0010
現時点でステートフルな特性を持つフレームワークは少数派です。
それでも，筆者はステートフルな特性がWebアプリケーション開発において重要な価値があると考えています。
そして，Piece Frameworkはまだまだ進化の過程にあります。
アプリケーション開発の中心をより本質的な部分にシフトさせるべく，Piece Frameworkの開発は続きます。
Piece Frameworkの今後の発展にご期待ください。

ここまで読んで頂いた皆様に感謝いたします。
ありがとうございました。

442 ：nobodyさん：2009/02/01(日) 18:03:26 ID:???

土日の勉強タイム終わり
ピース試す時間なかったorz

443 ：nobodyさん：2009/02/01(日) 18:10:30 ID:???

オツカレ。
あとはブログにでも書いてくれ

444 ：nobodyさん：2009/02/02(月) 00:32:10 ID:???

そうだよな
ステートレスなHTTPプロトコルを、フレームワークがステートフルにしてくれれば誰がWEBアプリを作ってもセキュアになる

445 ：nobodyさん：2009/02/02(月) 01:58:28 ID:???

しかし自演し放題のスレだとくだらない煽り合い始まると
一部の馬鹿がオナニー覚えた猿みたいに自演連投し出して始末に終えないなｗ

446 ：nobodyさん：2009/02/02(月) 02:10:06 ID:???

>>445
自覚しろよ。

447 ：nobodyさん：2009/02/02(月) 03:52:14 ID:???

それセッション変数で（ｒｙ

ステートフルに作らないといけない処理は、webサービスのごく一部だしなぁ。
そのためにフレームワークいっこ覚える気にはならん。
大体そういう場所ってセキュリティ的にも大事な場所だから、曖昧な理解で他所のコード使うわけにもいかんし。

448 ：nobodyさん：2009/02/02(月) 07:12:40 ID:???

>>>444
ステートフルになったら、誰が作ってもセキュアになるってセンス、ありえねぇ

449 ：nobodyさん：2009/02/02(月) 10:36:18 ID:???

誰が作ってもセキュア…これはデジタル土方の間で流行る予感（・∀・）
フレームワークで無理ならもっと下のレイヤーで改善したら確実ですよね？
＝HTTP/HTTPSに代わる新しいセキュアなプロトコルを作ればいいんじゃないか？
でも、面倒くさし金にならんから誰もやらんか…俺はやる気以前の問題として知識がないから無理ｗ

450 ：nobodyさん：2009/02/02(月) 10:44:14 ID:???

IDSに依存する開発者とか、バカすぎるだろ。あれと一緒。

451 ：nobodyさん：2009/02/02(月) 10:46:29 ID:???

PCの場合、ユーザーを特定する方法って複雑そうですね＾＾
携帯電話は、端末IDを使えばユーザーの特定が安全＆楽でしょうか？

452 ：nobodyさん：2009/02/02(月) 11:01:12 ID:???

>>451
携帯の端末IDって設定で許可していないと取れなかったような気がするが、
今はどうなってるの？

453 ：nobodyさん：2009/02/02(月) 13:51:06 ID:xbZu7ZNv

ところで、ステートフルとスレートレスの違いって何？
PieceFrameworkの利点って何？教えてえらい人。

>>452
機種によって違うけど、アクセスするたびに許可を求めてくる物がほとんどだと思う。

454 ：nobodyさん：2009/02/02(月) 14:27:46 ID:???

>>453

> ステートフルとスレートレスの違いって何？
ttp://pc11.2ch.net/test/read.cgi/php/1227303362/

> PieceFrameworkの利点って何？
ttp://piece-framework.com/ja/index.html

自分でもう少し掘り下げてから質問したらどうよ

455 ：nobodyさん：2009/02/02(月) 15:00:08 ID:???

http://www.ruby-lang.org/ja/news/2009/01/30/ruby-1-9-1-released/

Ruby1.9安定版が出ていよいよPHP脂肪カウントダウン開始ｗｗｗ

456 ：nobodyさん：2009/02/02(月) 15:04:12 ID:???

>>453
クッキーやIPアドレスに比べ、より直接的に個人特定・追跡できそうな情報なんだが、
前提にしているサイトって多いのかな？あんまり騒ぎにならないな
これって、その機体の契約の間ずっと不変なんでしょ？

457 ：nobodyさん：2009/02/02(月) 15:08:42 ID:???

騒ぎになってるよ

458 ：nobodyさん：2009/02/02(月) 15:48:00 ID:???

>>455
奇数バージョンは実験的なバージョンだよ
Linuxのカーネルと同じ

459 ：nobodyさん：2009/02/02(月) 16:08:03 ID:???

待て、Rubyはどうかしらんが、Linuxカーネルに
今は偶数か奇数かで安定版と開発版の区別はないぞ。

Rubyも偶数奇数でわかれてたっけ?
そのへんは、おおらかにやってそうなふいんきだけど...

460 ：nobodyさん：2009/02/02(月) 17:14:57 ID:???

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/25881

461 ：nobodyさん：2009/02/02(月) 17:22:35 ID:???

なぜ本家リファレンスマニュアルを参照しない。

ttp://www.ruby-lang.org/ja/man/html/_C1C8A4DFB9FEA4DFC4EABFF4.html#RUBY_VERSION

> Ruby のバージョンは、 major.minor.teeny という形式です
>
> version 1.8 までは、minor が奇数のバージョンは開発版、 minor
> が偶数のバージョンは安定版です。1.9.0 以降は、 teeny が 0
> のバージョンが開発版となる予定です。

なので1.9.1は安定版でよかろう。つかwww.ruby-lang.orgにそう書いてある。
しかし、それが本当に安定しているかどうかは別の問題だが。

462 ：nobodyさん：2009/02/02(月) 17:31:17 ID:???

Rubyは文法が涙目だから駄目だろ
elsifだけは勘弁してくれよ

463 ：nobodyさん：2009/02/02(月) 18:12:53 ID:???

>>462
じゃぁPerlと（略）とTT.pmの組み合わせにしなさい。

464 ：nobodyさん：2009/02/02(月) 18:24:05 ID:???

>>462
そのキーワードの何がそんなに気に入らないのかわからん。
PHPのarray_**は気に入らんが、それだけで文法が駄目とか思わんし。

465 ：nobodyさん：2009/02/02(月) 18:28:15 ID:???

elsifとかelifとか慣れの問題だろ。柔軟に適応できないやつはマに向いてないぞ。
あれこれ難癖つけて1つの言語にこだわって結局自滅するんだ。

466 ：nobodyさん：2009/02/02(月) 19:08:34 ID:???

禿堂

467 ：nobodyさん：2009/02/02(月) 19:14:01 ID:???

インターネットって危険がイッパイなんですね！＞＜
大事な用件は直接会って話そう！

468 ：nobodyさん：2009/02/02(月) 19:58:48 ID:???

}
else
if () {
}

って書けなくて気持ち悪いからだろ
CやJava書いてる奴はそういう奴多い

469 ：nobodyさん：2009/02/02(月) 20:18:47 ID:???

case～when があるから elsif なんかめったに使わないし

470 ：nobodyさん：2009/02/02(月) 20:44:56 ID:???

>>468
そんなこだわりをもったまま他の言語を使おうと思う方がおかしくないか？
まるで世界中英語で押し通す英米人のようだ

471 ：nobodyさん：2009/02/02(月) 20:48:12 ID:???

ハワイで日本語が通じないって怒ってる日本人だろ

472 ：nobodyさん：2009/02/02(月) 20:53:14 ID:???

>>470
いやだからPHPフレームワークのスレにいるんだろこの人は
なんでそこでRubyやる覚悟を説く必要あるんだ

473 ：nobodyさん：2009/02/02(月) 20:57:03 ID:???

C＝イギリス
Java＝アメリカ
PHP＝オーストラリア
だとして、
イギリス系やアメリカ系のオーストラリア人同士が、
フランス語って英語と文法違ってめんどいよねー
でもオーストラリアは英語だからいいよねーって話してたら、
急にフランス人が来てその意味解らん、そんなんでフランス語が
できるようになるわけないだろ、って言われてるようなもんだな。

474 ：nobodyさん：2009/02/02(月) 21:17:26 ID:???

適応力があるかないかの差でしょ
言語として使う必要がくれば使うことに別段抵抗はないなぁ
重要なのは何を使うかじゃなくて何を作るかだしなー

まぁRubyは当面必要になるような場面が全然思い当たらないし
勉強する気もないけどさー

つか、好き好き語るならPHPFWの好き嫌いを語ったほうがよさそうだｗ

475 ：nobodyさん：2009/02/02(月) 21:17:34 ID:???

オーストラリア馬鹿にすんな!!!

476 ：nobodyさん：2009/02/02(月) 21:28:22 ID:???

本当に馬鹿にされてるのはおフランス

てゆーか一番問題なのは定期的に多言語界隈に沸く
Ruby信者の低脳な釣り餌に全力で食いつく雑魚どもだとおもうけどなｗｗ

477 ：nobodyさん：2009/02/02(月) 22:00:19 ID:???

今回のエサはRubyアンチが撒いてるんじゃないか
どっちでも食いつきがいいんだけどなこのスレは

いつものこととはいえ、お前らほんとはPHP嫌いで使ってるだろｗ

478 ：nobodyさん：2009/02/02(月) 22:02:28 ID:???

古女房みたいなもんだ
ミテクレはいまいちでも、いつでもやれるし、あそこのフィット感がいい。

479 ：nobodyさん：2009/02/02(月) 22:33:33 ID:???

>>478
確かに。しかも安く済む。

480 ：nobodyさん：2009/02/03(火) 01:40:22 ID:???

俺たちデジタル土方は、既製品を使う立場。
既製品が気に入らないなら、自分で好きなようにプログラミング言語を作ればいい。
でもプログラミング言語を開発する手間に比べたら、既製品を使う方がずっと手軽だ。
既製品を使う必然性は、すぐ使えるという利便性にある。
既製品とはいえ、ある程度の選択肢は用意されている。
PHPが気に入らないのなら、Perl、Python、Ruby、Java…他の既製品を使ってみればいいじゃないか？
ここで上から目線で語って「俺はスゴイ！」という気分に浸れるのか？
ちっぽけなプライドなんて何の役にも立たないぜ？
PHPのフレームワークで、WEBアプリをいかに速くセキュアで簡潔に作れるか？
その恩恵を享受できないとしたら、このスレに来ても時間の無駄だろう。
みんなでスキルアップしまくって、日本の開発スピードを世界最速レベルに引き上げようぜ！！！

http://q.hatena.ne.jp/1203288623
>どのような価値ある情報を日本語で蓄積するかが大切なはずです。

…以上、デジタル土方の主張でした＾＾

481 ：nobodyさん：2009/02/03(火) 06:50:56 ID:???

キモッ

482 ：nobodyさん：2009/02/03(火) 07:15:56 ID:???

別にデジタル土方じゃねーし

483 ：nobodyさん：2009/02/03(火) 10:07:10 ID:???

>>468
だから適応能力のない人は食ってけませんよっと。

484 ：nobodyさん：2009/02/03(火) 11:05:42 ID:???

>>480
言ってることは至極まともっぽいんだが、2chでアジ演説ってのはネタだなあ

485 ：nobodyさん：2009/02/03(火) 11:23:06 ID:???

>>468
> }
> else
> if () {
> }
>
> って書けなくて気持ち悪いからだろ

俺は素直に} elseif () { って書くのでぱっと思いつかないが、
if と else がある言語でそういう書き方が出来ない言語ってあるのか？

486 ：nobodyさん：2009/02/03(火) 11:26:26 ID:???

else
if () {
}
だとifとの差別化ができなくね？

487 ：nobodyさん：2009/02/03(火) 11:45:16 ID:???

>>485
いや、だからRubyではelse ifとは書けないから云々ってずっと話をしてたんだけどなぁ...
つか蒸し返すなよ。

488 ：nobodyさん：2009/02/03(火) 12:03:09 ID:???

>>487
どこのスレ来て言ってるんだよ。PHPもelse ifはできないだろうが。

489 ：nobodyさん：2009/02/03(火) 12:05:07 ID:???

まさかPHP5は可能といかいうオチ？

490 ：nobodyさん：2009/02/03(火) 12:09:31 ID:???

>>488-489
PHPでもできるよ。

491 ：nobodyさん：2009/02/03(火) 12:21:15 ID:???

>>490
ほんとだ。PHPでもできた。ｽﾏｿ。

492 ：nobodyさん：2009/02/03(火) 12:36:42 ID:???

マジレスすると、Rubyの実行速度がPHPを上回ったら、Rubyはシェアを取れると思う。
PHPで出来ることは、Rubyでも出来るからね。

Rubyの改善には期待してます。
ただし、続きはRubyスレでお願いします＞＜

493 ：nobodyさん：2009/02/03(火) 12:46:22 ID:U0x1Z73i

それは夢のまた夢

494 ：nobodyさん：2009/02/03(火) 12:48:03 ID:???

＞ただし、続きはRubyスレでお願いします＞＜
って言いながら香ばしい餌垂らしていくんじゃねえｗ

495 ：nobodyさん：2009/02/03(火) 12:51:48 ID:???

ＰＨＰは実行時に余計な処理せずに最小処理だけして爆速にできるオプション選べるように
すればもっとシェア広がると思う。
普通使わない変数への初期値セットとか設定ファイルいちいち呼んだり余計なステップが多すぎ

<?php set_quickmode(); みたいに書いてさ・・

496 ：nobodyさん：2009/02/03(火) 13:07:20 ID:???

速くしたいだけなら、VM作ってコンパイル・最適化済みのバイトコードを、
メモリにのっけておいて実行するようにすればいいんじゃない？
大体今風に作られたスクリプトではrequireあたりも大きなボトルネックっぽいし

ただ動作速度を速くしたってこれ以上シェアが広がるとも思えんけどな
すでに棲み分けって点では十分できてるだろ

497 ：nobodyさん：2009/02/03(火) 13:43:31 ID:???

Javaにコンパイルできるぞ

498 ：nobodyさん：2009/02/03(火) 14:31:04 ID:???

JRubyでJavaとして使う
これがRubyの生きる道？

499 ：nobodyさん：2009/02/03(火) 14:34:25 ID:???

まあ、PHP以外も普通に使えるようにしとこうぜ！って話だな

500 ：nobodyさん：2009/02/03(火) 15:28:08 ID:???

パフォーマンスの面ではPHPも人のこと言えないからなぁ
高負荷サイトだと今でも、調査の結果mod_perlにしましたみたいなことあるし

501 ：nobodyさん：2009/02/03(火) 15:45:39 ID:???

っていうかフリーのＦＷって、全部実行時コンパイルじゃないの？
ＦＷの意味半減だと思うんだが。

502 ：nobodyさん：2009/02/03(火) 15:52:23 ID:???

実行時コンパイルかどうかはフレームワークの問題じゃなくて実行環境の問題な気がするが
コンパイルが通るかどうかは別として他のフレームワークでつくってZendに食わせてもいいんだし

503 ：nobodyさん：2009/02/03(火) 16:00:32 ID:???

自分の知る限りではPHPだとアプリケーションサーバとして動作する
（メジャーな、実績のある）フレームワークは存在しないし、
mod_phpもmod_{perl,python,ruby}のような常駐型として作られていないので
リクエストごとにインタプリタが動きます。

ただ、それとフレームワークのメリットとは全くもって関係ないです。
Webアプリケーションフレームワークは生産性・保守性の向上のためのもの。
コンパイルのコスト軽減にはAPCやeAccelerator等を使うのが一般的。

504 ：nobodyさん：2009/02/03(火) 16:05:48 ID:???

超有名な
ttp://www.zend.co.jp/product/zendplatform.html
これは、ダメですか。そうですか。すごいですね。

505 ：nobodyさん：2009/02/03(火) 16:09:14 ID:???

>>503
アプリケーションサーバーかつフレームワークな実装もPHP以外なら存在するのはたしかだけど
それが一緒に提供されるメリットは感じないな。
その話とインタプリタの話がどうしてつながるのかわからないんだけど？

506 ：nobodyさん：2009/02/03(火) 16:11:52 ID:???

本当ですね。Zend Platformがフレームワークだったとは寡聞にして知りませんでした。

507 ：nobodyさん：2009/02/03(火) 16:13:50 ID:???

>>506
フレームワークなんて言ってないよ。（フレームワークとしての機能もあるけど）
PHPソースをコンパイルした状態で保持して実行するよって話

508 ：nobodyさん：2009/02/03(火) 16:16:37 ID:???

>>507
失礼。前半じゃなくて後半へのレスでしたか。

509 ：nobodyさん：2009/02/03(火) 16:19:30 ID:???

>>508
どうでもいいや。わけわかんねぇ

510 ：nobodyさん：2009/02/03(火) 17:44:52 ID:???

Zend使えばJavaみたいにVMの上で動いてるのと同じような感じなるわけだが、
それじゃ不満なんだろうか。
もちろんZendFrameworkじゃないフレームワークでも問題ないし。

511 ：nobodyさん：2009/02/03(火) 17:50:27 ID:???

>>510
Zendって省略しないで。それは会社名でしょ。
Zend PlatformでもVM上で動いているのと同じになるわけじゃないでしょ

512 ：nobodyさん：2009/02/03(火) 17:50:50 ID:???

>>510
金かかるんじゃねーの？

513 ：nobodyさん：2009/02/03(火) 17:58:28 ID:???

金かかるよ。それで？

514 ：nobodyさん：2009/02/03(火) 18:06:03 ID:???

最近の顧客はWebアプリケーションは無料と思ってるところ多いから、
その手のを請求したらケチつけてくるよ。ライセンスがどうなってるのか
しらねーけど。

515 ：nobodyさん：2009/02/03(火) 18:09:42 ID:???

Ａ「ＰＨＰで金が掛かるなんて聞いたことがないね」
Ｂ「フレームワークを使うからなんです。フレームワークを使えば
コードの保守・管理が楽になり色々とメリットが・・・」
Ａ「なるほど。あんたらが楽するためにこっちが金出せと？」

516 ：nobodyさん：2009/02/03(火) 18:13:29 ID:???

>>510のはフレームワークじゃなくてサーバじゃないの？
今はなきColdFusionみたいな

517 ：nobodyさん：2009/02/03(火) 18:14:36 ID:???

>Zend PlatformでもVM上で動いているのと同じになるわけじゃないでしょ

なるよ

518 ：nobodyさん：2009/02/03(火) 18:17:03 ID:???

>>516
ColdFusionはまだAdobeからFlexと併売されてなかったっけ?
ていうかColdFusionやFlexこそがフレームワーク込みのサーバ製品だよね。

519 ：nobodyさん：2009/02/03(火) 18:29:22 ID:???

Flexはともかく、ColdFusionをフレームワークというのは、
PHPそれ自体がフレームワークだ！っていう程度の意味しかないような。

520 ：nobodyさん：2009/02/03(火) 18:33:49 ID:???

PHPもアクセラレータ使ったら充分速いよ
だいたいYahooがPHPで動いてるんだから99％のサイトはPHPでおk

521 ：nobodyさん：2009/02/03(火) 18:40:07 ID:???

>>517
そのVMって、どういう意味？

522 ：nobodyさん：2009/02/03(火) 18:41:32 ID:???

>>514
Webアプリが無料って・・・もしかして、それホームページ？

523 ：nobodyさん：2009/02/03(火) 21:24:57 ID:???

>>520
PHPで大規模なサイトも作れますね！スゴイ（・∀・）
ちなみに私のホームページは、なんと！１日１００アクセスぐらいです＞＜

サーバが１台で済むような小規模サイトなら>>503の対策で十分ですよねー？＾＾
>APCやeAccelerator等を使うのが一般的

524 ：nobodyさん：2009/02/03(火) 21:35:53 ID:???

http://www.atmarkit.co.jp/news/200809/11/ruby.html
Rubyが遅い理由
遅いのにはいくつか理由がある。
1つは変数に静的型がなく、コンパイル時に型が決まらないことから最適化が効きづらいこと。
しかし、これは動的言語共通だ。
ほかにRubyが遅い理由として前田氏はRubyには「関数がなく、すべてメソッドであること」があるという。
ただ、Rubyは次期開発バージョンのRuby1.9系ではインタープリタをまるごと差し替え、バイトコードを処理するVM を採用したことで多くの最適化を実施し、大幅に高速化しているという。

Pythonも3.0になったことだし、PHPの包囲網は強力だぞ！！！
Perl6.0は(ry

525 ：nobodyさん：2009/02/03(火) 21:40:37 ID:???

>>517
VM＝ヴァーチャルマシンのこと。
Javaの仕組みで使われて有名だよ。
http://d.hatena.ne.jp/keyword/VM

526 ：nobodyさん：2009/02/03(火) 23:47:25 ID:???

>>520
Yahoo!JapanはあんまりPHPで動いてないぞえ
知恵袋とかはそうだけど昔からある部分はCかJavaだお

527 ：nobodyさん：2009/02/03(火) 23:49:55 ID:???

Zend EngineがJavaのVMっぽいってこういうことだな
http://journal.mycom.co.jp/special/2004/php5/004.html

528 ：nobodyさん：2009/02/03(火) 23:57:32 ID:???

そ、それ2000年の記事ですけど、PHP5でもそうなの？

529 ：nobodyさん：2009/02/04(水) 00:10:47 ID:???

いったんバイトコードにコンパイルしてからVMで実行するのはPHP4でも5でも6でも同じ。
PythonやRuby 1.9でも大ざっぱに言うと同様の仕組みになってる。
あとはVM(エグセキュータ)に手を入れてia32/amd64だけでもJITコンパイラが搭載されるとおもしろいのだけど。

530 ：nobodyさん：2009/02/04(水) 00:16:08 ID:???

勉強になりました。

531 ：nobodyさん：2009/02/04(水) 00:17:17 ID:???

>>528
どうでもいいけど俺には2004年に見える

532 ：nobodyさん：2009/02/04(水) 00:18:04 ID:???

>>528
どうでもいいけど俺にはPHP5の記事に見える

533 ：nobodyさん：2009/02/04(水) 00:37:31 ID:???

>>527 >>529
普段意識してなかったけど、PHPってそうなってたんだ！
参考になりました。

534 ：nobodyさん：2009/02/04(水) 00:46:03 ID:???

PHPフレームワークの本が揃い、使いやすい状況にある。
ダントツ１位がないのは、それぞれ一長一短だからだろうか？
各FWのユーザーから、「この実装は、このFWではこうやっているよ。メリットはこれこれ。」という報告をよろしく！
FW同士、切磋琢磨していいとこ取りをしよう！

他のLL言語のメリット・デメリットはこちらもどうぞ
http://pc11.2ch.net/test/read.cgi/tech/1215319832
【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】

535 ：nobodyさん：2009/02/04(水) 00:57:47 ID:???

>>534
× こちらもどうぞ
○ こちらでどうぞ

でいいだろｗ

536 ：nobodyさん：2009/02/04(水) 01:07:12 ID:???

mod_phpが常駐しないことのメリットは、なんと言ってもデプロイが簡単なことだな。単にファイルを差し替えるだけでいいんだから。
そして、これで十分なスピードがある。
スクリプト言語の処理速度の差なんて、ウェブに限って言えばどうでもいいレベル。速度差はDB部分にかかってるわけで。

537 ：nobodyさん：2009/02/04(水) 01:20:31 ID:???

いやそんなことない。
DB部分は殆どキャッシュされてるがアクセスの多いページ、例えばサイトトップとか。

538 ：nobodyさん：2009/02/04(水) 01:22:05 ID:???

重箱の隅をつつくようで悪いけど、mod_phpそのものは常駐してますやん。
バイトコードやシンボルテーブルはリクエストの度に初期化・実行・破棄されるけど。
あとは同意。

539 ：nobodyさん：2009/02/04(水) 01:22:45 ID:???

はてなとかmixiくらいになるとその差が重要になってきて
だからわざわざめんどいmod_perl使ってるんだろ

540 ：nobodyさん：2009/02/04(水) 01:27:58 ID:???

>>537
そういうのはコンテンツキャッシュでどうとでもなる。

mixiは知らんけど、はてなの場合は中の人がPerlを使える・Perlを使いたい、
かといってCGIは遅すぎるのが理由な希ガス。

541 ：nobodyさん：2009/02/04(水) 01:28:55 ID:???

mod_perlとは懐かしい響きだ
それは確かに面倒くさそうだ。てか、未だにメンテされてるの？

542 ：nobodyさん：2009/02/04(水) 05:45:22 ID:???

常駐するから速いとも一概に言えないじゃん
Rubyなんて常駐させても遅いよ

543 ：nobodyさん：2009/02/04(水) 11:41:49 ID:cqQgvAqQ

YahooはRubyだお

544 ：nobodyさん：2009/02/04(水) 11:53:43 ID:???

RubyもいいけどPHPもね
ttp://searchblog.yahoo.co.jp/2007/09/php_at_yahoo_japan.html

545 ：nobodyさん：2009/02/04(水) 13:04:10 ID:???

世紀末Web土方伝説～LLの拳～
例えるなら、
Python（グーグル）…ラオウ
Ruby（楽天）…トキ
PHP（Yahoo）…ケンシロウ
Perl（はてな）…ジャギ
というポジションでしょうか？（・∀・）

546 ：nobodyさん：2009/02/04(水) 13:07:17 ID:???

Perlは（現状ではなく）役割的にはリュウケンのような気もするが

547 ：nobodyさん：2009/02/04(水) 15:41:16 ID:???

わかりやすく芸人に例えてくれ

548 ：nobodyさん：2009/02/04(水) 15:51:12 ID:???

楽天はRuby殆ど使ってないぞ
99%がPHPとJava
研究してるけど全く表に出てこないｗ

549 ：nobodyさん：2009/02/04(水) 16:13:35 ID:???

わかりやすく実写版ドラゴンボールに例えてくれ

550 ：nobodyさん：2009/02/04(水) 16:18:51 ID:???

よけいわかりにくいわｗ

551 ：nobodyさん：2009/02/04(水) 16:20:06 ID:???

>>545
Rubyはトキだと思ってたらアミバだったぜ！みたいな感じか？
PHPがケンシロウってのはｗバットかアインくらいで妥協しておけ

ECMAScript群はきっと南斗聖拳

552 ：nobodyさん：2009/02/04(水) 16:57:49 ID:???

Googleも実はPythonあんまり使ってないんだよなｗ
サービスの殆どはCとJavaで、Pythonはヘルプ機能とか軽いところしか使われてない。

553 ：nobodyさん：2009/02/04(水) 17:28:36 ID:???

Rubyはフリーザって感じだな。
出た当初は桁外れに強くて
今でも強いイメージがあるんだけど、
実はそんなでも無い？

PHPはクリリン？あまり強いわけじゃないが
登場回数は多い。でもよくよく考えると地球人最強？

えーと、クリリンって最後の方ではフリーザより強くなったんだっけ？

554 ：nobodyさん：2009/02/04(水) 17:36:40 ID:???

ドラゴンボール戦闘力の軌跡なんてのがあるんだなｗ
フリーザ弱っ。天津飯つえー。

http://schiphol.2ch.net/test/read.cgi/retro/1208239286/676
フリーザ；1億2000万
ヤムチャ：3億5000万
クリリン：12億6500万
天津飯：60億4500万
公式戦闘力（｢ドラゴンボール戦闘力の軌跡｣集英社より)

555 ：nobodyさん：2009/02/04(水) 17:37:36 ID:???

うん。やけくそなインフレがよくわかる

で、ここはいったい何のスレなんだｗｗｗ

556 ：nobodyさん：2009/02/04(水) 17:41:26 ID:???

ポタラ・フュージョン公式によると、もっとすごいよ。
ttp://www.geocities.jp/poposu01/katari153.html

557 ：nobodyさん：2009/02/04(水) 17:48:28 ID:???

ヤムチャなめんなよおまいら

558 ：nobodyさん：2009/02/04(水) 18:00:45 ID:???

http://www.youtube.com/watch?v=2kCo5-7sys4&hl=ja

559 ：nobodyさん：2009/02/04(水) 23:39:35 ID:???

新しい言語どんどんできたけど
結局今でもC、Java、Perl、PHPって感じだよね

560 ：nobodyさん：2009/02/04(水) 23:45:32 ID:???

ＣとPerlとはすごいよな
JavaとPHPはウェブありきで作られた面もあるからすごくて当然だけど

561 ：nobodyさん：2009/02/05(木) 01:18:17 ID:???

糞言語ばっかりだな

562 ：nobodyさん：2009/02/05(木) 01:57:20 ID:???

JavaがWebに使われるようになったの結構後だぞ
J2EEとか最初無かったから

563 ：nobodyさん：2009/02/05(木) 09:11:17 ID:???

>>562
HotJava......

564 ：nobodyさん：2009/02/05(木) 13:50:05 ID:???

Applet...

565 ：nobodyさん：2009/02/05(木) 18:46:36 ID:???

>>562
昔を知らないんだね。Appletとかちょっと書けると結構金になったもんだぞ。

566 ：nobodyさん：2009/02/05(木) 22:25:45 ID:???

>>563
糞久しぶりに聞いたｗ

567 ：nobodyさん：2009/02/05(木) 23:19:28 ID:???

C、Java、Perl、PHPの話してるんだからAppletとかそう言う問題じゃないだろうに
Flashとかとの比較になるだろそういうのは
もともとJavaはWebでApplet作るために設計された言語じゃないって事でしょ

568 ：nobodyさん：2009/02/05(木) 23:27:54 ID:???

もっともなんだが、それ以前にずーっとスレ違(ry

569 ：nobodyさん：2009/02/06(金) 20:36:37 ID:???

Javaって元々はHOTJava系で
売ろうとしてたんでしょ？

570 ：nobodyさん：2009/02/06(金) 20:55:40 ID:???

Javaはもともとは組込用のC++の代替言語として開発された
そのうちにモザイクが発表されてこれは凄いって事になって
これからはWebだなってことでHotJavaもセットになって発表された

571 ：nobodyさん：2009/02/07(土) 08:38:14 ID:???

Javaのホワイトペーパー第一版には、言語としての素晴らしさと、
中間ファイル出すから何でも動くぜーっていうのが中心として
書かれてたと思う。HotJavaはちょっと後じゃなかったっけ？

572 ：nobodyさん：2009/02/07(土) 09:15:33 ID:???

てかJavaがweb前提ってどっから出てきた発想なんだろ

573 ：nobodyさん：2009/02/07(土) 10:10:14 ID:???

>>572
どっかの勘違い君じゃない？

例のホワイトペーパーはそんなこと１つも書いてないよ。
ホワイトペーパーってのはリリース前に出すやつね。

574 ：nobodyさん：2009/02/10(火) 00:39:54 ID:???

んっとにフレームワークの話題ってないのなｗ
とりあえず、おまいらHTML5についてどう思うよ。しょうもない言語論争してるより、切実な問題じゃないか？

俺は個人的には、フォームのクライアントヴァリデート機能に期待してるんだ。
Ajaxうんちゃらかんちゃらの工数がちょっとでも省けるんなら大歓迎したい。

575 ：nobodyさん：2009/02/10(火) 05:46:16 ID:???

解説サイトの受け売りそのままですね

576 ：nobodyさん：2009/02/10(火) 08:54:16 ID:???

受け売りというか、それ以上にありがたいというか影響の大きい新機軸なんてあったかな？

577 ：nobodyさん：2009/02/10(火) 13:37:16 ID:???

>>574
クライアントヴァリデートってオマケだろ？
本当に値が正かはサーバーで見なきゃいけない。
工数省けるってのはクライアントヴァリデートのだよね？
結局サーバーサイドのヴァリデーションは面倒なままだ。
PEARで何かあるんかも知れんが。

578 ：nobodyさん：2009/02/10(火) 21:19:58 ID:???

かったりーのでクライアントヴァリデートなしで済ませる僕ってダメなやつですか？

579 ：nobodyさん：2009/02/11(水) 00:37:33 ID:???

>577
HTMLを食わせると、それと同じ基準でバリデートしてくれるライブラリが出るだろ、きっと。
最悪でも自前で実装すれば、HTML5でサイトを作っている限りは使いまわせる。

580 ：nobodyさん：2009/02/11(水) 07:55:43 ID:???

>>578
別にいいんじゃない？
>>579
楽観的だなあ。ヴァリデートの難しさは分かってるよね？
Softbankの携帯電話のみ、とか、VISAのカードでチェックデジットが
間違ってない、とか複雑なのあるし。callbackにすりゃいいんだろうけど。
あと導線というか実装がみんなまちまちなので汎用的ライブラリを作るのは
結構大変だと思われ。現存のフォームヴァリデータの実装を見てみるといい。
ケチをつけたくなるものがほとんどだ。

581 ：nobodyさん：2009/02/11(水) 08:04:54 ID:???

むしろ逆かな
サーバアプリ側のヴァリデート設定をもとにフォームのHTMLを吐き出すライブラリができる感じ？
どのみちサーバ側でのヴァリデートはしなきゃいけないんだから。
ユーザ側の入力を少しでもしやすくする部分で手が抜けるっていうのがメリットだと思う。

582 ：nobodyさん：2009/02/11(水) 13:18:02 ID:???

>581
>サーバアプリ側のヴァリデート設定をもとにフォームのHTMLを吐き出すライブラリができる
これ、結構色んなフレームワークで既に実装されているんだが。

583 ：nobodyさん：2009/02/11(水) 15:56:29 ID:???

どっちにしても下位互換しなきゃいけないんだから
作業が減るのは相当後の話だろ

584 ：nobodyさん：2009/02/11(水) 17:48:23 ID:???

クライアントヴァリデートなんてかなりどうでもいいな
そんなに付加価値ないだろ

585 ：nobodyさん：2009/02/11(水) 20:09:31 ID:???

なんでお前らヴァリヴァリ言ってんの？

586 ：nobodyさん：2009/02/12(木) 23:00:20 ID:ANumrANN

ヴァーリトゥードゥ

587 ：nobodyさん：2009/02/12(木) 23:04:11 ID:???

ヴァリヴァリヴァリヴァリヴァリタンク♪

588 ：nobodyさん：2009/02/13(金) 20:51:25 ID:???

そこはバリバリ伝説だろと小一時間(ry

589 ：nobodyさん：2009/02/13(金) 21:29:28 ID:???

cakePHPって簡単にAjax組み込める？
それともIDとか勝手に振られちゃいますか？

590 ：nobodyさん：2009/02/13(金) 21:56:00 ID:???

簡単に組み込めそうなことすらマニュアル見て試せない奴が
簡単に組み込めるとも思えないが

591 ：nobodyさん：2009/02/13(金) 23:32:42 ID:???

unixtimeが1234567890になった瞬間にPHP脂肪ｗｗｗ

592 ：nobodyさん：2009/02/14(土) 17:06:27 ID:???

ちょっとしたポータルサイトをPHPでつくろうと思っていますが、どのFWを使おうか迷っています。よかったら誰か決めてください。それにしますので。

593 ：nobodyさん：2009/02/14(土) 17:07:54 ID:???

PRADOにしてください

594 ：nobodyさん：2009/02/14(土) 17:12:31 ID:???

Zend

595 ：nobodyさん：2009/02/14(土) 17:15:31 ID:???

>>593
>>594
ありがとう。メインはPRADOにします。Zendをモジュールでつかってみます。

596 ：nobodyさん：2009/02/14(土) 17:36:41 ID:???

ちょｗ

597 ：nobodyさん：2009/02/14(土) 19:37:42 ID:???

安価でサイト作るぜ！みたいなノリだなｗ

598 ：nobodyさん：2009/02/15(日) 02:20:01 ID:???

>>597
http://baresoku.blog94.fc2.com/blog-entry-261.html
http://imakitasangyou.web.fc2.com/index.html

599 ：nobodyさん：2009/02/19(木) 16:30:08 ID:???

これってもう話題になった？
http://www.pluf.org/

600 ：nobodyさん：2009/02/19(木) 17:24:43 ID:???

>>599
へー、こんなフレームワークがあるんだー。

Pluf に一致する日本語のページ約 710 件
まだあんまり知られていないようですね＞＜

ttp://d.hatena.ne.jp/mopemope/20090210/p1
>というか、PHPのときはrhacoでいいじゃんというのがある…

rachoはDjangoが流行る前からあったみたいですが？
ttp://project-p.jp/halt/kinowiki.php/Django%E5%8B%89%E5%BC%B7%E4%BC%9A/Disc3

601 ：nobodyさん：2009/02/20(金) 19:06:39 ID:???

フレームワークを使用して新規にECサイトを構築する場合、
管理側、ユーザ側それぞれにフレームワークを入れたほうがよいのかな。
それともフレームワークは一つで作成した方がよいのかな。
みなさんどうしてます？

602 ：nobodyさん：2009/02/20(金) 19:10:32 ID:???

同じフレームワークでもいいが、ニーズが１８０度近く違うこともあるので、
同じでもいいし違ってもいい

603 ：nobodyさん：2009/02/20(金) 19:42:20 ID:???

大抵データアクセス用のモデルクラスを作成するかと思うので、それらを使い回す為には
同じフレームワークの方がいい場合も多いかと。というか普通はそうだと思う。

それでどーーーーーーーーしても駄目な場合、もう一つフレームワーク使う・・・かなあ？

604 ：nobodyさん：2009/02/20(金) 19:45:06 ID:???

フロントZend
管理Cake
はよくやる

605 ：nobodyさん：2009/02/20(金) 19:49:56 ID:???

>>604
管理画面はscaffoldでがんがん行くってこと？
フロントに使わないのはなぜ？使いにくいの？
cake使ったこと無いからわかんね

606 ：nobodyさん：2009/02/20(金) 20:01:45 ID:???

フロントは携帯対応とかあるからCakeだと逆にめんどい

607 ：nobodyさん：2009/02/23(月) 11:17:23 ID:???

俺は>>603に同意だな。DBスキーマが二個あるのはトラブルの元だし。
scaffoldで済む程度の管理画面なら分けてもいいかもだけど。

608 ：nobodyさん：2009/02/23(月) 18:58:21 ID:???

レプリケーションしてて片方が読み専用、もう片方が書き専用なんてのは良くあるよ
だからFWも複数スキーマ対応してないと採用されづらい

609 ：nobodyさん：2009/02/24(火) 02:11:29 ID:???

>>608
複数スキーマってどういう意味？
レプリケーションなら、同一スキーマでいいんじゃね？
複数データベースという意味ならcakeは
複数のデータベースに接続できるね。

610 ：nobodyさん：2009/02/24(火) 07:42:17 ID:???

スキーマの意味を理解していないのではないかと。

611 ：nobodyさん：2009/02/24(火) 08:47:42 ID:???

今はCakeが一番流行ってるんですか？

612 ：nobodyさん：2009/02/24(火) 08:58:35 ID:???

>>609
同一スキーマにレプリケーションして意味あるのかｗ

613 ：nobodyさん：2009/02/24(火) 13:20:18 ID:???

みんなが言ってるスキーマの定義がバラバラなんじゃないか？

614 ：nobodyさん：2009/02/24(火) 14:37:17 ID:???

((lambda (x) (x x)) (lambda (x) (x x)))

615 ：nobodyさん：2009/02/24(火) 23:50:17 ID:???

log(message,leve,facility)
って感じに呼んで、
facilityによって別々のログ（ファイルやコンソール）に書き込むような
ログ機能があるFWってありますか？

616 ：nobodyさん：2009/02/25(水) 00:38:34 ID:???

>>613
どんな定義であろうと、流石にレプリケーションを同一スキーマにって奴はおらんのでは。
マシンですら別にしないと意味ないのに。

617 ：nobodyさん：2009/02/25(水) 01:05:34 ID:???

てか、
「同一スキーマにレプリケーション」とか「レプリケーションを同一スキーマに」
って、表現おかしいぞ。レプリケーションの意味わかってるのか？

618 ：nobodyさん：2009/02/25(水) 01:10:39 ID:???

とりあえずあれだ
レプリケーション（負荷分散）とか、適当に自分が念頭に置いてる訳語つけて喋れおまいら

619 ：nobodyさん：2009/02/25(水) 01:10:40 ID:???

スキーマって、DDLまたはそれの元になるデータのことを言ってるんじゃないのかな。

たとえ別サーバーであっても、同じDBMSをのっけているのなら、同じスキーマでも問題ない様に思える。

異DBMS間で、レプリケーション（マイグレーション？）するのなら、定義が変更される可能性があるので、DBMSごとにスキーマを微調整する必要はあるかもしれないけど。

>>616の反応を見てると、DSN、ユーザー名、パスワードといった接続情報も含めて、これをスキーマっていっているような気がする。

620 ：nobodyさん：2009/02/25(水) 01:14:07 ID:???

>>617
おかしいから、そんなのありえないって言ってるんじゃないのか

621 ：nobodyさん：2009/02/25(水) 01:16:52 ID:???

>>619
トンチンカンだなお前は

622 ：nobodyさん：2009/02/25(水) 01:18:48 ID:???

スキーマの定義は多分Oracleやってる奴とそうじゃないやつで違う。

623 ：nobodyさん：2009/02/25(水) 01:24:24 ID:???

Oracleではデータの集合自体をスキーマという
逆に言語(DDLも含む)で言うスキーマってのは定義の事だから、
同じ定義で複数作っても同じスキーマということになる

ってことでかみ合ってないんじゃないかと思う

624 ：nobodyさん：2009/02/25(水) 01:25:19 ID:???

俺がスキーマっつったらだいたいイコールCREATE TABLEの中身
俺がレプリケーションっつったらDBの複製

625 ：nobodyさん：2009/02/25(水) 01:33:04 ID:???

同一スキーマもなにも、そもそもレプリケーションにスキーマ関係ねーだろ

626 ：nobodyさん：2009/02/25(水) 01:39:56 ID:???

いやOracleには関係あるんだよそれが
だから話がかみ合ってないんだよ

627 ：nobodyさん：2009/02/25(水) 01:45:21 ID:???

いやoracleでも関係ねーし

628 ：nobodyさん：2009/02/25(水) 01:46:36 ID:???

オラコーはユーザ毎にそれぞれのスキーマとかあるからな
いろいろ他のDBと概念が違ってめんどい

629 ：nobodyさん：2009/02/25(水) 01:47:15 ID:???

ここの大多数の奴はMySQLしか知らない奴なんだから
Oracleの話はいったんやめてみよう

630 ：615：2009/02/25(水) 02:01:33 ID:???

スキーマとかどうでもいいので俺の質問に答えて下さい

631 ：nobodyさん：2009/02/25(水) 02:16:57 ID:???

第二引数の意味が解らないので答えられません

632 ：nobodyさん：2009/02/25(水) 02:17:38 ID:???

ってかFWじゃなくてlog4phpでいいんじゃないのかと思うんだが

633 ：nobodyさん：2009/02/25(水) 03:11:59 ID:???

オラクルでしか使えない用語は
使わないでください。

オラクル用語のスキーマは間違いすぎです。

634 ：nobodyさん：2009/02/25(水) 03:13:40 ID:???

オラクルでは間違いじゃないんだから完全否定もできんけどな。

635 ：nobodyさん：2009/02/25(水) 03:22:06 ID:???

Postgresqlにもスキーマあるぞ。

636 ：nobodyさん：2009/02/25(水) 03:39:07 ID:???

>>630
cakephpはエラーレベルによって吐くファイル名が変わるけど
任意の場所にログを吐くFWはないんじゃね？

637 ：nobodyさん：2009/02/25(水) 03:39:40 ID:???

Zend_Log

638 ：nobodyさん：2009/02/25(水) 03:50:40 ID:???

なんだこの流れ
発端は>>607-608か？
素直に読んだら>>607の「スキーマ」は大体>>624の意味だろ
オラクル使いは自分の使ってる言葉が絶対かｗ

「レプリケーション」にしたって、オラクルの流儀なんてしらね。SQLを適当に発行したら
分散機構及びDBMS側でうまくやってくれる、それでいいじゃねえか。
なんでフレームワークわけてまでこっち側で対応しなきゃならないんだ。貧乏くさいぞ。

639 ：nobodyさん：2009/02/25(水) 06:25:05 ID:???

ま、ウェブ系だとポスグレやMySQLが当たり前だけど、クラスによってはオラクルが当たり前な場合もあるからな。フリーのDBに慣れてると、オラクルはホント戸惑うよな。limitがないとか。

640 ：nobodyさん：2009/02/25(水) 10:04:36 ID:???

言われてみれば、MySQLしか使ってないな～（遠い目）
MySQLは安いし、ノウハウも蓄積、公開されてるし、他のDBでないとダメな理由や状況が今のところ無いです、ハイ＾＾

>>639
Accessもlimitがなくてあせりました＞＜

641 ：nobodyさん：2009/02/25(水) 11:19:57 ID:???

オラクル一回使ったけどCentOSに入れるのに一週間掛かったなー。何あのCD-ROMの枚数とパッチセットの数。
普通にインストールしても丸一日かかるんじゃないか？
融通が利かず、コマンドラインインターフェイスが最悪だった記憶しかないです。

642 ：nobodyさん：2009/02/25(水) 13:04:42 ID:???

mysql4まではOracleの方がいいと思ったこともあったな。

643 ：nobodyさん：2009/02/25(水) 13:21:02 ID:???

PHPとOracleって時点で激しくミスマッチ感があるんだが
Linux版って安定してるの？

644 ：nobodyさん：2009/02/25(水) 13:23:01 ID:???

db2とかoci8のモジュールメンテナはIBMやOracleの人だったはず

645 ：nobodyさん：2009/02/25(水) 13:25:11 ID:???

>>643
MySQLより安定してるが

646 ：nobodyさん：2009/02/25(水) 13:34:06 ID:???

あんまりこなれてない印象があったけど、敷居が高いってだけかな
PDOの対応は微妙みたいだけど
PDO自体が微妙なのかな？

647 ：nobodyさん：2009/02/25(水) 13:38:59 ID:???

PDOはクエリの発行と結果の取得を抽象化しているけど、データベース固有の機能を利用する
仕組みは提供していないから、ちょっと凝ったことをしようとすると使えない。

唯一PDO_PGSQLのラージオブジェクト操作メソッドはドライバ作者が頑張ってるけど
ドキュメントが整備されていなくてCのソース読まないと使いこなせないのが難。

648 ：nobodyさん：2009/02/25(水) 14:39:41 ID:???

MySQLは簡易ＤＢの部類だからなどっちかといえば

649 ：nobodyさん：2009/02/25(水) 14:48:30 ID:???

MySQLが簡易なんじゃなくてOracleがでか過ぎるんだよ。
mixiがMySQLだろ？普通にサイト立ち上げる程度にOracleなんていらんでしょ。

650 ：nobodyさん：2009/02/25(水) 14:51:13 ID:???

OracleがデカイってのはWebProg板的にな。

651 ：nobodyさん：2009/02/25(水) 15:15:40 ID:???

自前でDB管理・障害対応ができるなら好きなDBMSを使えばいいんだけどね
Oracleが使われるのは機能とか規模の問題じゃないことも多い

652 ：nobodyさん：2009/02/25(水) 15:21:45 ID:???

Oracleの良さは、バグ発生したときに
サポートに調査投げることで時間稼ぎが出来るってとこに尽きる。

「現在、サポートに問い合わせ中です。」

653 ：nobodyさん：2009/02/25(水) 15:23:24 ID:???

Oracle,DB2,SQLServer,PostgreSQLとMySQLの間には大きな溝があるんだよ
仕組み自体が違うから考え方も違う

654 ：nobodyさん：2009/02/25(水) 15:37:35 ID:???

PHPの人たちはいろんな意味でLAMP環境しかしらないんだなと思わせるスレだな。

655 ：nobodyさん：2009/02/25(水) 16:02:17 ID:???

わたしはなんでも知り尽くしてますってか？

656 ：nobodyさん：2009/02/25(水) 16:08:35 ID:???

>>654
WebProgは普通LAMPでしょ。
わざわざOracle入れたのってオフィスビルが８階建て以上の会社しか知らない。

657 ：nobodyさん：2009/02/25(水) 16:09:44 ID:???

そういうんじゃなくて、DBの話でMySQL以外の話が出ると、そのプロダクト叩いたりとかさ。
現実にOracleてはスキーマはそういう意味だって解ったなら、それで納得すりゃいいのに。

658 ：nobodyさん：2009/02/25(水) 16:13:27 ID:???

PostgreSQLでもDB2スキーマの意味はOracleと同意だよ
スキーマの下にデータベースオブジェクトができる感じ
MySQLが特殊なんじゃないかね

659 ：nobodyさん：2009/02/25(水) 16:37:05 ID:???

というよりは、DBに関してスキーマという単語をいくつかのレベルで使う場合があるのに、
わざとか素でかは知らんが、一種類の定義のみでしか解釈せずにレスをぐちょんぐちょんにしてる
オラクラーがいただけの話だが
まあ「データベース定義」をDBスキーマといってみるのは誤解を招くしかっこよくもないとは思う

660 ：nobodyさん：2009/02/25(水) 17:17:47 ID:???

まぁ悪いのはオラクル馬鹿にした>>638だろ

661 ：nobodyさん：2009/02/25(水) 17:29:35 ID:???

>>658
FWが用意しているスキーマもお忘れなく。

662 ：nobodyさん：2009/02/25(水) 17:33:52 ID:???

プログラマはDB側の話なんて気にしないから
システム解ってる奴とプログラマで認識に差があるのでは
DB側の話でスキーマって言ったらだいたい領域みたいな話だよね

663 ：nobodyさん：2009/02/25(水) 17:52:34 ID:???

>>600-からずーーーっと同じ話なんだが
そろそろいいじゃね？

664 ：nobodyさん：2009/02/25(水) 18:00:42 ID:???

>>607 >>608はFWのスキーマの話をしてるのに、いきなりOracle定義のスキーマって語を
持ち出したオラクラーも悪い。だいたいここFWスレなんだからFWのスキーマだと思わないのかね？

665 ：nobodyさん：2009/02/25(水) 18:04:06 ID:???

ウェブの場合、高度な処理が要求されるんじゃなくって、簡単な処理を大量にこなすことを要求されるからな。
ミクシイみたいな大規模サイトでも結局は簡単なSELECTがほとんどだろうし。
その点で、MySQLなんかの方が向いてる。もちろん安いからって理由が最大だけど。
ORマッパーとか使い出したら、DBの機能って低いレベルで揃えさせられるからな。

666 ：nobodyさん：2009/02/25(水) 18:05:16 ID:???

>>665
その話は終わっただろ。

667 ：nobodyさん：2009/02/25(水) 18:07:21 ID:???

フレームワークのスキーマってそもそも何だよ
そのレベルの話ならフレームワーク全体がスキーマなんだから
DBの話ならデータベースサーバのスキーマだって解るだろうに

668 ：nobodyさん：2009/02/25(水) 18:09:28 ID:???

わざと混同してるんだろ。
荒らしたいから。
もしくは本気でDBのスキーマ知らなくて判断つかなかったかのどっちかだ。

669 ：nobodyさん：2009/02/25(水) 18:09:58 ID:???

MSのSQLServerも、ASP.NETと連携させると、非常にいいね。

670 ：nobodyさん：2009/02/25(水) 18:12:35 ID:???

そもそも事の発端になってる>>607はDBスキーマって明言してるわけで

671 ：nobodyさん：2009/02/25(水) 18:13:36 ID:???

お前ら、スレの名前って読めるの？？

672 ：nobodyさん：2009/02/25(水) 18:13:47 ID:???

>>670
よく読め。FWを２つに分けたらスキーマが２つになると言ってるんだ。
FWレベルの話だろ？

673 ：nobodyさん：2009/02/25(水) 18:21:22 ID:???

FWが生成するスキーマをDBスキーマと呼称したのなら
DBのスキーマを知らん阿呆だってことだろ

674 ：nobodyさん：2009/02/25(水) 18:22:46 ID:???

それでFAでいいじゃねーか。

675 ：nobodyさん：2009/02/25(水) 18:26:32 ID:???

【PHP】フレームワーク CakePHP　5ホール目【v1.2】
http://pc11.2ch.net/test/read.cgi/php/1229669539/920

920 名前：nobodyさん[sage] 投稿日：2009/02/25(水) 14:43:45 ID:???
Paginator helperにXSSの問題
http://cakephp.jp/modules/newbb/viewtopic.php?topic_id=1779&forum=9&viewmode=flat&order=ASC&start=0

...orz

676 ：nobodyさん：2009/02/25(水) 18:36:22 ID:???

>>607が間違えて>>608が完全DB側に意味を引き寄せてそれなら解るとフォローし
あとはネットイナゴみたいな感じだろ

677 ：nobodyさん：2009/02/25(水) 18:41:30 ID:???

このスレは関係ない話で盛り上がった上に反省会までやんのな。

678 ：nobodyさん：2009/02/25(水) 19:12:46 ID:???

>>676
間違いでも阿呆でもないと思うよ。
そういう風に「スキーマ」っていう人・文化もいる（ある）。正確かどうか、好ましいかどうかは置いておいて。
なんで「間違い」にしたいのかね。

679 ：nobodyさん：2009/02/25(水) 19:21:30 ID:???

スキーマの定義とかどうたらこうたらより、どうせならレプリケーションで盛り上がれよｗ

レプリケーションって使ったことないんだけど、例えばMySQLなんかの非同期レプリケーションなら、
更新系・参照系の問い合わせの際に、自分でアクセス先DBを使い分けなきゃいけないの？

もしそうだとすると、こういった使い分けに対応したフレームワークってある？
DBの接続設定でごにょごにょしておけば、更新系のクエリなら自動的にマスタの方にアクセスしに
行ってくれるような

680 ：nobodyさん：2009/02/25(水) 19:44:31 ID:???

>>678
>>607乙

681 ：nobodyさん：2009/02/25(水) 20:05:05 ID:???

しっかし、相変わらず関係ない話題のほうが盛り上がるスレだなｗ
まぁ食い違ってたバグの原因が見つかったんだから、それでいいじゃん
説明不足の仕様が問題だったんだろう

682 ：nobodyさん：2009/02/25(水) 23:23:35 ID:???

スキーマについてよくわからんのでぐぐったんだが、
論理スキーマで話をしてる人と、物理スキーマで話をしてる人がいて、
ごっちゃになったでおｋ？

683 ：nobodyさん：2009/02/25(水) 23:29:43 ID:???

>>682
そういう概念的なものではなく、も少し即物的な対象をなんと呼ぶかでのしょうもない喧嘩、に見える

684 ：nobodyさん：2009/02/26(木) 06:08:17 ID:???

PHP-usersのMLに流れていて、そこに書いてあったが、
Agaviってまだあったんだな。

685 ：nobodyさん：2009/02/26(木) 09:57:20 ID:LnongX2j

DBの違いは、ラッパーのライブラリやフレームワークが吸収してくれますね＾＾

>>679
最近だと、メモリ上にデータを置いて高速化する手法も旬の話題
http://itpro.nikkeibp.co.jp/article/OPINION/20090216/324752/
>データベース技術の世界に新顔が次々と登場している。
>米Danga Interactiveの「memcached」、ミクシィの「Tokyo Cabinet」と「Tokyo Tyrant」、楽天の「ROMA」、グリーの「Flare」などだ。
>いずれも半導体メモリーを使って大規模データベースを高速処理する技術である。

フレームワーク＋メモリーでデータキャッシュの場合、データの取り扱いをみなさんどうされてますか？

686 ：nobodyさん：2009/02/26(木) 10:02:04 ID:LnongX2j

>>684
PHPのフレームワーク
　諸行無常の響きあり＞＜
　　今使ってるFWも
　　　いつかは廃れちゃうかもね＾＾

687 ：nobodyさん：2009/02/26(木) 10:06:40 ID:???

３年前からAgavi萌えです

688 ：nobodyさん：2009/02/26(木) 10:40:55 ID:???

>>686
別にPHP以外のフレームワークだって
いつかは廃れるよ。

Javaだってそうだし。

689 ：nobodyさん：2009/02/26(木) 10:50:04 ID:???

まぁStrutsの廃れなさは異常だけどな

690 ：nobodyさん：2009/02/26(木) 11:14:21 ID:???

PHP/FIみたいなPerlスクリプトが名を変え体を変え今まで残ってる方が不思議だ。
Perl使いがいかにテンプレートに困ってたかが分かるな。当時TTがあったらPHP消えてそう。

691 ：nobodyさん：2009/02/26(木) 15:34:51 ID:???

Strutsとっくに廃れてるけどな

692 ：nobodyさん：2009/02/26(木) 15:57:18 ID:???

691は現実を見た方がいい

693 ：nobodyさん：2009/02/26(木) 18:18:24 ID:???

692は現実を見た方がいい。
廃れていないのと、COBOL化しているのは別。

694 ：nobodyさん：2009/02/26(木) 18:21:11 ID:???

印刷業界にいつまでもOS9使ってる連中がいるのと同じだな。

695 ：nobodyさん：2009/02/26(木) 20:54:26 ID:???

Cake使ってみたが、個人的には窮屈だと感じてしまったよ。

標準機能は少なくていいから、もう少し薄いフレームワークないですかね。
気持ちよくコードが書けるようなやつ。
次に試してみるCIがそんなのならいいんだけど･･･。
誰かCIの感想聞かせてください。

696 ：nobodyさん：2009/02/26(木) 21:19:53 ID:???

そしてすべてはここにもどる

>>695
ちいたんでいい

697 ：nobodyさん：2009/02/26(木) 22:11:10 ID:???

>695
一緒にkohana使おうぜ。CIから派生したフレームワーク。
PHP4を切り捨て、PHP4由来の気持ち悪い部分を一掃したのが特徴。

698 ：nobodyさん：2009/02/26(木) 22:11:57 ID:???

ちいたんは名前が最悪だ。これだけで捨てるに値する。以上

699 ：nobodyさん：2009/02/26(木) 23:03:51 ID:???

画面重視に作ると、あんまり整頓されたFWだと
身動きが取れなくなることがある。
それなら素のPHP使えよって話なのかもしれないが。

700 ：nobodyさん：2009/02/26(木) 23:57:07 ID:???

結局ZFベースにして自分で作るのが最強って話だなｗ

701 ：nobodyさん：2009/02/27(金) 00:17:14 ID:???

新規開発でも、普通にStruts一辺倒だぜｗ
もちろんStrutsも改良されてるしな

702 ：nobodyさん：2009/02/27(金) 02:43:04 ID:???

>>695
CIの解説本は１週間で読める（＝簡単）
PHPの案件は、CI＋ZFのライブラリで十分だと思う
PHPに時間をかけても意味ない（＝俺はLispの勉強を始めました）

703 ：nobodyさん：2009/02/27(金) 02:44:39 ID:???

http://www.atmarkit.co.jp/news/200902/26/redis.html
グーグル、永続化対応のインメモリDB「Redis」を発表
現在、PHPやRubyのクライアントライブラリを開発中という。

704 ：nobodyさん：2009/02/27(金) 02:51:47 ID:???

http://itpro.nikkeibp.co.jp/article/OPINION/20090226/325527/
「キー・バリュー型データストア」開発者が大集合した夜

GoogleやAmazon.com、Microsoftなどがキー・バリュー型データストアに注目するのは、分散処理を求めているからである。
キー・バリュー型データストアは、データ処理の高速化と大規模化（ひいてはクラウド・コンピューティング）を実現する上で、必須の技術になっている。

705 ：nobodyさん：2009/02/27(金) 03:06:27 ID:???

>>701
誰もお前の身辺のことは聞いてないし、スレ違いね

706 ：nobodyさん：2009/02/27(金) 03:09:48 ID:???

>>699
根本的にフレームワークが何なのか理解できてないね

707 ：nobodyさん：2009/02/27(金) 09:07:30 ID:???

>706
むしろMVCの分離から出来ていないような希ガス

708 ：nobodyさん：2009/02/27(金) 11:47:34 ID:???

MVCは幻想だよ

709 ：nobodyさん：2009/02/27(金) 18:32:37 ID:???

MVCは、モニター３つ並べて作業すると効率がいいでしょうか？
Mの編集作業で一つ、Vの編集作業で一つ、Cの編集作業で一つの画面を見る
あとで結果を表示する画面が一つで、モニター４個あれば作業効率がいいかも

710 ：nobodyさん：2009/02/27(金) 18:36:26 ID:???

>>709
MVCはscreenコマンド(UN*X)使って切り替えながら開発してるな。
デュアルディスプレイで、左開発、右ブラウザ専用。

711 ：nobodyさん：2009/02/27(金) 18:36:39 ID:???

Ｍとか滅多に編集しないから

712 ：nobodyさん：2009/02/27(金) 21:02:44 ID:???

PHP5.2.9リリースでPHP脂肪ｗｗｗ

713 ：nobodyさん：2009/02/27(金) 21:30:57 ID:???

MVCだから3つって訳じゃないんだけどな
モデル、ビュー、コントローラの他に、厳密にはアクションやサービスがあるわけで
まぁモデルとコントローラは滅多にいじらないから3つと言えば3つだけど

714 ：nobodyさん：2009/02/27(金) 21:34:25 ID:???

それはすでにMVCでは無いのでは

715 ：nobodyさん：2009/02/27(金) 21:36:28 ID:???

MVCモデルは5層あるってことじゃなくて
MVCフレームワークはいじる必要がクラスが5種類あるって事でしょ

716 ：nobodyさん：2009/02/27(金) 21:38:35 ID:???

フレームワークスレでMVCって言うの恥ずかしくない？
これからさ、MVCで語ったら、
MVC (笑）
でいいと思うんだけど。

717 ：nobodyさん：2009/02/27(金) 21:51:56 ID:???

アジャイル(笑)

718 ：nobodyさん：2009/02/27(金) 21:53:46 ID:???

アジャイル(笑)で形に囚われない自由な自分を演出

719 ：nobodyさん：2009/02/27(金) 21:57:14 ID:???

>>716
デザインパターンが理解できない方なのは解ります

720 ：nobodyさん：2009/02/27(金) 22:02:20 ID:???

MVCやらアジャイルやらは、それなりに有効で普及してるものなんだから、
別に恥ずかしくも何ともないけどな
提唱された概念につけられた名称全て恥ずかしかったら、何の議論もできないじゃないか
自意識過剰なんじゃないか？

これがアスペクト指向あたりだと、微妙になってくるけど

721 ：nobodyさん：2009/02/27(金) 22:07:23 ID:???

Javaの人間なのでMVCもアジャイルもアスペクトも何も恥ずかしくない俺
むしろ理解して使いこなせてない人の方が恥ずかしい世界

722 ：nobodyさん：2009/02/27(金) 22:15:28 ID:???

まったくだ
web2.0と一緒にすんな

723 ：nobodyさん：2009/02/27(金) 22:23:53 ID:???

いや、当たり前すぎて語るのは恥ずかしいって話なんだが。

724 ：nobodyさん：2009/02/27(金) 22:25:28 ID:???

その手の用語を当たり前に使ってるかちょっと背伸びしてる感を持ってるかの違いじゃないの

725 ：nobodyさん：2009/02/27(金) 22:25:41 ID:???

初心者が質問してるところにMVCって言うの当たり前すぎて恥ずかしいって指摘して楽しいの？

726 ：nobodyさん：2009/02/27(金) 22:26:34 ID:???

間違いを指摘しされた>>714が恥ずかしくなって暴れてるという認識でいいですか？

727 ：nobodyさん：2009/02/27(金) 22:33:43 ID:???

俺も同意するところあるなぁ。
PACで実装したシステムに、MVCに分離できてないから糞だとか言う奴もいたりしてな。

728 ：nobodyさん：2009/02/27(金) 23:24:03 ID:???

それにしたって、理解しないで言ってる奴が恥ずかしいだけであって
MVCを勧めることが恥ずかしいわけではないだろ

729 ：nobodyさん：2009/02/27(金) 23:30:02 ID:???

文脈を読もうぜ。無知だといわれたのはなんか偉そうなアホであって質問者じゃない。

C言語レベルでの構造化やカプセル化すら良く分かってないような奴も多いのが現実。
publicメソッドとグローバル関数の違いをたずねられた時はどうしようかと思った。しかも俺よりキャリア長い奴に。
まあ、俺もMVCを100%分かっているかといわれると言葉に詰まるがな。

730 ：nobodyさん：2009/02/28(土) 00:30:59 ID:???

>>726
>>714=>>716 は無理ある
ム板のLL隔離スレなんかでも、恥ずかしい恥ずかしい言って荒らすのがいる

731 ：nobodyさん：2009/02/28(土) 00:45:31 ID:???

今度は俺はObject指向解ってるぜ自慢か

732 ：nobodyさん：2009/02/28(土) 01:35:48 ID:???

とりあえず>>716が恥ずかしい存在なのは理解できた

733 ：nobodyさん：2009/02/28(土) 07:26:13 ID:???

>>729
単に言葉として理解してないならまだしも
本気で区別ついてないなら仕事できなくね？

734 ：nobodyさん：2009/02/28(土) 09:57:40 ID:???

こんどはMVCかよ・・・・。
ちなみにMVCのどこをいじる頻度が多いかはFW依存だよ。
作者によってMVCの解釈が違ったりするからなｗ

735 ：ヤングマン：2009/02/28(土) 12:22:52 ID:???

西条秀樹のＹＭＣＡで、ＭＶＣダンスを作れないだろうか？

PHPer　さあ立ち上がれよ
PHPer　今翔びだそうぜ
PHPer　もう悩む事は
ないんだから
PHPer　ほら見えるだろう
PHPer　君の行く先に
PHPer　楽しめる事が
あるんだから

すばらしい　M.V.C　M.V.C
デスマーチを　吹き飛ばして
君も元気出せよ
そうさ　M.V.C　M.V.C
若いうちは無茶なプロジェクト
何でもできるのさ

736 ：nobodyさん：2009/02/28(土) 12:31:11 ID:???

全然おもしろくないですよ。

737 ：nobodyさん：2009/02/28(土) 12:31:57 ID:???

VとYの振り付けの区別がつかない件について

738 ：nobodyさん：2009/02/28(土) 12:37:33 ID:???

こういうのはよほど発想と運がいいか、才能がないと外すよな。
本人は面白いと思ってるんだろうから親父ギャグみたいなもんだ。

739 ：nobodyさん：2009/02/28(土) 12:41:40 ID:???

おもしろくなさすぎてワロタ

740 ：nobodyさん：2009/02/28(土) 12:42:27 ID:???

ゴロがあってないんだよな。嗚呼MVCにしたほうがいい
　♪ そうさ　あ～M.V.C　あ～M.V.C

741 ：nobodyさん：2009/02/28(土) 12:51:26 ID:???

>>740
そうした所で面白くない事実は全く変わらない。

742 ：nobodyさん：2009/02/28(土) 13:00:01 ID:???

裁判起こしたくなるほどつまらんな

743 ：nobodyさん：2009/02/28(土) 13:02:19 ID:???

結構反応あるのにワロタ

744 ：nobodyさん：2009/02/28(土) 16:19:58 ID:???

つまらないって言ってもらえるだけまだまし

745 ：nobodyさん：2009/02/28(土) 16:21:30 ID:???

>>744
だな。もっと酷いと寒すぎるとかキモイとか頭大丈夫？とか言われるもんな。

746 ：nobodyさん：2009/02/28(土) 16:39:13 ID:???

別にMVCの言葉に拘る必要ないよね。
RailsはVCだったりDjangoはMVTとか言ったりしてるし、
作りやすく守りやすく区切って適当に頭文字くっつけてればいいよ

747 ：nobodyさん：2009/02/28(土) 17:26:21 ID:???

誰にも触って貰えない寒さと来たら・・・

748 ：nobodyさん：2009/02/28(土) 20:34:44 ID:???

Yiiって外部ライブラリに依存してる？

749 ：nobodyさん：2009/02/28(土) 22:06:39 ID:???

外部ライブラリってのがどのあたりまでの事をさしたいのかによりそうだけど
機能を利用するにあたって要求されるもんは
ttp://www.yiijan.org/requirements/

750 ：nobodyさん：2009/02/28(土) 23:41:05 ID:???

yii良さそうだが英語情報だけってのが辛いわ

751 ：nobodyさん：2009/02/28(土) 23:57:05 ID:???

英語が読めないなんて小学生までだよねｷｬﾊﾊｷﾓｰｲ

752 ：nobodyさん：2009/03/01(日) 10:48:52 ID:???

英語もPHPFWもさっぱりだけど翻訳しながら弄ってる
面白いよ

753 ：nobodyさん：2009/03/01(日) 10:51:46 ID:???

>>751
こういうヤツに限って英字新聞とかは全く読めない。
読めるのはマニュアルだけ。

754 ：nobodyさん：2009/03/01(日) 11:11:08 ID:???

>>753
それで十分だろ

755 ：nobodyさん：2009/03/01(日) 11:20:29 ID:???

>>754
その程度で「英語が読める」と自称してるのがキモい。

756 ：nobodyさん：2009/03/01(日) 11:39:26 ID:???

誰も自称してねーよハゲ

757 ：nobodyさん：2009/03/01(日) 11:42:50 ID:???

本人乙

758 ：nobodyさん：2009/03/01(日) 12:35:54 ID:???

英語のドキュメント読めないで許されるのは小学生までだよねｷﾓｷｬﾊ

759 ：nobodyさん：2009/03/01(日) 13:08:30 ID:???

ハナからおつむが小学生レベルな俺に隙はなかった

760 ：nobodyさん：2009/03/01(日) 13:13:59 ID:???

英語のマニュアル読めないとマは勤まらないだろ。
PerlもPHPも最初は英語のマニュアルしかなかったわけで。

Perlの英語版赤らくだは独特の言い回しだしジョークは挟むしで
TOEIC600の俺にはちょっと辛かった。

761 ：nobodyさん：2009/03/01(日) 13:35:53 ID:???

どの程度のことをやるかにもよるでしょ。ひどいマは日本語すら危ういしなｗ

762 ：nobodyさん：2009/03/01(日) 13:41:32 ID:???

ドキュメントなんてコードだけ読めばおk

763 ：nobodyさん：2009/03/01(日) 13:42:17 ID:???

プログラマはコードで会話する（ｷﾘｯ

764 ：nobodyさん：2009/03/01(日) 15:05:28 ID:???

>>763
全世界で通じる共通言語だからなｗ
インターナショナルという名の在日中華だらけの職場で
意思伝達の最終手段になってます

YiiはDocmentの他国語対応GoogleDocsだかでやってっから
かなり早いうちに一通りのマニュアルの類はそろうんじゃないかと思うよ
英訳スキル持ちはもとより、英語の勉強がてらに参加してみても面白いんじゃね

765 ：nobodyさん：2009/03/02(月) 02:53:21 ID:???

5.3は新機能が多いから未知のバグも多そうだな
運用に耐えうるようになるのはだいぶ先そう

766 ：nobodyさん：2009/03/02(月) 09:25:48 ID:???

http://lang-8.com/
↑これ使ったら英語が楽しくなるよ
＝外国語で日記を書くと、ネイティブに母国語で添削してもらえる

添削してあげれば、日本語を勉強してる外国の子から感謝されるし
マジおすすめ☆＾＾

英語のマニュアルはコードと一緒に読めば意味が分かるから、読解しやすい文章なんじゃない？

767 ：nobodyさん：2009/03/02(月) 09:34:19 ID:???

>>766
英文マニュアルはおしなべて語彙も極端に少ないし文法もかなり単純。
外国人にも簡単に読めるようになっている。
Time誌とかと読み比べてみるといい。英語の質が全然違うから。

768 ：nobodyさん：2009/03/02(月) 09:35:39 ID:???

貼り忘れ
http://www.time.com/time/

769 ：nobodyさん：2009/03/02(月) 13:45:10 ID:???

コンピュータ書籍の技術英語と普通の小説なんかの英語は別物だからな。
小説の場合、前後の文脈で意味が取れるけど、技術英語の場合、文法をよく把握していないとまるで逆の意味になったりするから。
どっちが簡単とか難しいってものでもない。
オライリーの本なんかは、スラングだらけなんで、相当読みづらいと思う。

770 ：nobodyさん：2009/03/02(月) 13:58:46 ID:???

>>769
まあでも普通に考えて簡単に読めるのはマニュアルでしょ。
マニュアル読めるから英語読めると思っちゃってる人結構いるし。
小説ガツガツ読めてマニュアル読めない技術屋はいないと思うし。

771 ：nobodyさん：2009/03/07(土) 03:03:07 ID:???

PHPのオブジェクトって存在しないプロパティーだったら
外部からいくらでも代入できるのな
なんたるビッチ
なんたるゆるまん

772 ：nobodyさん：2009/03/07(土) 03:14:11 ID:???

個人的にはnoticeくらい出してもいいかとも思うが、PHPにはstdClassというのもあってだな
まあJavaScriptでもできるんだし、配列代わりに使うのならそんなもんかなとも思う
きっちりしたプロパティなんかはアクセサ使えばいいじゃん

773 ：nobodyさん：2009/03/07(土) 03:50:11 ID:???

ある程度の規模になったらphpはむしろ使いにくいよね。
存在しないプロパティに代入できる事が、
自由度が高くて良いと思える規模がphpの領域。
その辺厳しくしないと弊害が出てくるなら、phpが適さない規模と思ってるよ。

774 ：nobodyさん：2009/03/07(土) 04:30:39 ID:???

__setも作ってないの？

775 ：nobodyさん：2009/03/07(土) 05:48:39 ID:???

>>773
大規模サイト出もPHP使ってるって言うけど
実際は楽天なんかはJavaにどんどん置換してるし
Yahoo!もPHP使ってるのはビューの部分だけでコアはJavaなんだよな

776 ：nobodyさん：2009/03/07(土) 06:12:09 ID:???

>>775
Yahoo!はJava使ってないよ。

777 ：nobodyさん：2009/03/07(土) 06:16:28 ID:???

おいおい使ってるぞ
俺携わってたし

778 ：nobodyさん：2009/03/07(土) 06:19:32 ID:???

Yahoo!はJavaとCの両方あるよ
検索系はC
サービスの一部はJava

779 ：nobodyさん：2009/03/07(土) 06:20:03 ID:???

あと知恵袋とかブックマークみたいな簡単なサービスはフルPHPじゃなかったかな

780 ：nobodyさん：2009/03/07(土) 06:26:06 ID:???

ブックマークはsymfonyだったはず

781 ：nobodyさん：2009/03/07(土) 11:52:08 ID:???

>>777
なんか、別の会社と間違ってんじゃね？
コンフル見てるけど、Java使ってるサービスなんか見たことないぞ。

>>778
サービスの一部って具体的にどれよ。

782 ：nobodyさん：2009/03/07(土) 11:55:58 ID:???

まあ検索系は最低限Cくらいプリミティブじゃないとな。
検索がPHPだったらさすがに笑う。
というか機能しねーだろ。

783 ：nobodyさん：2009/03/07(土) 12:03:59 ID:???

youtubeもgoogleに買収される前はphpだったよな

784 ：nobodyさん：2009/03/07(土) 12:21:47 ID:???

>>781
うちの会社が作ってたサイトがYahooに買収されたので具体的にはどれかは言えないが
そういう部分はJavaのところが沢山ある

785 ：nobodyさん：2009/03/07(土) 13:39:08 ID:???

>>784
買収された側のサイト名は言えるでしょ。嘘じゃないなら。
買収ってことは。公然の事実でしょ。

そしたら、俺が明日、コンフルみて確認してやるよ。

786 ：nobodyさん：2009/03/07(土) 13:43:15 ID:???

コンフルって何でつか？

787 ：nobodyさん：2009/03/07(土) 13:48:33 ID:???

まぁ、買収したとしてもメンテナーがいなきゃ、早々にPHPで作りかえるだろうね。
ガワだけはそのまんまでも。
外注のままの製品系は別として。

実際求人は、C C++ PHP Perl。Java使いは取ってないからな。
ttp://hr.yahoo.co.jp/fresh/work.html

788 ：nobodyさん：2009/03/07(土) 13:57:36 ID:???

http://japan.zdnet.com/sp/feature/07sp0060/story/0,3800076669,20347317-2,00.htm

コンフルは、なんていうかYahooの社内用語みたいだな。

ちょこっと検索した感じだと、YahooでJavaは、
アプレット系が少し出てくるくらいだな。
少なくともYahooの中でJavaはメジャーじゃなさそうだ。

789 ：nobodyさん：2009/03/07(土) 14:33:57 ID:???

>>785
スポナビ

790 ：nobodyさん：2009/03/07(土) 14:34:45 ID:???

>>787
中途の方はJava入ってるけど

791 ：nobodyさん：2009/03/07(土) 14:35:52 ID:???

あっスポナビが買収って話じゃなくて一通り見たらスポナビでServletってアドレスあるって話ね

792 ：nobodyさん：2009/03/07(土) 15:12:31 ID:???

>>790
ん？どのページ？

793 ：nobodyさん：2009/03/07(土) 15:15:22 ID:???

>>791
アドレス晒して

794 ：nobodyさん：2009/03/07(土) 15:25:14 ID:???

スポナビあやしいｗ Yahooのサービスじゃないな。
Copyright (c) 2009 Y's Sports Inc.

http://services.yahoo.co.jp/
ここに入ってないし

795 ：nobodyさん：2009/03/07(土) 15:28:06 ID:???

>>793
http://hr.yahoo.co.jp/career/detail.php?cd=0101

ってかYahooでJava使ってたらなんか困るのか

796 ：nobodyさん：2009/03/07(土) 15:34:54 ID:???

>>795
募集職種と経験とは違うわな。
Java経験でもやらせるのはPHPだし。

別にJava使ってると思ってもらってもいいけど、
Javaを扱ってる開発部署がないのに、なんでそんな話になるのかな？と思っただけ。

ただ、名前貸しというかサービス乗っ取りみたいなものの中には
Javaで組まれてるものもあるかもしれん。
たとえばスポナビはYahoo!のデザインレギュレーションから完全に外れてる。

797 ：nobodyさん：2009/03/07(土) 15:46:06 ID:???

http://sportsnavi.yahoo.co.jp/info/help/recruit.html

798 ：nobodyさん：2009/03/07(土) 16:11:45 ID:???

>>796
Java経験者なら普通C++やらせないか？C++も使ってないの？
定期的にｽﾚﾁで盛り上がるねここ。

799 ：nobodyさん：2009/03/07(土) 16:18:37 ID:???

スポナビ的に連携してる部分だとリクルート関連はJavaだな

800 ：nobodyさん：2009/03/07(土) 16:39:26 ID:???

たいして面白くもない無関係な話題引っ張りすぎの変なのが沸いてる
マ系の職場あちこち回ってると、たまにいるんだよねこういう奴ｗ

801 ：nobodyさん：2009/03/07(土) 16:44:07 ID:???

>>798
C++は使ってる。でも、なんつうか、毛色の違う人たちなんだよね。
中途採用の奴はたいがい、糞サービスのメンテに回される。

まぁ、スレチにもほどがあるので、この辺で。スンマソン

802 ：nobodyさん：2009/03/07(土) 16:44:37 ID:???

俺はヤフーのすべてを知ってるんだぜ自慢をしたいんだろ。
使ってるの見たって奴がいるなら、それていいじゃんかな。

803 ：nobodyさん：2009/03/07(土) 17:25:34 ID:???

あんな大企業を単一言語で回してたらそっちのほうが衝撃だわ。

国内PHP大規模サイトトップ10に入る某社にいるが、内部じゃRubyもJavaもPerlも使ってる。フロントじゃ当然FlashやJS使うしな。
スクリプトまで通さずにCで書いたApacheモジュールでケリをつける部分だってある。
会計システムと繋ぐならJava以外の選択肢なんぞ考えたくもない。

だいたい、単一言語に社運をかけるなんて、上場企業クラスになったらあり得ない。
急に別言語に乗り換えてもプログラマはいくらでも確保できるだろうが、インフラ側の経験値蓄積が間に合わない。
エンジニア側も同じ。最低2つはスキルがないと簡単に切られるぞ。
経営層的に言ってPHPの利点の一つは、使い捨てるエンジニアが市場に腐るほどいる（いなくとも1月も研修すれば完成する）点だしな。

804 ：nobodyさん：2009/03/07(土) 18:55:58 ID:???

自信満々にCとかjavaとか使ってるとか言うけど
俺みたいにPHPで足りない機能をCでライブラリ作ったり
apacheのモジュール作ったりしてるやつは少ないだろうな

805 ：nobodyさん：2009/03/07(土) 19:57:58 ID:???

自分はその程度のスキルすらないゴミの部類だけど
プログラマ一本を主軸にやってくつもりならそれくらいはできないと正直この先生
きのこれないと思う

806 ：nobodyさん：2009/03/07(土) 20:15:20 ID:???

>>804
どうやってやんの？

807 ：nobodyさん：2009/03/07(土) 20:29:23 ID:???

>>806
知識がない人がよく質問するね、それ

808 ：nobodyさん：2009/03/07(土) 20:37:43 ID:???

知らないから聞いてるんだけど意味が分からないｗ

809 ：nobodyさん：2009/03/07(土) 20:44:35 ID:???

知らない人に説明しても、説明の意味がわからないでしょ
意味がわからないぐらいだからもっと勉強してからおいで

810 ：nobodyさん：2009/03/07(土) 20:46:11 ID:???

>>804
普通やりますがな

811 ：nobodyさん：2009/03/07(土) 20:47:23 ID:???

イメージ的には、なんかSDKみたいなソースの固まりを落としてきて
ごにょごにょしてコンパイルすると.soができるって感じ？
いや当てずっぽうだけど

812 ：nobodyさん：2009/03/07(土) 21:53:23 ID:???

ＰＨＰに足りない機能ってなんだった？

813 ：nobodyさん：2009/03/07(土) 21:55:12 ID:???

オフィシャルのソース落としてきて、
中に入っているモジュール部の近い物を選んでコピペして
名前変更して、Makefileとかをごにょれば出来るお

814 ：nobodyさん：2009/03/08(日) 01:15:23 ID:???

生き残る奴は技術力が高い奴じゃなくて単価が安い奴だけどな
高い技術力なんてさほど要求されない
単なるオナニー

815 ：nobodyさん：2009/03/08(日) 02:19:51 ID:???

使い捨ての中華みたいな扱いの奴は、そうだろうな

816 ：nobodyさん：2009/03/08(日) 05:17:12 ID:???

Yahooは募集が多いのは、PHPかJavaだと思う。部署によってはそれ以外の言語も使ってるだろうけど。

817 ：nobodyさん：2009/03/08(日) 05:45:29 ID:???

言語なんて適材適所。
phpだと作りにくいもの・規模はやっぱりあるし、
phpだけに絞るのは、プログラマー個人もとしても開発会社としても、
どう考えてもお勧めできないな。

818 ：nobodyさん：2009/03/08(日) 09:56:10 ID:???

PHPはどう考えても特殊だし、配列操作１つ取っても関数群が充実してるから
アルゴリズムに弱いヤツが多そうだな。遊びでもいいから他の言語も覚えるに
越したことはない。時代が変わると潰しが利かなくなりそう。

プログラマ自体が潰し利かないんだからPHPしか書けませんとかヤバイと思う。

819 ：nobodyさん：2009/03/08(日) 10:02:31 ID:???

ショートタグ使わない奴って馬鹿だよね？

820 ：nobodyさん：2009/03/08(日) 10:03:04 ID:???

逆だろ

821 ：nobodyさん：2009/03/08(日) 10:07:22 ID:???

短くて便利なのに使わないんだから馬鹿だろ

822 ：nobodyさん：2009/03/08(日) 10:42:34 ID:???

>>821
俺も逆だと思う。理由は自分で考えるなり調べるなり汁。

823 ：nobodyさん：2009/03/08(日) 10:42:49 ID:???

>>818
ライブラリの充実度なら、C++のほうが上だぞｗ

824 ：nobodyさん：2009/03/08(日) 10:50:02 ID:???

>>823
例えば配列からある数値をスキャンする程度の場合、C++だったらゴリゴリ書くだろ。
PHPはその程度のアルゴリズムを知らなくても使えるからな。

それ言ったらPerlのCPANの充実度もPHPのPEARより上だし。多分。

825 ：nobodyさん：2009/03/08(日) 11:42:51 ID:???

>>824
> C++だったらゴリゴリ書くだろ
そこまでプリミティブなものまでいちいち書くのか？
標準ライブラリとか使わないの？

826 ：nobodyさん：2009/03/08(日) 11:53:18 ID:???

>>824
long la[N];
long* lp = find(la,la+N,12L);
if ( lp != la+N ) {
// 見つかった!
}

C++でアルゴリズムなんか知る必要はありません。

827 ：nobodyさん：2009/03/08(日) 11:57:57 ID:???

まったく関係ないが、C++ってPerlより記号多いというか暗号っぽいことあるよな

828 ：nobodyさん：2009/03/08(日) 11:58:53 ID:???

C++書いてたの15年近く前だからなぁ・・・状況が変わったのか、俺が間違ってたのか。
サンクス。

829 ：nobodyさん：2009/03/08(日) 12:44:23 ID:???

C++はBoostとSTLを使いこなせれば超強力。
ただ黒魔術的ではある。C++0xになるともう...

830 ：nobodyさん：2009/03/08(日) 14:12:48 ID:???

PEARって全然使われてないだろ。CPANとは比べもにならない。そもそも、PHPの場合、組み込み関数ですべて出来ることが売りなんだから。

831 ：nobodyさん：2009/03/08(日) 14:49:59 ID:???

組み込み関数ですべて出来ることが売りなんだから。
組み込み関数ですべて出来ることが売りなんだから。
組み込み関数ですべて出来ることが売りなんだから。
組み込み関数ですべて出来ることが売りなんだから。
組み込み関数ですべて出来ることが売りなんだから。
組み込み関数ですべて出来ることが売りなんだから。
組み込み関数ですべて出来ることが売りなんだから。
組み込み関数ですべて出来ることが売りなんだから。
組み込み関数ですべて出来ることが売りなんだから。

え？

832 ：nobodyさん：2009/03/08(日) 15:15:21 ID:???

エスケープ一つ取ってもお任せにできないことが多いから

833 ：nobodyさん：2009/03/08(日) 15:49:27 ID:???

Perlなんかだと、CPANのモジュールがインストール出来ないと、使い物にならない。
で、シェルが開放されてるレンタルサーバじゃなければ、モジュールのインストールは難しい。

834 ：nobodyさん：2009/03/08(日) 16:00:49 ID:???

PHPerは全員LISPが使えるようになろう！

835 ：nobodyさん：2009/03/08(日) 16:54:26 ID:???

>>833
は？

836 ：nobodyさん：2009/03/08(日) 16:59:47 ID:???

>>833
コンパイル必要なXSモジュールが無ければ、
extlibとかに突っ込んでまとめて配布すれば大丈夫だよ。
MovableTypeとかが現にそうやってる。

837 ：nobodyさん：2009/03/08(日) 17:35:45 ID:???

たまたま読んだんだが、
WEB+DB PRESSのVol.48のモダンプログラミング入門という特集が、
今のこのスレの流れに合ってる気がする。
気が向いたら読んでみて。

838 ：nobodyさん：2009/03/08(日) 17:39:02 ID:???

UPしてくれ

839 ：nobodyさん：2009/03/08(日) 17:52:58 ID:???

コピペでもおｋ

840 ：nobodyさん：2009/03/08(日) 20:35:02 ID:???

>>836
> >>833
> コンパイル必要なXSモジュールが無ければ、
それが致命的な問題だろ。

841 ：nobodyさん：2009/03/08(日) 20:52:18 ID:???

>>838
WEB+DB PRESS総集編［Vol.1～48］
がでたら読んでみるｗ

前回の総集編、Vol.1～36の
発売日が2007年3月30日発売だから
もうすぐだよな？

842 ：nobodyさん：2009/03/08(日) 22:37:10 ID:???

W+Dはバックナンバーが役に立たないというわけじゃないけど新しいうちに読んだ方が面白いよ
・・・と言いつつ自分はvol.46～48を積んでる

843 ：nobodyさん：2009/03/08(日) 22:57:06 ID:???

出版社さん宣伝乙

844 ：nobodyさん：2009/03/09(月) 02:47:11 ID:???

$_REQUESTがあるのにわざわざオブジェクトでRequestとか作るFWってあほなの？

845 ：nobodyさん：2009/03/09(月) 02:54:46 ID:???

>>844
毎度毎度、
$value = isset($_REQUEST['value']) ? $_REQUEST['value'] : DEFAULT;
ってするのもアホっぽいが。

846 ：nobodyさん：2009/03/09(月) 05:07:06 ID:???

オブジェクトにするメリットもあるにはあるが、ほとんどの場合、$_REQUESTで十分なんだよな。
$req = array_merge(array('key1'=>'DEFAULT1','key2'=>'DEFAULT2'),$_REQUEST)

847 ：nobodyさん：2009/03/09(月) 08:05:45 ID:???

>>844
そのあほなＦＷのリクエストオブジェクトは$_REQUESTを格納してるだけなの？
他に仕事してないんならアホだわ。

848 ：nobodyさん：2009/03/09(月) 08:32:04 ID:???

ほとんどは、>>845のnotice避けと、magic_quotes対策だろ。

>>846
$get = array_merge(array('key1'=>'DEFAULT1','key2'=>'DEFAULT2'),$_GET)
$post = array_merge(array('key1'=>'DEFAULT1','key2'=>'DEFAULT2'),$_POST)
$cookie = array_merge(array('key1'=>'DEFAULT1','key2'=>'DEFAULT2'),$_COOKIE)
$req = array_merge(array('key1'=>'DEFAULT1','key2'=>'DEFAULT2'),$_REQUEST)

って毎回書くよりはスマートってことだろ。十分なメリットだよ。
あと、$_REQUESTってCookieも入るよね。やや乱暴な気がするので、Cookieだけ除外するとか

849 ：nobodyさん：2009/03/09(月) 08:36:24 ID:???

リクエストごとに初期化する処理に、$req = array_merge(array('key1'=>'DEFAULT1','key2'=>'DEFAULT2'),$_REQUEST)を1行書いておけばいいだけ。
もっとも、毎回isset($_REQUEST[''])で確認とっても構わないと思うけど。俺はそうしてるし。
せっかく$_REQUESTとか$_SESSIONみたいな便利なものがあるのに、余計なラッパーは要らない。

850 ：nobodyさん：2009/03/09(月) 08:46:53 ID:???

> 1行書いておけばいいだけ
そして global $req ですね、わかります。

グローバル変数なり関数なりを使いたくないなら、悪いことは言わないから
クラスなりオブジェクトなりにしておけ。使いたいなら何も言わんが。

851 ：nobodyさん：2009/03/09(月) 09:30:49 ID:???

>>849
>$req = array_merge(array('key1'=>'DEFAULT1','key2'=>'DEFAULT2'),$_REQUEST)を1行書いておけばいいだけ。
これだからPHPerは。。。

852 ：nobodyさん：2009/03/09(月) 09:44:23 ID:???

>>851の説明を待ちましょう。

853 ：nobodyさん：2009/03/09(月) 10:52:58 ID:???

さすがクソコーダの考えることは違うな

854 ：nobodyさん：2009/03/09(月) 10:59:02 ID:???

>>852

855 ：nobodyさん：2009/03/09(月) 11:04:16 ID:???

どうしてもオブジェクトで表現したいときだけ、$obj = new Klass($_REQ)ってやればいい。
どうやったところで、$_REQには単純なスカラ変数（たまに配列）しか入ってないんだから。
Perlなど他の言語のように、自前でクエリストリングを取り出す処理を実装しなければいけないなら、初めからオブジェクトにしてもいいかもしれないけど。

856 ：nobodyさん：2009/03/09(月) 11:13:35 ID:???

なぁなぁ、それでどのＦＷのリクエストオブジェクトがそんなに糞なわけ？
参考までに教えてくれ

857 ：nobodyさん：2009/03/09(月) 20:31:50 ID:???

>>851
説明はまだか？

858 ：nobodyさん：2009/03/09(月) 22:56:56 ID:???

>>857
説明しないと分からないんでちゅか？

859 ：nobodyさん：2009/03/09(月) 23:44:57 ID:???

説明できないときのいいわけかよｗ

860 ：nobodyさん：2009/03/09(月) 23:52:09 ID:???

>>849はフレームワークを使ったことはあっても、フレームワークのソースは読んでないんだな。たぶん。

861 ：nobodyさん：2009/03/09(月) 23:53:01 ID:???

WhatじゃなくてHowがむき出しのダサダサコードだって言いたいんだろうけど、PHP使うような程度ならこれでいいんじゃね？

862 ：nobodyさん：2009/03/09(月) 23:59:31 ID:???

それは、フレームワークを使うか使わないかという段階での振り分け。言語の問題じゃない。

それに、>>849にクスクス笑いが起きるのは、デフォルト値実装の意味がわかってないからだよ。

863 ：nobodyさん：2009/03/10(火) 08:31:56 ID:???

PHP（mod_php）自体がグローバル変数を使い回すように設計されてる。

864 ：nobodyさん：2009/03/10(火) 09:12:31 ID:???

でっていう

865 ：nobodyさん：2009/03/10(火) 12:45:37 ID:???

フレームワーク覚えたいのですけど
シンプルなフレームワークありませんか？
デザイナーとプログラマが分離して作業できればいいんですが

866 ：nobodyさん：2009/03/10(火) 12:56:40 ID:???

ちいたん

867 ：nobodyさん：2009/03/10(火) 18:09:37 ID:???

>>865
コードイグナイタ使っとけ。

868 ：nobodyさん：2009/03/10(火) 21:34:04 ID:???

YiiFrameworkはソースの中で$_POSTをじかにアクセスしてるな。
ドキュメント見てて少し意外だった。
mojavi2ですらrequestオブジェクトだったというのに・・・。

869 ：nobodyさん：2009/03/12(木) 17:45:05 ID:y65Mhsc8

PHPのFWに、ページ遷移のテストの機能を持ったものってありますか？

870 ：nobodyさん：2009/03/12(木) 20:12:27 ID:???

具体的にどういうこと？

871 ：nobodyさん：2009/03/12(木) 22:29:23 ID:???

フレームワーク使いたいんですがcakePHPか
国産のフレームワーク使うか迷っています
国産のフレームワークとかどうですか？

872 ：nobodyさん：2009/03/12(木) 22:31:15 ID:???

RoRみたいなことがしたいならケーキ焼いてろ。

873 ：nobodyさん：2009/03/12(木) 23:09:56 ID:???

国産のどのフレームワークだよ

874 ：nobodyさん：2009/03/12(木) 23:19:51 ID:???

>>869
諦めてPerlにしましょう。

875 ：nobodyさん：2009/03/13(金) 01:50:59 ID:???

ちいたんだろ

876 ：nobodyさん：2009/03/13(金) 02:26:04 ID:???

ページ遷移のテストって、どういうのかハッキリ分からないけど、Perlのフレームワークにそんなのあったっけ。CatalystとCGI::APPぐらいしか使ったことないけど。

877 ：nobodyさん：2009/03/13(金) 10:29:47 ID:???

国産フレームワークってどれがいい？
いずれcakePHPをやろうと思っています

878 ：nobodyさん：2009/03/13(金) 10:47:04 ID:???

>>877
まず国産にこだわる理由を書くと、それなりの意見や感想レスも出てくるかと。
いずれって事は、今は何を使ってるの？その辺も。
そこいらを書かないと実のある質問ではほとんどないと思う。

879 ：nobodyさん：2009/03/13(金) 11:08:51 ID:???

>>878
まずは、国産、つまり日本語で丁寧に解説されているのを
やってみようと思いました。英語わからないですし
ＰＨＰのフレームワークとはいえ、何かにつまづくかもしれないですし

今は何も使っていません。rubyのフレームワークを使って挫折しました。
サーバにアップロードするだけで使えるＰＨＰを勉強して
今、そろそろフレーム段階に突入したところです。

それほど難しいのはいらないので、cakePHPに興味があります
その前に国産使おうとしました
国産の種類の適正を知りたいです

880 ：nobodyさん：2009/03/13(金) 11:19:10 ID:???

それなら、あくまでも私見だけど、いきなりcakePHPで問題ない、と思う。
日本語の解説は、国産（現役はEthnaくらいか）より遙かに多かったりする。

あと、これはどのフレームワークにも言えることだけど、「どう使うのか」の部分では
解説やリファレンスが役に立つが、「どうなってるのか」の部分では、最終的には
ソースを読むしかないので、シンプルに書かれているフレームワークも触ってみると
いいかも。CI（Kohanaの方がいい？）とか、ちいたんwとか

881 ：nobodyさん：2009/03/13(金) 11:31:43 ID:???

ちいたん、って何かの罠なんですか？

882 ：nobodyさん：2009/03/13(金) 11:37:52 ID:???

>>879
ZFの方がお勧め

883 ：nobodyさん：2009/03/13(金) 12:52:43 ID:gvTYRnry

デザインとプログラムを分けて制作したいのですが
cakePHPは表示するのにデータベースを使うみたいで困ってます
データベースなしで使えるフレームワークがございましたら教えてください

884 ：nobodyさん：2009/03/13(金) 13:46:06 ID:???

cakePHP以外全部

885 ：nobodyさん：2009/03/13(金) 13:51:29 ID:???

表示にDBを使うって何に使ってるの？

886 ：nobodyさん：2009/03/13(金) 19:09:47 ID:???

>>883
それはあなたの思い込み。

さすがのcakePHPもDBをつかわないとHelloWorldも書けないとか、そんな終わっている仕様ではない。

887 ：nobodyさん：2009/03/13(金) 19:11:45 ID:???

>>879
国産FWでドキュメントがきっちりしてるのってEthnaしかないと思う。
EthnaのコミッタまでCakePHPを使い出してるらしいから、
もうだいぶ終わってる感があるけど・・・。

symfonyもCakePHPも日本語のドキュメントは充実してますよ！

888 ：nobodyさん：2009/03/13(金) 19:44:23 ID:???

前任者がmojavi2で作ったシステムのメンテしててずっとPHP4で
来てるんだけど、いい加減にPHP5以降を考慮してフレームワーク
移行かもしくはmojavi2のソースいじるかどうしようかと思案中。

mojavi2からシフトしやすいFWってどれがいいですかね。
どのみち多少のコード書き換えは発生するんだしと考えると
リセットして今後の運用のみ考えて選定したほうがいい気もするし・・・・

ちなみにシステムはとある業界の業務用アプリで大雑把に
ソースファイル数で2000近くある。当初２，３百ファイル程度の
規模だったのが客の要望にこたえているうちに雪だるま式に
膨らんでしまった。
規模がもう少し小さければ書き直すんだけど・・・

あと前任者はドロップアウトしてもう居ません（泣

889 ：nobodyさん：2009/03/13(金) 19:52:48 ID:???

>>888
やっぱりsymfonyでしょう
もう大分原形とどめていないとはいえ、mojavi3ベースだし

890 ：nobodyさん：2009/03/13(金) 20:11:12 ID:???

さあ、お前の代からRoRにするんだ。

891 ：nobodyさん：2009/03/13(金) 20:57:17 ID:???

>>886
cakePHPはDBないと動かないぞ

892 ：nobodyさん：2009/03/13(金) 20:58:41 ID:???

げ、調べたらＤＢないと動かないみたい
cakephpｗ

893 ：nobodyさん：2009/03/13(金) 21:35:38 ID:???

さすがカビたケーキと言われるだけあるな

894 ：nobodyさん：2009/03/13(金) 21:59:40 ID:???

いや普通に$uses = nullって書くだけでDB(モデル)使わないアプリ作れるけど
同じシステム内でだって画面によっちゃDB使わない画面もあるわけで、
そういうところでモデル呼び出さない設定ができて当たり前なわけで、
当然Cakeだってそういう設定はできる。

895 ：nobodyさん：2009/03/13(金) 22:45:25 ID:???

DBなくても動くんじゃないの？

896 ：nobodyさん：2009/03/13(金) 22:54:58 ID:???

さすが毒入りケーキ

897 ：nobodyさん：2009/03/13(金) 23:56:22 ID:???

>>894
ない
あるならソースよろ

898 ：nobodyさん：2009/03/14(土) 01:10:31 ID:???

http://www.1x1.jp/blog/2007/08/cakephp_no_db.html

usesの件は使ってりゃ誰でも気がつくだろ

899 ：nobodyさん：2009/03/14(土) 11:26:46 ID:???

>>883
CakePHPは少ししか使ったことないから詳しくは知らないけど、
大抵のphpで作るアプリケーションはデータベース使うよね。
別にデータベース使わないと駄目というつもりはないんだけど、

> デザインとプログラムを分けて制作したいのですが

この発言からすると、データベースについてなにか勘違いをしている気がするんだ。

デザインとプログラムを分けるには、
ロジックを普通にphpで書いて、デザインはテンプレートの仕組みで作ることだよ。
で、そのテンプレートに表示する内容は、
ロジックに含めず大抵はデータベースに格納する。
小規模な場合は、CSVファイルに保存する事もないとはいわないけど、
その方が逆に面倒だと思う。

900 ：nobodyさん：2009/03/14(土) 11:33:54 ID:???

>>899
フレームワークというより、Smarty等を勧めるだけでいいような気がする。

> 小規模な場合は、CSVファイルに保存する事もないとはいわないけど、
> その方が逆に面倒だと思う。
つSQLite
そろそろブラウザにも搭載されようかって勢いだし、正直データベース前提で
何の問題もないような。

901 ：nobodyさん：2009/03/14(土) 15:07:22 ID:???

hoge/fuga/100
と
hoge/fuga/100/
どっちのURLがいいと思う？
上は冗長じゃないけど100がファイル名みたいでちょっと違和感あるし
下は冗長だし、悩む

902 ：nobodyさん：2009/03/14(土) 15:22:56 ID:???

そもそも前提条件がわからん
各パラメタがデータなのかディレクトリなのかコントローラなのかアクションなのか

903 ：nobodyさん：2009/03/14(土) 15:24:12 ID:???

冗長の意味を知って使わないと笑われるぞ

904 ：nobodyさん：2009/03/14(土) 16:41:43 ID:???

簡単な線引きするなら、さらに下位層に当たる名前があるなら
末尾にスラッシュつけるかな、俺なら

ってか、よくわかってないなら普通にGETでパラメータ渡しておけばいいんじゃね
スラッシュの有無なんて気にしないですむよ＾＾

905 ：nobodyさん：2009/03/14(土) 17:02:04 ID:???

>892
>893
>896
>897
カビてたり毒入りだったりするのは君らの頭みたいだねw

906 ：nobodyさん：2009/03/14(土) 17:09:10 ID:???

caker乙ｗｗ

907 ：nobodyさん：2009/03/14(土) 18:51:50 ID:???

どれ使えばいいの？
個人的には初心者なのでcakephpの名前が入っていき安い感じがしたんですが

908 ：nobodyさん：2009/03/14(土) 18:54:54 ID:???

名前で決めるのか。斬新だなｗ

909 ：nobodyさん：2009/03/14(土) 19:01:24 ID:???

下痢したければカビケーキをどうぞ
ただし正露丸を忘れずに

910 ：nobodyさん：2009/03/14(土) 19:02:12 ID:???

http://www.google.co.jp/trends?q=cakephp%2Csymfony%2Cmojavi%2CEthna&ctab=0&geo=all&date=all&sort=0

困った時は「調査機関G」に聞くといい

911 ：nobodyさん：2009/03/14(土) 19:14:44 ID:???

なんでZend抜いたんだ
http://www.google.co.jp/trends?q=cakephp%2Csymfony%2Cmojavi%2CEthna%2CZend+framework&ctab=0&geo=all&date=all&sort=0

912 ：nobodyさん：2009/03/14(土) 19:31:00 ID:???

CakePHPはデータベース無くても動く。

のはいいとして、データベース無くても
データベースを使ったのと同等のことができる
フレームワークってあるのかな？

つまり、設定をmysqlからfileに変えるだけで
動くようなもの。・・・まあ無いよね。

913 ：nobodyさん：2009/03/14(土) 19:43:01 ID:???

ZF使ってる身としてはお前らが一体何に悩んでるのか分からん

914 ：nobodyさん：2009/03/14(土) 19:45:21 ID:???

ZFを使っているからわかんねーんじゃね？
ZFよりも早く開発できるものがあるということに。

915 ：nobodyさん：2009/03/14(土) 19:50:27 ID:???

早く開発することだけ考えた結果がこのざまだよｗ

916 ：nobodyさん：2009/03/14(土) 19:51:16 ID:???

開発の早さ意外に何を求めてほしいんだ？

917 ：nobodyさん：2009/03/14(土) 20:12:56 ID:???

CakePHPしか使ってないからわかんねーんじゃね？

918 ：nobodyさん：2009/03/14(土) 20:54:22 ID:???

CodeIgniterを忘れてもらっちゃ困るぜ
ttp://www.google.co.jp/trends?q=cakephp%2Csymfony%2CEthna%2CZend+framework%2CcodeIgniter&ctab=0&geo=all&date=all&sort=0

919 ：nobodyさん：2009/03/14(土) 21:21:54 ID:???

PHP雑魚いｗｗｗ

http://www.google.co.jp/trends?q=cakephp%2Csymfony%2CZend+framework%2CcodeIgniter%2CRuby+on+Rails&ctab=0&geo=all&date=all&sort=0

920 ：┌【 ┐=ﾟωﾟ=】┐：2009/03/14(土) 21:32:09 ID:???

うひ

921 ：nobodyさん：2009/03/14(土) 21:34:42 ID:???

railsの影響受けてないphpフレームワークなんてほとんどないしな

922 ：nobodyさん：2009/03/14(土) 21:35:33 ID:???

cakephp設置してみたんですが
何もクリックするものないんですが
何かをクリックしたら、作成画面とか出て粉インすか？

923 ：nobodyさん：2009/03/14(土) 23:14:21 ID:???

php.iniでエラー設定にstrict使ってるからボロボロなんだよね、cakePHPって
エラーが大量に出過ぎてフイテそのままゴミ箱に移動した

924 ：nobodyさん：2009/03/14(土) 23:58:44 ID:???

cakephpって、プライマリーキーの名前に必ずid
テーブルの名前に必ず複数形、
この規約を違反するときは、違反するとコードを書く

フレームワークってこんなのばかりなんですか？初心者です

925 ：nobodyさん：2009/03/15(日) 00:01:14 ID:???

926 ：nobodyさん：2009/03/15(日) 00:01:54 ID:???

>924
Railsの影響を受けてるフレームワークはだいたいそんな感じ。
「設定より規約」と呼ばれる考え方だな。
特に割とどうでもいい部分について、一定のルールに従う事でコードを書かないで済ませる事ができる。
関数のデフォルト引数指定みたいなもんだ。

927 ：nobodyさん：2009/03/15(日) 00:06:09 ID:???

>>926
そうなんですか、ありがとうございます
rubyのフレームワークで挫折したので、今度はがんばりたいです
(作れないうえに、サーバにアップもわからなかった)

928 ：nobodyさん：2009/03/15(日) 00:10:14 ID:???

最初に手をつけるならZendとかEthnaとか自由度高いのから始めた方がいいと思うけどね
全く詳しくないと規約縛りのフレームワークはなんで規約で縛ってるのか実感しづらいでしょ

929 ：nobodyさん：2009/03/15(日) 01:05:02 ID:???

いやちょっとまて。
RoRで始めようとしたってことは、PHPもあんまり知らないのではないかと。
それならZFとかEthnaなんてまったく使い方わからんだろ。
CakePHPみたいな、「こう書いたら画面が出る」的なフレームワークを選ぶのもわからんでもない。

でも、RoRをWindowsにいれてWEBrickで動かすってとこまでは、そんなに難しくないはずなんだけどね。
むしろPHPよりも環境作りやすいくらい。
サーバで動かすってところで躓くのなら、まずはローカルで遊んでみるのが一番楽ちんだと言ってみる。

930 ：nobodyさん：2009/03/15(日) 01:30:29 ID:???

フリーのサーバー適当に借りてからやろうとおもうと
Rubyはまったく使い物にならないことが多いってのがあるから、
よほどの理由とかがないかぎりはRubyは覚えなくても問題ないかなー

PHPはarrayさえなんとかしてくれれば他は今のとこ不満ないわー

931 ：nobodyさん：2009/03/15(日) 02:09:46 ID:???

RoRは対応してない鯖多いからな
RubyのCGIじゃないと駄目なところが多い

932 ：nobodyさん：2009/03/15(日) 07:13:55 ID:???

スレ違いだが、Ruby使うならLinux環境の方がいいよ。

933 ：nobodyさん：2009/03/15(日) 07:29:12 ID:???

PHPだってそうだろ
win環境で開発してるしてる奴は昭和

934 ：nobodyさん：2009/03/15(日) 07:41:47 ID:???

ASP.NETの高機能ぶりを見ると、コマンドラインでファイル作って、エディタでしこしこコードを書いてるのは、原始時代のようだけどな。

935 ：nobodyさん：2009/03/15(日) 09:36:44 ID:???

rhacoがgihyo.jpで連載されている件
2回目マダー?

936 ：nobodyさん：2009/03/15(日) 09:44:26 ID:???

アスプｗ

937 ：nobodyさん：2009/03/15(日) 10:54:02 ID:???

>>927
小規模なサイトを高速で作成するなら、シンプルなCodeIgniterがいいよ
CodeIgniterの使い方は、覚えることが少ないから、すぐに使い出せる

CodeIgniterの標準機能で不足を感じたら、Zend Frameworkの機能をCodeIgniterに取り込んで利用（拡張）することもできる
CodeIgniterを比較基準にして、他のPHPのフレームワークを使い比べてみたらいいと思います

938 ：nobodyさん：2009/03/15(日) 11:01:14 ID:???

SPLの本体って単なるPHPソースなのかよ
しょぼすぎﾌﾟｷﾞｬｰ

939 ：nobodyさん：2009/03/15(日) 11:07:12 ID:???

>>934
Microsoftは、PHPを支援している
http://www.microsoft.com/japan/opensource/php/

・Microsoftは、WEBアプリ作成でPHP（オープンソースのマーケット）を無視できない
・ASP.NETとPHPは、ユーザー層が違うと思っているか、あるいはユーザーを他に取られないように布石を打っているんじゃないですかね？

PHPユーザーでIDEが好きな人は、Zend Studio、Eclipse、NetBeansとか使えばOK？

940 ：nobodyさん：2009/03/15(日) 11:12:33 ID:???

MS自体が斜陽なんだから
斜陽技術にロックインされるのはあまりにリスキー
アスプ厨の明日はない

941 ：nobodyさん：2009/03/15(日) 11:25:19 ID:???

Windowsを抜きにしても、.NETは純粋に使いやすいと思うぞ。
Monoがあるからそこまでリスキーでもないしな。
web屋ならJava覚えたほうが無難ではあるし、MSのサーバーサイド技術が斜陽というのは否定できんが。

>937
ぶっちゃけ、ディスパッチャとM-V-C間を自動で繋ぐ機構、後は好みに応じてO/Rマッピングとかがあれば十分だよね。
そこらにあるフレームワークは、多機能にしようとして学習コスト上げすぎだと思う。
PHPは覚えやすいのが最大の強みなのに。
まあ、基本的に初心者向けのプロダクトではないので、当然といえば当然なのだけれど。

942 ：nobodyさん：2009/03/15(日) 11:59:33 ID:???

.NetからJavaなら自動でソースコード変換できるツールあるから
いざとなれば実はなんとかなる

943 ：nobodyさん：2009/03/15(日) 17:15:38 ID:???

>>927
きみはRuby on Railsのほうが向いてると思うなぁ。
Rubyのほうが、コミュニティが初心者に優しいよ。

944 ：nobodyさん：2009/03/16(月) 00:10:35 ID:???

MSが斜陽って。さすがペチパー脳。

945 ：nobodyさん：2009/03/16(月) 00:17:50 ID:???

>>944
既に終わったビジネスモデルの上に立脚してるんだから
斜陽と言わず何と言う？

946 ：nobodyさん：2009/03/16(月) 00:31:46 ID:???

まあ、ASP.NETの場合、業務アプリケーションからウェブへのアプローチという面が強いので、DTP屋がウェブを始めるからPHPを覚えるみたいなのとは反対の位置にあるとは言える。

947 ：nobodyさん：2009/03/16(月) 00:37:17 ID:???

だいたいサーバと言っても、ウェブがすべてじゃない。ExchangeやSharePointなんかで、オフィスサーバはガッチリ押さえてある。
ASP.NETはバジェットの大きなコーポレートサイトがターゲットなわけで、WordPressやECCUBEをカスタマイズして数万円拾うような仕事とは接点がないのは仕方ない。

948 ：nobodyさん：2009/03/16(月) 10:38:02 ID:???

アッースプ厨肛門裂傷で脂肪ｗｗｗ

949 ：nobodyさん：2009/03/17(火) 01:54:58 ID:???

やっぱりＰＨＰが最強です
最初から画像を扱える(^^
フレームワークで作ってもアップロードするだけ(ffftpの平文で)(^^@
rubyやjavaなど糞

950 ：nobodyさん：2009/03/17(火) 07:38:06 ID:???

RubyもJavaもアップロードするだけなのだが。

951 ：nobodyさん：2009/03/17(火) 08:06:31 ID:???

ffftpを使う化石原人がまだいたとは笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑

952 ：nobodyさん：2009/03/17(火) 08:31:25 ID:???

導入するまでの金額が高かったら使いやすさとか関係なくね？

953 ：nobodyさん：2009/03/17(火) 08:59:36 ID:???

>>949
全てのサーバにPHPやMySQLが最初から入ってると思うなよ。

sh・awk最強。

954 ：nobodyさん：2009/03/17(火) 09:19:36 ID:???

FTPソフトの今の時代はfilezillaだろ

955 ：nobodyさん：2009/03/17(火) 09:20:23 ID:???

ffftpなんてSFTPやサーバ上でファイルの編集もできない初心者向けすぎる
filezillaに早く乗り換えろ

956 ：nobodyさん：2009/03/17(火) 10:13:18 ID:???

なんとなくWinSCP使ってるなぁ。

957 ：nobodyさん：2009/03/17(火) 10:47:29 ID:???

Javaはコンパイルが必要だけどな。

958 ：nobodyさん：2009/03/17(火) 11:02:48 ID:???

JSPのことではなかろうか

959 ：nobodyさん：2009/03/17(火) 11:54:27 ID:???

filezillaはダブルクリックでアップロードになってしまう動作が嫌で使わなくなった。
今はどうなのか知らない。

960 ：nobodyさん：2009/03/17(火) 11:59:44 ID:???

調べてみたが、ローカル・リモートでのフォルダの同時移動機能がついたのはごくごく最近じゃないかｗ
そりゃ今までユーザも増えんわなｗ
画面がごちゃごちゃしてるのもすっきりさせることもできるみたいだし、結構良さそうだね

961 ：nobodyさん：2009/03/17(火) 12:04:48 ID:???

昔はそんなに種類もなかったからよくわからない人がFFFTPをすすめてたりしてたんだよ
今は時代が変わってるから国産FTPソフトより外国製のほうが優れてるのは認めざるを得ないんだよ
国産FTP作者も頑張ってもらいたい

962 ：nobodyさん：2009/03/17(火) 12:06:54 ID:???

え？ｆｆｆｔｐでもいいじゃん
たまにＤＯＳ窓使うけど

963 ：nobodyさん：2009/03/17(火) 12:13:11 ID:???

Microsoftは、ASP.NETをオープンソース化＆全部無料にしたら巻き返せると思います＾＾

964 ：nobodyさん：2009/03/17(火) 14:03:29 ID:???

巻き返せるも何も、金の掛けられる案件なら、普通に普及してるから。Oracleだって。

965 ：nobodyさん：2009/03/17(火) 14:25:00 ID:???

aspの利点なんてないじゃん
全部perlとphpに負けてる

966 ：nobodyさん：2009/03/17(火) 14:32:10 ID:???

クローズされてるがゆえのメリットもあるのよねえ

967 ：nobodyさん：2009/03/17(火) 14:47:01 ID:???

>>965
IDE(Visual Studio)
Vs.Phpも使ってるけど、型がカッキリしている.NET用言語に比べたら
インテリセンスの性能が格段に違う。

968 ：nobodyさん：2009/03/17(火) 15:51:44 ID:???

フリーウェアを嫌がるクライアントも現存するしな。

969 ：nobodyさん：2009/03/17(火) 15:58:07 ID:???

ASP.NETって、中身の言語はVB？C#とかもいけるのかな
主に使われてるのは何だろう

970 ：nobodyさん：2009/03/17(火) 16:14:36 ID:???

>>969
C#でもおk
apache+mod_monoでもおk。

ただ、ASP.NETの考え方がなれなくてPHPメインでやってる。
普通にテンプレートエンジンに変数を渡していって
はき出してくれるような仕組みにならないのかしら。
きっとそうすることも出来るのだろうけど、深く調べてない。
Smarty互換のテンプレートエンジンがあったら、
PHP捨ててASP.NETに行くかも。

971 ：nobodyさん：2009/03/17(火) 17:56:48 ID:???

どういう受け渡し方なの？

972 ：nobodyさん：2009/03/17(火) 18:39:52 ID:???

>>971
>>970は漠然と理想を述べてるだけだと思う。
テンプレートはWebProgにおける鬼門の１つなので、
理想的な実装方法があれば誰かがとっくに実装してるはず。

テンプレートに直接変数名書いたものを動かしたいなら
テンプレートをevalするラッパーを書けばいい。
ちょっとした仕事をする時に案外重宝する。

973 ：nobodyさん：2009/03/17(火) 20:24:34 ID:???

これまでのASP.NETはいわゆるポトペタで作るタイプで、これはこれで有効なんだけど、PHPしか使ったことがない（というか、ウェブアプリしか作ったことがない）開発者には違和感があったとともう。
で、ASP.NET MVCっていう、フレームワークが今出てきてて、これは普通のと言うか、PHPとかPerlのウェブフレームワークを使う感覚に近い。

974 ：nobodyさん：2009/03/17(火) 21:36:02 ID:???

価格コムも魔法のiらんどもIISでクラックされたのに良く使う気になるな。

975 ：nobodyさん：2009/03/17(火) 21:36:13 ID:???

.aspや.aspxのサイトはほとんどが重いのだが、
.NETな奴らが技術力ないだけなのか？
単純にフレームワークに頼りすぎなのか？

976 ：nobodyさん：2009/03/17(火) 21:40:54 ID:???

10万件だか漏洩してクレジット提携止められたサウンドハウスも
ASP.NETじゃなかったっけ？
JScript吐き散らかしてたような気がする。

977 ：nobodyさん：2009/03/17(火) 23:04:56 ID:???

ASP.NETはイベント駆動にするために、
なんとも気持ち悪い動作してたりするのが好きにはなれないなー
作る側の利点はあるけど、使う側からしたら何やってるかわかりにくくて
ユーザ側視点でみると(個人的に)信用しづらいサイトが出来上がること多いし

まぁ好みの問題だと思うけど
HTMLソースとか外に出す部分はそれなりにきれいに纏めたいと
感じてしまう人には向かないとは思うｗ

978 ：nobodyさん：2009/03/17(火) 23:10:55 ID:???

クラックされまくりのアスプなんてマゾしか使わない

979 ：nobodyさん：2009/03/17(火) 23:24:25 ID:???

ASP.NETで作ったアプリがクラックされているだけで、
ASP.NETがクラックされているわけじゃない。

「SQLインジェクションされまくりのデータベース」
といってるのと同じくらい間抜けなこといってんぞ。

980 ：nobodyさん：2009/03/17(火) 23:29:19 ID:???

詭弁乙
俺ぁアスプ使うくらいならPHP3使うね

981 ：nobodyさん：2009/03/17(火) 23:32:08 ID:???

まぁ、.NET+IISを使ってるところが狙われやすい
＝よくわかってない奴が作ってて穴が多い、ってのは
少なからずある気はするけどな
うちとこも.NET+IIS+Oracleなんていうある意味鉄板な感じだけど
最近入社したばかりのド素人な俺が見ても
できがいいとは言いがたいもの作ってるしな…ﾊｧ

982 ：nobodyさん：2009/03/17(火) 23:34:35 ID:???

いや、詭弁ではないだろｗ
よくわかってない客みたいな素人相手に言うなら
IISはクラックされまくりとかASP使うと情報漏洩しやすい
みたいなギャグみないな話でもすごく効果あるとは思うけどｗ

983 ：nobodyさん：2009/03/17(火) 23:44:20 ID:???

環境の安全性という観点で言えば、PHPもASPも目糞鼻糞だろ。

984 ：nobodyさん：2009/03/18(水) 00:24:27 ID:???

価格とかのクラックはアプリじゃなくてシステムレベルの話じゃないのか
MHTMLの脆弱だからWindows自体の穴だよ

985 ：nobodyさん：2009/03/18(水) 00:33:36 ID:???

誰も頼んでないのにいらんことして穴を増やす、M$のいつものお家芸なのかな

986 ：nobodyさん：2009/03/18(水) 01:58:58 ID:???

そのとおりでございます

987 ：nobodyさん：2009/03/18(水) 03:40:45 ID:???

適度に定期的に穴を作ってセキュリティ技術者の雇用を創出するのが使命

988 ：nobodyさん：2009/03/18(水) 18:21:40 ID:???

テストってぶっちゃけassertTrueだけで事足りるよね

989 ：nobodyさん：2009/03/18(水) 19:33:31 ID:???

>>980
ｐｈｐ３（笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑
つかってらぁ＾＾

990 ：nobodyさん：2009/03/19(木) 03:26:19 ID:???

使ってるなんて誰も言ってないだろw

991 ：nobodyさん：2009/03/19(木) 19:09:23 ID:???

PHP4対応のフレームワークって、流石にもう需要減ってるよね。
CIも、Kohanaみたいに書き直す流れってある？

992 ：nobodyさん：2009/03/19(木) 19:57:51 ID:???

> PHP4対応のフレームワークって、流石にもう需要減ってるよね。

それをいうのなら、「フレームワークのPHP4対応」だろ？
別に、「PHP4対応のフレームワーク」の需要が減っているわけじゃない。

993 ：nobodyさん：2009/03/20(金) 00:54:38 ID:???

PHP4サポート終わってるから連鯖でもだいたいみんな切り捨て始めてるし
新しいフレームワークがわざわざPHP4に対応する意味はないと思う

994 ：nobodyさん：2009/03/20(金) 07:21:31 ID:???

保守案件は多いから名。