08/02/21 01:23:24
>>74
Scalaをググってみましたが
SCALA:(スカラ)は岡山市のヘアーサロンらしいです
76:nobodyさん
08/02/21 02:54:43
>68
GNOME周りの細かいスクリプトってPythonばっかでしょ？
海外でRuby使っている人ってRoRの流れの人じゃないかな
正直なところ、RoRは偉大だと思うけどRubyはそうは思わない
「RoRのプログラマに選ばれた言語」として評価はするけど
77:nobodyさん
08/02/21 12:49:51
BlenderのPython
Google SketchUpのRuby
PHPをスクリプト言語として搭載した色物3DCGソフトがあったら色んな意味で面白そうだ
78:nobodyさん
08/02/21 13:39:33
将来的にRubyが来るかPhthonが来るかPerlがしぶとく生き残るか。
ずぅっと混戦状態な気もするけど。
案外Webだけに的を絞ったPHPが一番長生きだったりしてね。
でも10年後、PHPの役目が今のCOBOL的な負の遺産管理とか、そういう生き残りかたはやだな。
79:nobodyさん
08/02/21 14:20:40
結局phpもjavascriptやperlみたいに上級者と初心者が乖離して
その間を埋める新しい言語が出てくるんじゃないの
一方extract($_POST);的なコードはいつまでも再生産されるっていう
80:nobodyさん
08/02/21 16:47:46
PHPからPython使えてRuby脂肪ｗｗｗ
URLﾘﾝｸ(pecl.php.net)
81:nobodyさん
08/02/21 18:22:05
マッツがむかつくから今までRubyしなかったけど
外人が大量にやってるからRuby始めました
YAMLが簡単に扱えてｲｲ(･∀･)！
82:nobodyさん
08/02/21 18:47:15
>>81
これよりも簡単に扱えるん？
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
PHP版がこのコード↑として、Ruby版はどういうコードなん？
83:nobodyさん
08/02/21 19:00:50
require 'yaml'
file_dir = './hoge.conf'
str = open(file_dir).read()
data = YAML.load(str)
こんなん
もっとキレイに書けるのか知らないけど。
コード自体はたいして変わらないか。
でも変なパースされてハマったことあるからspycにはいい印象ないな
84:nobodyさん
08/02/21 19:09:48
ってか、やっぱり標準で装備されてる安心感が大きい
85:nobodyさん
08/02/21 19:19:43
じゃあ、YAMLが簡単に扱えるじゃなくて、
YAMLライブラリが標準添付されているって言うべきだな。
86:nobodyさん
08/02/21 19:23:34
ある文に後から関数的な処理を加えたい時、PHPだと
[追加部分前半](元の文)[追加部分後半]
って分かれるのが普通だけど
Rubyだと
（元の文）[追加部分]
で済むのが気持ちええ～
多重に追加する時も
（元の文）[追加][追加][追加]
って書いていけるのがオルガスムス(´ρ｀)
87:nobodyさん
08/02/21 19:40:27
ここRubyスレじゃないんだ。わかってる？ｗ
88:nobodyさん
08/02/21 19:43:13
関数塗れな処理で、カッコでgdるかドットシンタクスで繋げられるかって事か
地味だがjQueryハマってるので気持ちは判る
しかしスレ違いではないか
89:nobodyさん
08/02/21 20:06:49
すぐスクリプト言語についてぬるく語るスレになるなここはｗ
よっぽどPHPのフレームワークにネタがないのか
90:nobodyさん
08/02/21 21:58:56
他言語も含めてフレームワークでネタが続いているの
どこにあるんだよｗ
91:nobodyさん
08/02/22 09:46:47
>>59
>URLﾘﾝｸ(www.timestretch.com)
>
>ここの結果だとPythonの方が速いけど。
>まあ、当たり前だけど目的による。
>なんで盲目的にPerlが速いといえるのかがわからん。
>>49と>>52よく読め。起動時間の話をしてるのに違うベンチマーク結果だしてどうする。
>>82
SpycはまともにYAML扱えないから止めた方がいい。いくらなんでも機能低すぎ。バグ大杉。しかもクソ遅い。
92:nobodyさん
08/02/22 12:35:59
PHPもYAMLパーサ標準装備されるんじゃなかったっけ？
93:nobodyさん
08/02/22 12:47:30
まじで？早くしてほしいね
94:nobodyさん
08/02/22 15:13:53
Symfonyでふんだんに使われているSpycが
そんなに悪いとは思えないが？
95:nobodyさん
08/02/22 15:16:53
Pieceでも前提にしてるね Spyc
96:nobodyさん
08/02/22 15:19:12
いままで parse_ini_file も有効利用出来なかったPHPerがYAMLってだけで何でそんなに騒ぐのか
97:nobodyさん
08/02/22 15:25:54
spycは単純な設定ファイルを読む程度なら充分だけど、
ヘビーに使おうと思うとあきらかに役者不足だよ。
98:nobodyさん
08/02/22 15:37:27
取り立てて良いわけでもないが、まともにyaml扱えないなんて印象はないけどな
だいたいyamlなんて設定ファイルで使うケースがほとんだと思うが
遅いって言っても実環境で使うなら普通キャッシュするし
機能低いとかヘビーに使うとか一体どういう局面で困ってるの？
99:nobodyさん
08/02/22 16:34:52
YAMLってヘビーに使うものなのか？
通常は設定ファイル程度に使わないか？
そういうのは一度キャッシュしてしまうだろうし。
（ってろく読まずに書いたら>>98も同じこといってるじゃんｗ）
100:nobodyさん
08/02/22 17:13:10
YAMLのパース処理なんて単純だし固定的だからエクステンションにするのがベストだろうな
symfonyってsyckとかいうの使うようになったんじゃなかったけ？
101:nobodyさん
08/02/22 17:18:54
>91
いや、起動が遅くてもインクルードで遅れたら意味ないでしょ？
だから、「目的による」と書いてあるの。それ以上は自明だと思ったから説明しなかっただけで。
それについては、Perlでもインクルードするモジュールによると他の人も書いてるでしょ。
この人は意図をよく理解してる。あなたはもう少しよく考えましょう。
102:nobodyさん
08/02/22 17:31:08
web+db press ちょうどyamlについての特集してるな
web+db pressの個人的タイムリー感は異常
103:nobodyさん
08/02/22 17:33:55
「起動が遅くてもインクルードで遅れたら」ってどゆこと？
「起動が速くてもインクルードで遅れたら」のtypo?
104:nobodyさん
08/02/22 18:29:49
>>101
>いや、起動が遅くてもインクルードで遅れたら意味ないでしょ？
>だから、「目的による」と書いてあるの。それ以上は自明だと思ったから説明しなかっただけで。
起動の速さを話題にしているんだから、それ以外の要素を持ち出すならそれを説明すべきだろ。
>>49,52,59を順に読んでみろ。どこにインクルードやrequireの話がでている?
「目的による」のひとことで分かるわけがない。おまえの脳内で勝手に補完するな。
>それについては、Perlでもインクルードするモジュールによると他の人も書いてるでしょ。
それは>>60からだろ。60はちゃんと説明しているが、59まではそんな話でてきてない。時系列を無視して語るな。
>この人は意図をよく理解してる。あなたはもう少しよく考えましょう。
おまえこそもう少しよく読め。
105:nobodyさん
08/02/23 21:58:54
web+db press読んだ
YAMLって結構高機能なんだな～
106:nobodyさん
08/02/24 09:22:41
ワロタｗ 高機能の内容も言わず、高機能とか言っても信用されないｗ
107:nobodyさん
08/02/24 11:54:48
信用って何だよ
仕様を見ればわかるがな
108:nobodyさん
08/02/24 19:48:11
最も使われているYAMLパーサのSyckはRuby出身
Rubyの手のひらの上で暴れてるだけのPHP乙
109:nobodyさん
08/02/24 20:10:52
最も使われてるの？
PHPのプロダクションてほかの言語からの輸入物多いからいまさらそんなん言われても
110:nobodyさん
08/02/24 23:46:30
PHP＝ポリシーのないパクリパッチワーク言語でおk？
111:nobodyさん
08/02/25 00:58:06
>>110
そう書くと、それはそれでとても魅力的な言語に見えます。
112:nobodyさん
08/02/25 03:41:00
PHPにいいとこどりされて他の言語脂肪ｗ
113:nobodyさん
08/02/25 10:52:39
最近、Ruby本多くなったけど誰がRuby使ってんの？
114:nobodyさん
08/02/25 14:43:04
異教徒
115:nobodyさん
08/02/26 00:07:04 /Sycx4p+
言語崇拝者でしょ。
116:nobodyさん
08/02/26 00:42:37
なぜ島根県が出て来ないのだ
117:nobodyさん
08/02/26 02:09:18
おまいらＰＨＰ，ｐＨＰていうどやなあ
今までＰＨＰでいくら稼いだんや？
118:nobodyさん
08/02/26 02:10:31
松本は島根県民としては誇りだ
しかしネゴシックスは県民の恥さらし
119:nobodyさん
08/02/26 02:13:42
世界に通用する言語開発した唯一の日本人が
島根県民だから同県民として素直にうれしいし
松本も地元に愛着を持ってるらしく
Ｒｕｂｙ検定やら松江を発信基地として活動してくれる
120:nobodyさん
08/02/26 02:15:05
島根県民は案外、人口の割りに頭のいい奴は多いぞ
121:nobodyさん
08/02/26 02:39:30
頭は良いが、常識はないってパターンか
いい加減書き込むときはスレタイぐらい読めよ
122:nobodyさん
08/02/26 08:59:32
Rails使いたくてこの1ヶ月Ruby勉強してた
確かに書きやすいしPHPに比べるときれい
でも肝心のRails環境があまり無い
実用面ではPHPがNo.1だと思います
それで質問ですが、最もRailライクなフレームワークはSymfonyでよろしいでしょうか？
この1ヶ月の勉強の知識でそのままPHPフレームワークに移行したいのです
123:nobodyさん
08/02/26 16:01:26
>>122
>それで質問ですが、最もRailライクなフレームワークはSymfonyでよろしいでしょうか？
YES
>この1ヶ月の勉強の知識でそのままPHPフレームワークに移行したいのです
その判断は誤りだといっておこう。
PHPはRubyと比べてできないことが多いから、PHPでRailsを真似てもたいしてうまくいかない。
124:nobodyさん
08/02/26 20:24:36
>>123
具体的に何が出来ないんですか？
125:nobodyさん
08/02/26 20:29:50
>>124
簡潔な記述、とかかなぁ
126:nobodyさん
08/02/26 20:38:57
( ´д`;)…
127:nobodyさん
08/02/26 21:49:40
>>122
akelos
128:nobodyさん
08/02/26 22:30:12
>>122
Railsに最も近いのは、現状でいえばakelos
でも、Railsがベストなわけじゃないってのは認識したほうが。
symfonyはRailsよりリッチ。いい意味でも悪い意味でも。
129:nobodyさん
08/02/26 22:47:06
そりゃどちらがrailsクローンかと言われると
akelosだけど現実的に考えるとsymfonyだろう
リッチってなんだよリッチって曖昧過ぎるだろ
130:nobodyさん
08/02/26 23:46:19
リッチかどうかは良くわからないけど、
symfonyの方がエンタープライズ向けな感じはする。
131:nobodyさん
08/02/26 23:56:03
>>124
簡潔な記述もそうだけど、PHPはメタプログラミングが弱いんだよ。
Rubyはそこが強力で、だからこそActiveRecordみたいなのが実現できる。
ActiveRecordがほんとに望ましいものかどうかは別として。
132:nobodyさん
08/02/27 00:00:57
PHPユーザーはPHPだけで何もかもこなそうとする傾向にある。
133:nobodyさん
08/02/27 00:03:44
今は亡き？Plaggerよりは、何でも出来るけどなｗ
134:nobodyさん
08/02/27 01:13:23
>>131
PHPの言語仕様がRubyよりも少ないのはわかるけどさ、
それで開発をする上で何ができないということなの？
135:nobodyさん
08/02/27 09:17:34
>>133
Plaggerをここで出す意味がわからない。
スペルの似た別の何か？
136:nobodyさん
08/02/27 09:27:49
>>129
akelosも十二分に実用だと思うよ。
ｽﾚﾘﾝｸ(php板)
URLﾘﾝｸ(www.akelos.org)
URLﾘﾝｸ(www.akelos.org)
URLﾘﾝｸ(blogs.atanaka.biz)
URLﾘﾝｸ(blog.takeda-soft.jp)
URLﾘﾝｸ(blog.hakuja.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
137:nobodyさん
08/02/27 21:44:16
Railsでこのまま行くか、PHPのフレームワークを覚えるか迷うな・・
akelosは>>136の上から5番目のブログ見て良さげと思った
138:nobodyさん
08/02/28 13:46:19
俺のフレームワークの使い方
・RDB使わずテキストの場合
ちいたん（ちょっと改造）
・PHP4でRDB使う
ちいたん（ちょっと改造） + PieceORM
・PHP5でRDB使う
symfony
こんな感じ
139:nobodyさん
08/02/28 13:51:16
php4かphp5かとか言ってるさなか今時３かよ。
キツい・・。perlにするかな。
140:nobodyさん
08/02/28 17:43:37
PHP3とかいっている環境しか使えない状態なら
その環境のPerlも当然バージョンが古く、
そのバージョンのPerlに対応しているフレームワークも無い。
141:nobodyさん
08/02/28 19:01:25
>>134
Railsはどうか知らんが、RakeはPHPじゃ無理だと思った。
142:nobodyさん
08/02/28 19:18:01
>>141
pakeがあるし、普通に雑務タスク書く分にはpakeでもわりと使えるよ
まあrakeみたいにDSLっぽく書けない、という意味で書いてるんだろうけども
143:nobodyさん
08/02/28 19:27:24
言語仕様が劣っていても、それをライブラリ・フレームワークとして
提供すれば、ほぼ同等のことが出来る。
違った形での実装、使い方になるだろうが、どちらを使っても
普段の仕事で使う分には大差がない。
大差があれば、われわれは○言語を使うから、
大幅に工数が減って、結果、”安く”作れます。といえるはずだろう？
安く作るって事は給料が減るわけだが、本当に工数が減るのなら問題ないはずだ。
実際は工数が減らないから「優れた言語を使うから安く作れる」なんて話を聞いたことが無い。
144:nobodyさん
08/02/28 20:48:04
>>143
どちらを使っても大差がないんだと思うなら
優れた言語使えばいいんじゃないのと思うがｗ
相手も同種のベンダーとかじゃない限り、
顧客にとっちゃどんな言語使ってようがあまり関係がない
「われわれは○言語を使うから云々」とか意味不明
安いのどうのっていうのは見積判断次第なわけで
工数とコストが比例するのが前提っておかしいだろう
145:nobodyさん
08/02/28 20:53:41
「優れた言語」の定義も曖昧なまま、意味の無い話をしている人たちが気持ち悪い。
146:nobodyさん
08/02/28 20:54:47
>>144
＞工数とコストが比例するのが前提っておかしいだろう
上記の「コスト」は見積もり、のこと？
この業界の最大のコストは人件費なんだから、コストは素直に比例でいいんじゃね？
まあ商用パッケージ等を使うこととかは別問題だけど、それでも「工数」を比較的上手に
コストと交換しているみたいなもんだし。
まあ、見積もりは別だ。 ・・・でもあんまり無茶なダンp(ry
147:144
08/02/28 21:09:31
>>146
コストじゃねー見積orz
工数とコスト（経費）が比例しなかったらまずいｗ
俺が意味不明だった
内部的な工数の変化と外部への見積とはまた別だろう的な
意味で書いたつもりだったけど変な文章になってた
148:nobodyさん
08/02/28 22:37:10
プログラマの言うすぐれた言語を使っても、
フレームワークを使うと、工数も作りやすさも変わらない罠。
なぜかというと、フレームワークを使うとビジネスロジックに専念できる。
そのビジネスロジックでは高度な言語機能なんて使わないから
149:nobodyさん
08/02/28 23:57:02
もともと SIerが作るシステムなんて仕様が汚いんだから、きれいに書ける仕組みがあっても意味がない。
それどころか、コピペで作られたシステムじゃないと、修正した場合の影響範囲が大きくなるから嫌がられる。
変更箇所が多くても土方仕事の方が良いというプロマネは多いはず。
土方仕事なんだから、職人技が使えないのは当然。
150:nobodyさん
08/02/29 02:19:49
Perl5.6は2000年リリースだけど、使えないCPANモジュールなんて数えるほどだと思うよ。
それどころかPerl5以降なら、たいていそのまま動くよ。15年前のリリースだけど。
151:nobodyさん
08/02/29 10:50:18
バージョンあがってないんだから当然だろ
152:nobodyさん
08/02/29 12:09:50
Railsがいずれ主流になるのは確信してるが
まだまだ時期が早い。
symfonyだよな、
春くらいに大手サイトでのsymfony採用実績がどんどん発表されるのを
知ってる人は少ないだろうな
153:nobodyさん
08/02/29 12:11:59
大規模で使えるフレームワークで考えれば
長い期間でsymfony独占だろうな
規模でかいフレームワークが乱立することは、マズ無い
会社を上げてその競争に入るのに多大なコストがかかる
154:nobodyさん
08/02/29 13:21:45
>>153
>大規模で使えるフレームワーク
これってなにをもってそういってるの？
大規模って何が大規模？大規模向けにsymfonyがもっていて他がもっていない特徴って何？
155:nobodyさん
08/02/29 15:41:39
あちこちでsymfonyほめ殺しやってるのはsymfonyアンチなんだろうなあ
なにかアンチをひきつける要素があったのか
156:nobodyさん
08/02/29 18:20:40
>>154
ここでいう大規模てのは人それぞれだからね
あえて俺が境界定義する必要はない
大規模に向けにある機能といったら
Viewからコンポーネント、モデルに手軽にアクセスできる柔軟性
157:nobodyさん
08/02/29 18:24:46
スケールしやすいとかそういう事言うのかと思ったら
えらく特化された大規模向け機能だな
よっぽど小回り利かないFWを使ってるのか
158:nobodyさん
08/02/29 18:26:58
多分 >>154 が言いたかったのは、「規模」は利用者数なのか、プログラムの大きさなのかって事じゃないかと思うんだが。
159:nobodyさん
08/02/29 19:55:13
>>158
あとは開発者数ってのもある
>>156
>Viewからコンポーネント、モデルに手軽にアクセスできる柔軟性
これもうちょっと詳しく説明できる？どんな機能で、どう大規模な開発で便利なのか。
160:nobodyさん
08/02/29 20:10:06
>>156
＞Viewからコンポーネント、モデルに手軽にアクセスできる柔軟性
具体的に想像出来ないが、Viewからとりあえず Hoge::new とか Hoge::factory とか Hoge::singleton とか
Hoge::getInstance とかであらゆるオブジェクトを気軽に作成できて、またそうするのが前提で、みたいな？
すっごくネガティブな方向でしか想像できない。
なんか、上の方とか他に影響のありそうな所とかをいじらなくて済むから、お伺いを
立てずにとりあえず現場でなんでも出来る、うーん効率的、などなど
直行性を高く保って実現する、ていうことなのかな？DRYはある程度犠牲にして、ていう？
なんかふわふわｽﾏｿｗ
161:nobodyさん
08/02/29 20:57:56
ビューごときが直にモデルにアクセスしたいなんて思い上がりすぎわろた
コントローラー様を介せよｶｽ
162:nobodyさん
08/02/29 21:05:30
コントローラを経由すると何が良いの？
163:nobodyさん
08/02/29 21:12:31
>>156
少し考えたが、Ethnaみたいになるのか？
どのオブジェクトもあらゆるオブジェクトを持ってるみたいな
Ethnaはもう循環参照で開き直ってるけどｗ
$this->af->ae->af->ae みたいな （← これはなかったかもｗ）
もしくは$this->backend->(永遠に続くオブジェクトループ) みたいな
っていうか、backendの範囲広すぎｗ
そこまでするんなら、もうオブジェクトそれぞれ$GLOBALSに置いておいて
変更は禁止で（変更するならcloneでもして）勝手にアクセスすればいいん
じゃね？とかいう気がすごくする。
164:nobodyさん
08/02/29 21:34:21
>>151
は？5.8、5.10とリリースされてるんだけど。PHPみたいに0.1のバージョンアップでもう動かなくなる方がどうかしてる。
PHPの場合、間違いなくPHP4系、PHP5系、PHP6系が平行して使われていくだろう。
165:nobodyさん
08/02/29 22:14:57
4は使われねーだろ
166:nobodyさん
08/02/29 23:02:18
symfonyはVからコンポーネントにアクセスする場合
CとVがワンセットでコンポーネントされてる場合
コンポーネントで定義されてるV切り離してCだけ呼ぶことも出来るし
CとＶをワンセットで呼ぶことも出来る
この辺り便利
167:nobodyさん
08/03/01 00:01:06
>>166
その説明じゃわからん。特に1行目と2行目。
コンポーネントされてる場合ってなんのことだ
CとVをワンセットで呼び出すってどういうことよ
168:nobodyさん
08/03/01 00:45:22
適当につけているバージョン番号の数値に
意味を考えるなんて馬鹿だよな。
169:nobodyさん
08/03/01 14:08:24
===がRubyでは範囲比較演算子として使われててPHP脂肪ｗｗｗ
170:nobodyさん
08/03/01 23:54:17
小中規模フレームワーク Akelos
大規模フレームワーク symfony
CakePHPは作者がバカそう
171:nobodyさん
08/03/02 01:01:22
一番はやっているものに、嫉妬して
悪口を言う気持ちは、わかります。
172:nobodyさん
08/03/03 17:23:19
URLﾘﾝｸ(slashdot.jp)
日本PostgreSQLユーザー会のWebページがクラックされてPHP脂肪ｗｗｗ
173:nobodyさん
08/03/03 18:05:14
スレ違い
174:nobodyさん
08/03/04 00:15:16
PHP5.3は正式にはいつリリースされるの？
名前空間が入ることはもう確定っぽいけど、そういうのを使ったフレームワークとかはいつ頃出てくるんだろうか
普及すれば、フレームワークの書き方が思いっきり変わりそうな機能だけど、まだしばらくはお手本とかなさそう？
175:nobodyさん
08/03/04 02:04:28
あんまりかわんないと思うけど。
176:nobodyさん
08/03/04 03:18:14
PEARみたいな外部ライブラリは充実するかも。やっとスタートラインに立つってだけだけど。
177:nobodyさん
08/03/04 14:37:23
独自拡張を、下の方の継承ではなく、上の方の差し替えで出来る可能性はあるかも？
// import Zend::DB as DB
import MyFramework::DB as DB;
$table = new DB::Table();
として差し替える、とか。配布スクリプトがカオスになる可能性もあるな
178:nobodyさん
08/03/04 18:08:54
名前空間とかgotoとかどうでもいいしね…
個人的にはicuがどうなるかだな
まぁ時代はqiqってことで
179:nobodyさん
08/03/04 20:48:12
qiqはもちろんすげーけど
gotoと名前空間を同列に語るなよ
程度が知れるぞ
180:nobodyさん
08/03/04 21:32:54
qiq見てみたけどすげーじゃん。phpに不足していると指摘されている機能がもう実現できてんじゃん。始めて知った。
181:nobodyさん
08/03/04 21:45:54
？？？
無名関数・クロージャ・配列の構文糖衣 が主な拡張？
そんなに欲しかったのか？
182:nobodyさん
08/03/04 21:49:23
じゃ他に何が必要なん？
183:nobodyさん
08/03/04 22:06:37
namespace
184:nobodyさん
08/03/04 22:07:34
列挙型とかクラスの動的な再定義とかモジュールのmixinとか
・・・って別にいらないと言えばいらないし、むしろ必要なのは標準ライブラリかな
いい加減、メール送信とかDBアクセスとかに外部のライブラリをいちいち吟味って
結構めんどい。さっさと標準で十分にするんだ。
Zend Framework付属のライブラリ群がそうなる予定なのかも知れないけど、そうすると
PEAR2の立ち位置が微妙になるし。
PEAR2にZend Frameworkからのバックポートがあるんなら、それが良いのかも知れない
185:nobodyさん
08/03/04 22:52:02
名前空間やパッケージを今更導入しても、PEAR、Zend、各種フレームワーク付属のライブラリの整合性を取るのは至難だろうな。PHP4.0程度で導入すべきだった。
186:nobodyさん
08/03/04 23:05:45
いや、やっとPHP4が死んでくれたので、これからPHP5（の記述）に移行する腰の重ーい
人たちや企業がまた慣れて旧態依然としたコードを乱発してしまう前にがんがん新機軸を
入れてしまえっていう、最後の機会かも知れない
187:nobodyさん
08/03/05 02:03:59
PHP4で動いているサイトは星の数ほどある。今動いてるサイトは、今後PHP4で動き続ける。機能追加もされていく。互換性のないPHPだから仕方ない。
188:nobodyさん
08/03/05 02:11:31
トリッキーなことしてなかったら4のサイトも5で普通に走るだろ…常考
189:nobodyさん
08/03/05 03:29:57
いやあ屑コード依存が多岐に渡ると作り直すぞ
俺が体験した範囲だと、4→5よりも古い4とlatestの4の間でコケて
5+ZFで作り直しってのがこの所多発
190:nobodyさん
08/03/05 04:22:14
多発ってどんだけ。
191:nobodyさん
08/03/05 07:13:06
クラスで3人くらい持ってたら「みんな持ってる」と言ってしまう
子供と同じ心理
192:nobodyさん
08/03/05 11:55:03
まぁ XPからVista並には移行するんじゃなかろうか。
193:nobodyさん
08/03/05 15:30:39
>>190
先月七回きたよ
194:nobodyさん
08/03/05 19:36:02
そんなあるのか
195:nobodyさん
08/03/05 20:10:34
あ、同じクラからだけどね
別案件でばらばら投げられて苛々したけど、ZFでやれたので最終的にDB一本化はけっこう綺麗にいった
運用ベースで見たら古い環境って相当な数居るように感じるのよね
問題でない限り使い続ける（というかリプレースする理由がない）もんだし
196:nobodyさん
08/03/05 23:07:01
そりゃ問題ない物までリプレースする必要はないが、
古い４って脆弱性問題にならなかったのか
197:nobodyさん
08/03/05 23:16:55
最新版のPHPは機能が多くなった分、もっとセキュリティに問題あるから。枯れてるPHP4の方がよほど安全。
198:nobodyさん
08/03/05 23:20:10
新しい４、なら気持ち同意
199:nobodyさん
08/03/07 02:17:48
PHP本体のセキュリティをちゃんとソースコード読んだ上で語ってる奴ってどんだけいるんだろうね。
200:nobodyさん
08/03/07 04:59:46
>>199
suhosin乙
201:nobodyさん
08/03/07 09:49:44
Windows本体のセキュリティをちゃんとソースコード読んだ上で語ってる奴ってどんだけいるんだろうね。
Windowsのセキュリティを語っているやつ死亡ｗｗｗ
202:nobodyさん
08/03/07 10:01:43
>>201
オープンソースのWEBフレームワーク言語と、ソースの秘匿されている商用OSを同列に並べるのは
ちょっと無理があるんじゃね？
せめてLinuxにしとけよ
203:nobodyさん
08/03/08 02:20:42
>>197
ですよね。
WindowsもVistaなんかより枯れてるNTですよね。
204:nobodyさん
08/03/09 02:17:33
Ruby書き慣れたらPHPの行末の;を書き忘れるなぁ
従ってPHP脂肪ｗｗｗ
205:nobodyさん
08/03/12 03:50:21
>>86
URLﾘﾝｸ(jp2.php.net) ?
206:nobodyさん
08/03/13 02:05:36
>>204
俺も、VBやっていたら、C言語の行末の;忘れたよ。
なんか似てるね。
207:nobodyさん
08/03/13 03:53:53
rubyって
if (式) {hoge()}
みたいな書き方出来ないのな
ブロック付きメソッドでは{}を使うのにifで{}使えないって何なの？
208:nobodyさん
08/03/13 04:08:48
>>207
その {} を then end に変えるだけなんだがな
何なのって言われると、文法としか言いようが無さそう
PHPって hoge() if (式) って出来ないのな、ってなもんだ
MLで聞けばひょっとするとMatzが答えてくれるかも知れないよ
ってか、スレ違い
209:nobodyさん
08/03/13 04:17:52
何で一貫性がないの？Matzは美意識が欠けてるの？
210:nobodyさん
08/03/13 07:21:58
URLﾘﾝｸ(blog.pasonatech.co.jp)
Matz & Dan : コンピュータサイエンスとしての知識が高まると
PHPに対して不満がでてくるかもよというのは予言しておきます（笑）
PHPER=コンピュータサイエンスとしての知識が低い人ｗｗｗ
211:nobodyさん
08/03/13 10:49:22
>>207
if文はブロックじゃないから
ブロック付メソッドはブロックを伴うから
212:nobodyさん
08/03/13 11:00:47
>>210
お前、読解力ないのな・・
213:nobodyさん
08/03/13 17:36:30
>>212
それ以外のどんな解釈があるんすかｗｗｗ
214:nobodyさん
08/03/13 18:49:20
いい加減あぼーん機能使おうよ
215:nobodyさん
08/03/13 20:53:17
>>211
一文ならブロックじゃないけど
複合文ならブロックじゃん
216:nobodyさん
08/03/13 21:40:53
>>215
違う
if文はrubyでいう意味の「ブロック」じゃない
rubyのifやwhileやforはスコープを持たない
だからdo～endの代わりにブレスが使えない
eachのようにブロック付き呼び出しで使うのがブロック
こちらはブロックスコープを持つ
217:nobodyさん
08/03/13 23:01:09
変な文法の言語は流行らない法則
218:nobodyさん
08/03/14 05:52:57
>>216
Rubyにおいてはブロック付メソッドが例外で
それ以外ではカーリーブラケットは使わないってことか
Cに喧嘩売りすぎワロタ
219:nobodyさん
08/03/14 16:06:52
PHPフレームワークとの組み合わせでおすすめのアクセラレータは何です？
220:nobodyさん
08/03/14 16:16:37
zend
221:nobodyさん
08/03/14 17:48:44
zendオプチマイザ？
アクセラレータじゃなくね
222:nobodyさん
08/03/14 18:10:09
多言語併用してたら関数とかメソッドまじ忘れてくるな
すべての言語が統一されればいいのに・・・
223:nobodyさん
08/03/14 18:41:06
すぐリファレンスできる言語ならどうでもいいよ
バッドノウハウ頼みな制限や変態仕様が全ての言語から根絶されたら素敵だろうなあ
224:nobodyさん
08/03/14 18:44:08
javaとphpでプロジェクトたらい回しされる・・。
225:nobodyさん
08/03/14 18:44:37
PHPが滅べばいいだけじゃないの？
226:nobodyさん
08/03/14 18:51:29
>>225
そうなっても別にJavaに統一されるわけでもないんじゃね？
227:nobodyさん
08/03/14 21:58:17
Perl=信長
PHP=光秀
Python=秀吉
Ruby=家康
PHPERﾃﾗ三日天下ｗｗｗ
228:nobodyさん
08/03/14 22:01:10
>>227
他はともかく、Ruby=家康 だけはあり得ないｗ
むしろ色物だろ
229:nobodyさん
08/03/14 22:13:19
>>227-228
自演乙
230:nobodyさん
08/03/14 22:25:17
何で自演だと思ったんだろうね
231:nobodyさん
08/03/15 00:01:12
URLﾘﾝｸ(enterprisezine.jp)
PHP＝トラブルｗ
LAMPセキュリティ問題の主犯ｗｗ
人知れずPHP3やPHP4を使い続けているサイトはたくさんｗｗｗ
もはやキリシタンみたいな扱いだな
232:nobodyさん
08/03/15 00:11:35
>>231
URLﾘﾝｸ(blog.ohgaki.net)
233:nobodyさん
08/03/15 00:13:21
>>231
そのサイトはひどい釣りにしか見えんな
確かに、既存サーバのPHPが硬直してしまっているっていうのは必要な指摘だとは思うんだけど、
その書き方が突飛と言うか無理過ぎるというか、とにかく説得力がない
例えば
＞Apacheのmod_phpを使ってPHPをApacheモジュールとして実行すると、Apacheプロセスの
＞すべての資格情報がPHPに引き継がれます
って、SuExec等を使わない限り、Perl、Ruby、Python等のCGIでも同じっていうことに言及しない
のはどうかとも思う。他にもいろいろ、わざとかも知れないけど香ばしい
234:nobodyさん
08/03/15 00:14:31
・・・なんかかぶったｗ
235:nobodyさん
08/03/15 01:27:32
>>230
いつまでも馬鹿相手にする輩なんか本人以外にありえんだろ
236:nobodyさん
08/03/15 08:30:08
ウェブサーバとアプリケーションサーバを別プロセスにした方がセキュアというのは正しいだろう。fastcgiの外部サーバとかJavaみたいに。
237:nobodyさん
08/03/15 16:57:53
最近どこもかしこもやたらSuExecだしなー
238:nobodyさん
08/03/15 17:23:26
suexec導入しようと思ったが
apacheのsuexecの説明見たら
suEXEC の設定には管理者の詳細にわたる慎重な注意が必要
とか書かれてｺﾜｽ
239:nobodyさん
08/03/15 18:23:12
suexecなんか使うくらいならfastcgi使うわ。
240:nobodyさん
08/03/15 18:30:06
suexecって要するにCGIをsetuidされたラッパーを通して実行するもの？
てことはモジュール版のPHPは普通にapacheの権限で実行される？
241:nobodyさん
08/03/15 20:29:23
みたいだね
ってことは、suexecが必要になるのって
不特定多数のユーザにリソースを貸すサーバ屋さんくらい？
242:nobodyさん
08/03/16 00:45:11
だってなぁ、suExecを使わない ということは
ほぼApacheモジュールで動いているのと同じなわけで、
Apacheモジュールで動くということは、Apacheの権限で動いているわけで、
PHPを使えば、Apache権限になれるから、
Apache権限で読み出せる他ユーザーのファイルを読み出せるからな。
243:nobodyさん
08/03/16 21:39:19 9hRtdL6R
include_onceがアクセラレータで使われない問題って
apc.include_once_overrideで解決できるんじゃね？
244:nobodyさん
08/03/16 23:14:35
facebookってPHPなんだな
Ruby脂肪ｗｗｗ
245:nobodyさん
08/03/23 05:33:05
Perl=信長
PHP=光秀
Python=秀吉
Ruby=隠れキリシタンｗｗｗｗｗｗｗ
246:nobodyさん
08/03/23 12:01:53
Ruby=慶次
247:nobodyさん
08/03/23 12:28:04
いずれにしろ光秀のPHPって・・・
248:nobodyさん
08/03/23 15:47:03
mbstring系の設定をPHPのコード中でしてたら、どうも文字化けする。
.htaccessに書いたらしなくなったけど。
mbstring系の設定はphp.iniか.htaccessでするって常識？
249:nobodyさん
08/03/23 16:40:24
みなさんすいません。>>248と同じ会社の者です。
まだ見習い中なのでとりあえずphpに慣れてもらおうと課題を出したのですが、
何日たっても報告にこないのでついさっき報告をあげさせると共に指針を与えた所でした。
mbstringが、mbstringがと、説明が要領を得なくて時間がかかったのですが、
どうやらmbstring.languageをスクリプト中で指定しようとしていたらしく、
マニュアルで確認するように伝え、日々日報に問題点を記述するように厳しく指導いたしました。
今後このような事が無いように指導を行い、
また、ご迷惑をおかけしましたことをお詫び申し上げます。
250:nobodyさん
08/03/23 16:51:02
なんていうか不安でいっぱいな会社だな。まあガンガレ。
251:nobodyさん
08/03/23 19:26:02
常識なの？
誰も言わなかったじゃん
ちゃんと説明しろよ249のハゲ
252:nobodyさん
08/03/23 20:55:07
懐かしいコピペだな
253:nobodyさん
08/03/23 21:23:45
PHPのmb_send_mail()とかクソ過ぎだろ。どうやったらこんな分かりづらいAPI思いつくんだか。
254:nobodyさん
08/03/23 21:39:27
>>253
上の方で出てた
mb_send_mail使う奴はど素人、プロはmailを使うでFA
255:nobodyさん
08/03/23 21:48:36
プロなら直にSMTP
256:nobodyさん
08/03/23 22:31:41
>>255
まあ汎用的ではあるな。一度しっかりとモジュールを作ってしまえばいいわけだし
というわけで、マルチバイトや添付ファイル、HTMLメールにがっつり対応したメールモジュールのある
フレームワークの紹介よろしく！
257:nobodyさん
08/03/23 22:35:47
>>256
あとPOP before SMTP と SMTP Auth にも当然対応しているという奴かな
どこにでも転がってそうだけど、一つばっちりした物があればそれでいいんだし
258:nobodyさん
08/03/23 22:35:49
>>256
Zend
259:nobodyさん
08/03/23 22:47:42
>>258 thx
結局ライブラリの質というか筋がいいとかでいうと、Zendが一番なのかな
260:nobodyさん
08/03/23 22:52:37
そうだね
261:nobodyさん
08/03/23 23:09:14
餅は餅屋なんだからMTAに任せたらいいじゃん
わざわざSMTP叩く奴なんなの？変態なの？
262:nobodyさん
08/03/23 23:32:43
>>261
MTAはMUAの間違い？（sendmailコマンドの様な）
PHPの関数インターフェイス(mail(), mb_send_mail())もMUAと言えなくもないのかな
でも、外部SMTPサーバを使いたい時も同様に扱えるから初めからMTAのサーバを
ソケットから叩くっていうのはそんなにおかしくないと思うけどな
そりゃいちいちpopenとかベタベタでやるのは変態っぽいけど、ライブラリになっていれば
そんなに手間でもないと思うし、PHPの関数叩くのとやってることは大して変わらないと思う
263:nobodyさん
08/03/23 23:39:24
>>262
ソケット通信なら、popenじゃねえな
fsockopenとかそういうのだな。PEARでもいいけど
264:nobodyさん
08/03/24 00:44:07
あー
外部にメールサーバがある場合か
なるほどね
265:nobodyさん
08/03/24 00:53:41
ZFだと確かPOPも扱えたよね。
266:nobodyさん
08/03/24 01:03:45
そうだ。餅は餅屋に任せよう。
んで、sendmailで添付ファイルを送るにはどうすればいいんだ？
267:nobodyさん
08/03/25 15:59:11
餅は餅屋って、sendmailはMTAだから、そのおまけのコマンド起動送信も含めて
添付ファイルを処理させるのはおかどちがいだろう。
まぁ適当にmultipartなメールをでっちあげてください。
>>262
MUAって、MDAが落としたメールとかも読めなきゃいけないんじゃない?
たぶん、あれをMUAとは言わんような...どっちでもいいけど。
どっちも/sbin/sendmailだからややこしいな。
268:nobodyさん
08/03/29 02:49:42
PHP のフレームワーク: 第 5 回 外部タスクを統合する
URLﾘﾝｸ(www.ibm.com)
3大フレームワークでのバッチ処理についての記事。
このシリーズは正にこのスレ向けだね。
269:nobodyさん
08/03/30 17:45:17
フレームワークでは例外がデファクト的に使われてるけど
例外だとApacheのエラーログに残らないのが難だな
フレームワークのログには残るけど。
Apacheのエラーログ見ながらテストってよくやるし、
そこで例外が確認できないのはイケてない。
270:nobodyさん
08/03/30 18:05:39
>>269
FWの一番上層のtry～catchで
error_log($exception->getMessage());
しておけばいい
mod_phpならapacheのerror_logに吐かれる
自分で例外をハンドリングもせずに例外が難だな、とか言われても
271:nobodyさん
08/03/30 19:45:47
>>270
>FWの一番上層のtry～catchで
その部分はFWが提供していて書き換えられない・拡張できない場合がほとんどだろ
自作FWじゃないんだから
272:nobodyさん
08/03/30 19:55:44
例外使わないCIが最強
273:nobodyさん
08/03/30 22:07:54
>>271
FW全域に渡ってのエラーハンドリングできないFWもアレだと思うし
仮にできなくてもブートストラップになるdispatch部分をtry-catchしたらいいし
それもいやならexception_handlerだってあるしやり方はいくらでもあるよ
274:nobodyさん
08/03/30 22:31:58
素直にframeworkのlog見ときゃいいだろ、と思ってしまう。
275:nobodyさん
08/03/30 23:06:10
ログが残る場所が変わるだけだろｗ
276:nobodyさん
08/03/30 23:37:57
だいたいアプリレベルのログをなんでapacheのエラーログでみたいのかが分からん
277:nobodyさん
08/03/30 23:45:40
アプリのログならその気になれば
HTTPヘッダやスタックトレースを出したりできるしな。
なんで不便なapacheログに頼るのだろう？
278:nobodyさん
08/03/31 01:07:38
html側の気づきにくいミスも分かるからapacheログ便利じゃん
fwのログではリソースへのリンクミスは分からない
どこかひとつにまとめておくならapacheログになる
279:nobodyさん
08/03/31 02:15:07
>>278
まとめて保存されてても
見る時は見づらいからフィルタリングして分けてるんじゃないの？
280:nobodyさん
08/03/31 02:58:55
俺なんてapacheログに日記書いてるよ
281:nobodyさん
08/03/31 03:01:14
その発想はなかったわ
282:nobodyさん
08/03/31 13:35:52 q29QDC7U
フレームワークのORMって
テンポラリテーブルやサブクエリ使うような処理はどうなってるの？
出来るのはせいぜいリレーションまで？
283:nobodyさん
08/03/31 14:57:48
サブクエリ対応のORMもあるんじゃないかな。はっきりあるとは言えないけど。
テンポラリテーブルはORMの範疇じゃないと思う。
284:nobodyさん
08/03/31 18:38:39
>>282
そういう場合はSQLを直接発行する。
285:nobodyさん
08/04/01 00:51:46
複雑なSQLになると、SQLは3分で書けたのに、それをORMの文法に直すのに1時間かけても出来無くって、挙げ句ORMのソースコード見たら対応不可能だったという。
286:nobodyさん
08/04/01 01:29:08
っていうか、ORMは80%の簡単なSQLを
簡単に使うのが目的なわけで。
表形式のデータを扱いやすい構造体に変更するの
面倒なんだよ。
287:nobodyさん
08/04/01 02:16:43
>>286
それはORMを理解してない。
> 表形式のデータを扱いやすい構造体に変更
「テーブルのリレーションをオブジェクトのグラフに」ってことだと思うが、
本来ORMはそれを半自動的(設定ファイルが必要)に実現するためのもの。
> 簡単なSQLを簡単に使うのが目的
これを実装したライブラリとかプロダクトがORMを理解してないのに
ORMとか言っちゃったもんだから、そう勘違いしてる人が多いんだけど。
288:nobodyさん
08/04/01 16:18:05
DBを単純なストレージとしてしか使えてない
joinとかサブクエリとか使いこなせてないわ
そんな俺は何から勉強したらいい？
289:nobodyさん
08/04/01 16:23:40
とりあえずは、普段自分が使うDBのSQLをしっかり覚えればいいんじゃない？
それ以上は、DB屋さんが面倒見てくれるでしょ。
290:nobodyさん
08/04/02 09:36:40
PHPじゃないけど、Bash on Railsなんてものが公開されてるね。
まぁ、ジョークなんだけど。
URLﾘﾝｸ(emasaka.blog65.fc2.com)
シェルスクリプトって、普段/bin/sh互換で書かされるから、
Bashの機能をフルに使って、のびのびと何か書きたい気持ちはわかる。
なんか、昔BashでIMAPを喋るスクリプトを書いたのを思い出した。
291:nobodyさん
08/04/02 21:41:33
bash爺さん乙
292:nobodyさん
08/04/02 21:57:39
頼むから少しでもbash絡みの構文が入ったら#!/bin/bashのサフィックス.bashにしてくれな。
293:nobodyさん
08/04/02 23:23:53
>>292
ファイル名のこと？
っていうか拡張子すら無いのも多いし、シェバングがきっちりしてれば気にしない
スレ的に展開すると、世の中には.htmlでPHP書く会社も結構あるしなあ
そこまでじゃなくてもテンプレートファイルが（実質PHPやテンプレート独自言語でも）.htmlなところも多いし
まああれだ。拡張子なんて飾りですよと。Windows使いにはそれがわからんのですよ
294:nobodyさん
08/04/03 00:32:15
今時糞文法のシェルスクリプト使うってどこのマゾだよ
Rubyでやればいいじゃん
295:nobodyさん
08/04/03 00:37:29
ほぼ存在が期待できるperlじゃなくてrubyってところにリッチさ？を感じる
296:nobodyさん
08/04/03 01:07:46
PerlがないならRubyを使えばいいじゃない
297:nobodyさん
08/04/03 07:21:38
>>296
そんな環境あり得ないだろ
298:nobodyさん
08/04/03 16:03:55 YXuoF4WI
perlとpythonはたいていひっついてくるよね
299:nobodyさん
08/04/03 17:23:53
>>296の滑りっぷりに萌えた
300:nobodyさん
08/04/03 23:27:45
Perlの場合、CPANモジュールのインストールを必要とすることが多いから。
BシェルはもちろんBASHの移植性にはかなわない。
301:nobodyさん
08/04/03 23:42:49
>>300
それがPerlではなくRubyの理由？
じゃないよな
この噛み合わなさはいい加減すごいな
っていうかPHPフレームワークの話題は無いのかｗｗｗ
302:nobodyさん
08/04/05 00:07:56
>>300
CPANモジュール使わなきゃいいじゃんっていうのは無し？
だってCPANモジュール使わなくても、bashに出来ることはPerlで書く方が楽じゃね？
俺はLinuxとかよくわからんが、bashで書けてPerlで書けないこととかってあるの？
303:nobodyさん
08/04/05 08:17:54 ELSeDes5
現場だと、ネットワークがガチガチSecureに構築されていて、CPANに届かないことがある。
304:nobodyさん
08/04/05 10:40:20
Perl(without CPAN) < bash なマゾが集まるスレはここですか
305:nobodyさん
08/04/05 22:54:08
移植性を考えるとシェルの方がいい場合も多いってことだ。
306:nobodyさん
08/04/05 23:05:37
>>305
なにと比べて、を書かないとあんまり意味がないな。逆もあるから
例えばシェルの場合はUnixコマンド（互換性があるとは限らない）を必要とすることでも、
Perlなら力業でベタに書けてしまうかも知れない
もっというとPerlで書いたものはWindowsにも持ってこられる場合も多い
shをBATに書き直す事を考えると、移植性って何？ってな事にもなるなｗ
307:nobodyさん
08/04/06 04:34:39
Rubyなければ入れればいいじゃん
シェルの仕事はコマンド発行とパイプ、リダイレクトまで
制御構造の文法がいびつすぎ
308:nobodyさん
08/04/06 19:14:33
LinuxでもFreeBSDでもシステム標準で使われるのは、若干PerlやPythonスクリプトもあるが、ほとんどはシェルスクリプトだろ。
309:nobodyさん
08/04/06 21:05:04
そうだなぁ。趣味だったら、PHPやRubyを使えばすっごい楽なんだが、
業務だとシェルスクリプトを「使わないといけない」んだよなぁ・・・。
そういう場では、「Ruby使いましょう」なんて言える空気ないよ。
Rubyは枯れてないしね。
ところで、Symfonyはそろそろ何かテンプレート機構は装備されたの？
未だに<?php echo $hoge ?>なの？
310:nobodyさん
08/04/06 21:36:35
<?php echo $hoge ?>で何の問題もないわけだけど
311:nobodyさん
08/04/07 17:09:13
そうそう。PHP自体がテンプレートエンジンなのに要らんことすんな馬鹿だろと思う。
312:nobodyさん
08/04/07 23:28:06
short_open_tag をONにしたときの問題って、ぶっちゃけXML宣言との衝突だけ？
それなら自分でサーバの設定をいじれるときは、テンプレートファイルに限定して
<? ?> <?= ?>形式で記述するのも手だなと感じる。
だれかえろいひと教えて
313:nobodyさん
08/04/07 23:31:50
>>310
やはり自民党清和会の下に結集し、日教組を壊滅させることでしょうね。
日教組の教師に｢労働者の権利｣などという左翼思想を吹き込まれた連中が義務も果たさずに
サビ残は嫌だ、非正規雇用は止めろ、などと権利ばかり主張しています。
あとは残業代を要求して裁判を起こしてるような腐った輩を社会全体で徹底的に叩くことでしょう。
314:nobodyさん
08/04/08 00:07:06
みんなうすうす<?=$var?>が効率的なことに気づきだしてる。俺は5-6年前から気づいて田が名。
315:nobodyさん
08/04/08 00:20:04
何をいまさら・・
316:nobodyさん
08/04/08 00:26:07
>>310, >>311
個人的には、<% %>が廃止は馬鹿だろ、と思った。
使ってはなかったが、Rails使い始めて、やはり必要だと思った。
<?php echo $hoge ?> と <%= $hoge %>
はどちらがすっきり見えますか？どちらがタイプ数（補完なしで）少ないですか？
って事を言いたくて、例えばSmarty正式サポートしろという事ではない。
>>312
自サバならそれもありだと思う。
けど、エロい人がこう言ってるから、凡人の俺は使うのを控えてしまう。
URLﾘﾝｸ(wiki.poyo.jp)
>■ショートタグを使っている
>まだそういう本出てきますか．ハァ．
317:nobodyさん
08/04/08 00:49:12
もうそろそろショートタグの正しい使い方を
認めてもいいと思う。
318:nobodyさん
08/04/08 05:07:11
phpはタイプしやすさなんて一㍉も考えてないからなぁ…
htmlspecialchars, array(); preg_replace...
319:nobodyさん
08/04/08 06:48:18
phpはタイポしやすさを考えてるんだよ
320:nobodyさん
08/04/08 15:59:49
PHPはタイプしやすさよりも読みやすさ優先
321:nobodyさん
08/04/08 17:41:25
読みやすい...のか?
まぁ、フラットな名前空間で、メソッドの動的書き換えなしというのは
読みやすさに貢献しているのかもしれない。
322:nobodyさん
08/04/08 19:53:54
Pythonしか使えないGoogle App Engine開始でPHPとRuby仲良く脂肪ｗｗｗ
323:nobodyさん
08/04/09 13:45:29
frameworkはサイト丸ごと作るとかの場合いいんだけど
単体Webアプリの開発すると全く役に立たないのがなあ。
昔はPerlでよくCGIの配布がされていて、PHPも後から増えてきたが
当時は完璧にMVCなんて欠片もないデザイン＆コード全部ひっくるめソース。
だがそれだけに、配布して掲示板だけ使いたいとかいう場合も
そのPHPファイルさえ設置して設定ちょこちょこ弄れば出来た。
しかし今もしframeworkありきでBBSとか作っても、それを配布するとなるとframeworkをまずインストールしなければならない。
大体掲示板とか配布されてるCGI使うのなんて素人だし、そんなframeworkの導入なんてできないし
第一例えばZFで作っていた場合、ディスパッチャが統括してるから普通の巣HTMLコンテンツまで影響が出る。
ただBBSを設置したいだけなのに、今まで普通にそのままアクセスできていたHTMLをZFのルールに従って設置しないといけない。
とか色々面倒すぎる。
frameworkの特にこの部分が気に入らないんだけど、諸兄らは特に気にしない？
index.phpで統括して振り分けるってのね。
普通に配下に全部おいてディレクトリ構成そのままと同じアドレスでアクセスできりゃいいじゃねえか、って思うんだけど。
コントローラー名/アクション名/
とかプログラマは理解してもデザイナが理解しないだろうと。
完全にプログラムばかりなサイトだといいけど、静的コンテンツが殆どで一部に動的コンテンツがある程度じゃ無駄すぎる。
かといってじゃあそういう時は今まで通りの直PHPファイルのみにしろってなると、なんの為のframeworkだかって思ってしまう。
なげーなｗ
324:nobodyさん
08/04/09 16:03:25
そういうケースにフルスタックのFWは向かないってだけだし、
あとZFに限らずフロントコントローラ形式のFWでも
mod_rewriteのルール次第で特定のディレクトリ以下や
ファイルのみに限定して動作させる事はそれほど面倒な事でもない
ディレクトリ構成そのままで一部分だけFW管轄下にする事もできるだろう
mod_rewriteやrouterの使い方が分からない人の言い訳にしか聴こえない
325:nobodyさん
08/04/09 18:42:17
まぁたまにファンクション寄せ集めの使いたくなるけど
結局全部framework上につくれば無問題
326:nobodyさん
08/04/09 21:44:17
>>323
フレームワークつったってただのPHPファイルに過ぎんよ。
新しくフォルダ作って、そこにすべてのファイルぶっこめばいいだけ。
327:nobodyさん
08/04/10 01:33:27
>>326
FWによるでしょ
328:nobodyさん
08/04/10 01:47:20
rewriteとかinclude_pathとか全部ぶんなげか
329:nobodyさん
08/04/10 07:35:57
>>324
だからPHP技術者が理解できても、一般人が理解できないだろって話をしてるんだが。
昔のPHPやPerlならちょっとだけ勉強すれば素人でもいけるレベルだったが
mod_rewriteを弄る素人いないだろ、ってか無料レン鯖だと弄れないところ多いだろ。
有効になってるかどうかすら怪しい。
お手軽が利点だったのに、そういう配布しても一部の技術者しか設定して使えないようなPHPプログラム作ってもなと。
今までPHPファイルを好きな場所に放り込んで、confとかをちょこちょこ弄った程度で使えていたものが
まずFWを導入して、mod_rewriteとかapacheの設定を弄って更に仕様に則った方式に従ってファイルを配置する
なんての誰が使うんだと。
ZFでいえば、PHP.iniのincludeパスまで設定しないといけない（PHP大本ファイルに全てincludeを書くというてもあるが、まあないわな）
そういうケースってか、後からこの機能だけ他で使いたいな って事があるだろ？
趣味でもいいが、FWフル活用であるシステムを作りました、その中の一部機能が評判なのでそこだけ配布する事にしました
が、当然元のFWに依存しているのでそれ以外のFWじゃ動かないし、FW前提の作りなのでファイル置いてconfファイル設定程度じゃ動きません。
で結局配布しても使えるのはほぼPHP技術者のみ。
ちょっと自分のページにCGI設置したい、とかそういう昔からいる人間には無理。
仕事のになら別にいいんだよ。
だが仕事でFW使ってそんな配布するのは昔みたいな作りにすればいいとかナンセンスだしな。
それじゃお互いが有効利用しあえないし。
仕事で作ってた一部を配布したいって時無理だし、趣味で配布用に作ったのをFW使ってる方に使いたいって時も無理（または変換に手間）だし。
>>326
フォルダ作ってぶっこんだだけでちゃんと動くFWがいくつあるよ？
330:nobodyさん
08/04/10 08:56:21
まー確かに要求される知識レベルが昔と比べると格段にあがってるよな
昔は「オブジェクト指向が分かっている人間はプログラマの中でもほとんどいない」
なんて本に書かれていたもんだけど
プログラマ界の被差別層PHPERの間でも
オブジェクト指向なんてもはや前提条件だし
331:nobodyさん
08/04/10 11:14:42
>>329
> フォルダ作ってぶっこんだだけでちゃんと動くFWがいくつあるよ？
有名どころは全部対応しているが？
mod_rewriteだって、index.phpを隠すためだけに使用されているわけで、
デフォルト設定のまま使える。
mod_rewriteでコントローラ/アクションに振り分けているんじゃないんだよ？
332:nobodyさん
08/04/12 13:05:07
URLﾘﾝｸ(www.modrails.com)
mod_rails登場でmod_php雪崩式に脂肪ｗｗｗ
333:nobodyさん
08/04/12 15:40:54
やっと、mod_phpに追いついただけじゃん
しかもプリインストールされるまではきてないし、
何年遅れだよｗｗ
334:nobodyさん
08/04/12 16:17:48
は？
フレームワークレベルでmodになってるんだからとっくにphpをぶち抜いてるよ
mod_symfonyとかmod_zend_frameworkみたいなもの
ﾌﾟｰﾌﾟﾌﾟﾌﾟ
335:nobodyさん
08/04/12 17:23:23
rubyに手を出すとスレタイすら読めない無能になるのか
336:nobodyさん
08/04/17 16:32:23
MySQLがオープンソースじゃなくなってPHPまた一歩脂肪ｗｗｗ
337:nobodyさん
08/04/17 17:02:10
その理由なら、rubyも死亡だろｗ
338:nobodyさん
08/04/18 06:17:36
まじでMySQL終わりっぽいじゃん
新規開発はpostgresにした方がいいんかな
339:nobodyさん
08/04/18 07:41:13
クローズドになったらMySQLなんて誰も使わないよな
ポスグレも充分に速くなってるから代替効くし
Sunの戦略がわからんわ
340:nobodyさん
08/04/18 09:42:52
クローズドになるとかいってんのお前だけだよｗ
341:nobodyさん
08/04/18 14:07:52
ソースはこれ？↓
MySQL、新機能追加は有償版の「MySQL Enterprise」だけを対象に
URLﾘﾝｸ(www.technobahn.com)
342:nobodyさん
08/04/18 14:18:22
別にフリーだから使うなんて事はないんだぞ？
趣味ならそれは重要だが。企業レベルじゃあまり関係ない。
SQLServerやらMySQLの有料版が実際使われているのがいい証拠。
企業の場合どっちかというとサポート体制が重要。
金払ってるといざって時サポート呼べるし、場合によっては責任もとらせられる。
無料版だとサポート呼べないし責任は全部自分ところ。
なんでもオープンソース使え使えっていってるのは2流の技術者と、そういうのに疎い有料無料かでしかみれない上役だけ。
現場でわかってるプロの技術者なら有料か無料かなんて選択肢の中ではかなり優先度は低い。
少なくとも、これオープンソースだから使いましょうよ、なんていってる技術者いたらその時点で役立たずのレッテル貼るわ。
その構築するシステムに向いてるかどうかで判断するのならまだしも。
343:nobodyさん
08/04/18 14:52:31
>>342
プロの技術者乙
344:nobodyさん
08/04/18 15:42:02
新機能が追加されないMySQLを使い続けてPHPERジリ貧ｗｗｗ
345:nobodyさん
08/04/18 18:10:17
その理由なら、rubyも死亡だろｗ
346:nobodyさん
08/04/18 18:23:32
RoRはMySQLをポイ捨てしてsqliteに乗り換え済み
先見の明の違いが出たねｗ
347:nobodyさん
08/04/18 18:54:43
ひどいつりだな
348:nobodyさん
08/04/18 19:35:54
sqliteはパブリックドメイン（何しても自由）だから
フレームワークに内蔵してデフォルトにしているだけで
別に良いものだから選んでいるわけじゃないんだけどな。
あくまで開発・プロトタイプ・個人用のもので
複数の人が同時にアクセスするものとしての
本番利用は現実的じゃない。
それにPHPは、sqliteをとっくの昔に言語の標準
データベースとして組み込んでいる。お前に言わせれば先見の明だなｗ
349:nobodyさん
08/04/18 19:41:04
末端の利用者が評論家気取りでグダグダ言ってるなよ。
みっともないｗ
350:nobodyさん
08/04/18 19:55:20
はぁ？ 普通利用しているからことちゃんとした意見言えるわけで。
使ってもいないくせに何か言おうとしているなこいつｗ
351:nobodyさん
08/04/18 20:26:25
>>350
つれたつれた
352:nobodyさん
08/04/18 20:38:46
>>342
一般企業で有償MySQLってなかなかないんじゃないかな？
OracleかSQL Serverでしょう、有償なら。
現場で解ってるプロの技術者には選択肢ないんじゃないかと思う。
俺の周りだけの話だけかもしれないけど。
353:nobodyさん
08/04/18 20:56:40
裾野が狭まるから頂も低くなるんだよ
オープンソースからプロプライエタリに移行して成功した製品あんのかと
354:nobodyさん
08/04/19 01:02:42
> オープンソースからプロプライエタリに移行して成功した製品あんのかと
どうやら、あなたはオープンソースからプロプライエタリに移行したら
失敗するといいたいようですが、そもそも
オープンソースからプロプライエタリになった製品があるのですか？
あと、MySQLはsunが買収したとしても、オープンソースのままなのは
知っていますか？
355:nobodyさん
08/04/19 03:29:45
>>354
オープンソースからプロプライエタリに移行した製品がないという
悪魔の証明に自ら挑むとはｗ
製品を殺す愚策なんだから知られないのは当然
まぁ俺も知らないけどね
本当に無償版の開発を停止して有償版しか出さなくなったら
MySQLは死んでいくと思うよ
356:nobodyさん
08/04/19 07:12:17
>>341を読む限り、「新機能」がCommunityServer版に付かなくなる、とも読めるな
もしメンテ（および機能改良）が続くんなら別にいいかなと、無理矢理楽観してみる
357:nobodyさん
08/04/19 08:21:08
ウェブシステムの性格的に、信頼性が低くても安い方がいいってことでApacheとかMySQLとかPHPとかが流行ってるわけだからな。
金かかるんだったら、ポスグレにして、その分自分の収入にする罠。
358:nobodyさん
08/04/19 09:19:18 Pd4VwcNb
くだらん書き込みが続いてるなぁ。
ApacheもMySQLも信頼性が低いってー事はないぞ。PHPについてはシランが。
あと、普通にPHPでwebプログラムを組める奴は必然的にPHPとJavascriptという風に複数言語使えるようになってるからそこから更にrubyとかいうことになってもそんなにコストかかるわけじゃないと思う。
俺もrubyについては手をつけてないが、Cやらpythonやらに手をつけてるし。
PHP脂肪とか言われたら他の言語使えばいいだけだって気づかないんかね。
# あと、ここはフレームワークのスレかと
359:nobodyさん
08/04/19 09:21:27
>>355
あんた、悪魔の証明が何かわかってないんじゃね？
360:nobodyさん
08/04/19 13:03:25
>>354
RHELとか？
成功というのが何を指してるかわからないけど。
361:nobodyさん
08/04/19 18:10:16
URLﾘﾝｸ(d.hatena.ne.jp)
Community Server開発継続でPHP余命一年延びるｗｗｗ
362:nobodyさん
08/04/20 01:52:32
src php 捨てたい
けどまだ時期尚早だよな
363:nobodyさん
08/04/22 22:01:35
URLﾘﾝｸ(blog.ohgaki.net)
Ruby1.9以下のWEBrickにディレクトリ遷移攻撃脆弱性があってPHP脂肪ｗｗｗ
364:nobodyさん
08/04/22 23:27:24
URLﾘﾝｸ(d.hatena.ne.jp)
誰かこれ参加しろよ
365:nobodyさん
08/04/23 03:25:02
Delphi for PHPってどうなんだろう
「データベースに特別なコードを書かずとも容易に接続できるようにした」
とかいう説明読むとフレームワークと認識してもいいように思うけど
366:nobodyさん
08/04/23 10:30:22
>>365
フレームワークの定義って、データベースアクセスが簡単かどうかってよりも
アクションのディスパッチャがあるかどうかだと思う。
367:nobodyさん
08/04/23 21:37:32
そりゃMVC一通りあるんじゃないの？使ったことないから分からないけど
368:nobodyさん
08/04/24 20:18:05
URLﾘﾝｸ(blog.ohgaki.net)
Pythonのセキュリティー警告してたらSPAMにメールアドレス使われたみたいだ
Python厨タチわりー
369:nobodyさん
08/04/24 20:21:21
Python厨だけにGoogle App Engine使って配信したのかもな
370:nobodyさん
08/04/25 06:21:16
そんな攻撃的な信者はphperにもrubyistにもいないよな
phythonerﾔﾊﾞｽ
しかも単なるセキュリティー情報で誹謗中傷ですらねーし
371:nobodyさん
08/04/28 10:48:30
フォームヘルパーって使ってます？
せっかくMVCなのにテンプレートに関数入れるなんて、とっても矛盾してると
思うのですが・・・
そういう需要もあるってだけなんですかね
372:nobodyさん
08/04/28 11:49:40
Viewのロジックじゃん
MVC=Viewの動的要素を一切省こうってわけじゃないよ
373:nobodyさん
08/04/29 00:07:53
確かにプルダウンとかラジオボタンのHTMLをコントローラ（やモデル？）でつくって
準備するのはなんだかなーだ
分担としては間違いなくViewの仕事だろう。ヘルパーって言うのが微妙なんだけどな
374:nobodyさん
08/04/29 01:49:36
だからViewHelperはViewの範疇なんだっての
高校生か？
375:nobodyさん
08/04/29 09:35:20
URLﾘﾝｸ(www.sabel.jp)
またフレームワークが増えましたよ、と。
376:nobodyさん
08/04/30 02:52:49
DIにアスペクト志向にアノテーション……採用前評価がめんどくさそうなw
採用検討／評価するにしてもうちはGW終わってからだなー。
おまえら頑張れ
377:nobodyさん
08/04/30 04:53:29
symfonyってcodeigniterの何倍くらい重い？
378:nobodyさん
08/04/30 15:03:38
rubyてmysql使うのにもmakeとかしなきゃいけないのか・・俺脂肪
379:nobodyさん
08/04/30 16:29:31
ふつー gem install mysql
380:nobodyさん
08/05/01 17:01:00 1aec6u7x
ethnaがシンプルでよかったので
社内システムの標準FWに採用しました。
381:nobodyさん
08/05/01 20:29:40
ethnaってまだ開発続いているの？
382:nobodyさん
08/05/02 00:35:33 ulIGiMsU
地味に続いてるよ。
383:nobodyさん
08/05/02 14:05:51 ulIGiMsU
新しいバージョンでるみたいだね。
384:nobodyさん
08/05/02 14:35:04
symfonyはcodeigniterの3倍遅いみたいね
同じパフォーマンスをあげようと思ったら3倍のリソースが必要か…
385:nobodyさん
08/05/02 14:58:16
単純に機能とスピードのトレードオフだろう。
386:nobodyさん
08/05/02 16:54:39
URLﾘﾝｸ(jp.techcrunch.com)
twitterがRoRを放棄でPHP復活ｗｗｗ
387:nobodyさん
08/05/02 16:57:33
RoRがスケーリングに対応できないというが
それならRoRをパクっただけのPHPのFWが対応できるのか？
388:nobodyさん
08/05/02 17:16:29
全部erlangで書きゃいいのに
389:nobodyさん
08/05/02 17:16:36 mpl3PtrU
phpは素で書けば速いもんな。
390:nobodyさん
08/05/02 18:38:44 ulIGiMsU
エスナも早いよ
391:nobodyさん
08/05/02 20:08:53
ciはソースに今どき閉じタグが書かれているのがイモ
392:nobodyさん
08/05/02 20:50:58
閉じたり閉じなかったりで動きが変わる事自体がイモじゃね
仕方ないんだろうけどさ
393:nobodyさん
08/05/02 21:29:55
>>391は所得も知能も底辺に位置する者の喚き声だなｗ
394:nobodyさん
08/05/02 21:37:21
なんで？
395:nobodyさん
08/05/02 21:38:49
>>393の頭には虫がわいてんだろうなww
396:nobodyさん
08/05/02 22:22:41
ソースに今どき開きタグが書かれているのがイモ
397:nobodyさん
08/05/02 23:34:45
>>396
それは激しく思う。というか閉じタグをとっぱずすなんてどう考えてもバッドノウハウじゃねえかｗ
少しは疑問に感じろよPHPerども
398:nobodyさん
08/05/03 03:55:15
閉じタグを書かない俺ってＧＥＥＫ！
399:nobodyさん
08/05/03 03:59:36
ciはsystemディレクトリの中にapplicationディレクトリが入ってるのがイモ
そこは分けとけよ
400:nobodyさん
08/05/03 04:42:11
>>398はもっと評価されるべき
401:nobodyさん
08/05/03 06:16:41
しばらくsymfony使ってて
久しぶりにci触ったら身軽でいいわ～
402:nobodyさん
08/05/04 23:06:36 QrBYi/l0
結局 中小規模だとどれがおすすめ？？
CakePHP
-> DBと密接すぎる
CodeIgniter
-> セッションがクッキーに保存される
とどっちも肝心なとこがいまいちだった…
403:nobodyさん
08/05/04 23:10:28
>>402
ちゃんと使えば？CIのセッションについては、DBに保存することもできたと思うけど。
っていう自分はドキュメントよんで評価して改良してっていう手間がもうしんどくて、
guesswork classic をカスタマイズしたものを延々つかってるけど
404:nobodyさん
08/05/04 23:13:41
>>403
うん DB使うときはそれでいいんだけど
使わないときがね…
小規模だと CakeかCIがよさげなんだけどね
その改造する手間がね… orz
guessworkもためしてみるかな
405:nobodyさん
08/05/05 00:52:06
CakePHP ってそんなにDBと密接だろうか？
usesプロパティにnull代入すれば
それで終わりじゃね？
406:nobodyさん
08/05/05 01:19:43
>>405
それで一応できるけど
modelは必須なのが前提だし…
DB使うにしても密接すぎて融通きかない感じかな
はまれば楽なんだけどね
407:nobodyさん
08/05/05 03:33:55
普通に作ればモデルを作るのが当たり前なんだが・・・。
まあ経験をつめ。
408:nobodyさん
08/05/05 09:50:45
変態セッションがいやなら$_SESSION使えばいいじゃない
409:nobodyさん
08/05/05 12:22:34
>>407
DBやファイル扱わない場合だってあるじゃん・・
410:nobodyさん
08/05/05 12:31:02
たとえば？
411:nobodyさん
08/05/05 13:45:56
それはどのFWを使うかというより、
FWを使うべきかどうかを検討する規模の開発だと思う。
生PHP+何かしら必要なライブラリで事足りそう。
412:nobodyさん
08/05/05 15:29:14
>>407
自分は、>>406じゃないけど、具体的にはどんな感じでモデル組んでます？
オンメモリな処理はともかく、DB上のデータに対しては、SQLの実行はパフォーマンスに
直結するから、内部の処理は隠すべきではないんじゃないかって思うところもあって、
結構悩ましい。
413:nobodyさん
08/05/05 17:17:56
内部の処理をモデルの中に隠せばいいのでは？
414:nobodyさん
08/05/05 19:08:40
だって、最適なSQLって画面とか機能ごとに違うことが多いじゃん。
画面とか機能からの独立性がほとんど無いものを個別に作り上げて、
それをモデルと呼べるのかといえば、かなり疑問。
っていうか、モデルとしてのメリットがほとんどない。
415:nobodyさん
08/05/05 19:21:04
MVCを勉強しなおしてね。
416:nobodyさん
08/05/06 01:40:18 Db+mgkTm
CIのルータが変態なので自前ルータを書いてるんだが
hoge/moge/
と
hoge/moge
を同一と判定すべき？しないべき？
417:nobodyさん
08/05/06 01:45:13 iGu8GQhf
すべき
418:nobodyさん
08/05/06 01:54:34
だよな
ファイルシステムとの類推で考えると
同名のファイルとディレクトリは同階層に存在できないもんな
419:nobodyさん
08/05/06 03:21:15
どちらでも同じコンテンツにアクセスできることが望ましいと思うが、
どちらかに転送した方が良いと思われ
420:nobodyさん
08/05/06 16:53:07
質問スレで知ったんだがRhacoってどうなの？
和製フレームワークっぽいけど
このスレで出たことないよね？
421:nobodyさん
08/05/06 16:54:23
どうも和製はなぁ。
結局海外製に押し切られる気がする。
だからRubyもいまいち使う気になれない。
422:nobodyさん
08/05/06 16:56:00
Rhacoのオフィシャルサイトがなんか重いなァ
パフォーマンスでないのかな？
423:nobodyさん
08/05/06 16:59:32
結構作り込んである印象
なんでまったく話題に出なかったんだろ？
424:nobodyさん
08/05/06 17:36:05
>>416
それって他のFWもそうじゃない
その辺があまいのばっかだよなあ
425:nobodyさん
08/05/06 17:47:31
CIがあまいだけでは？
426:nobodyさん
08/05/06 17:48:55
>>418
おいおい。index.htmlを忘れているぞ。
hoge/moge/ だとmogeフォルダのindex.html（設定による）を参照すべきだろう？
427:nobodyさん
08/05/06 17:55:43
>>426
>>417-418は、まさにそう言ってるんだと思うが？
428:nobodyさん
08/05/06 18:14:00
いや、少し考えてみた。
URLが hoge/moge なら、一番最初に hoge/moge を探すべきだな。rewriteやaliasを含めて。
いきなり hoge/moge/ に書き換えるのは乱暴か
で、そうやって探して hoge/moge が見つからなかった時のみ、hoge/moge/(DirectoryIndex) と
するのが一応は順序かと思った。
>>426はそういう意味かな
429:nobodyさん
08/05/06 18:15:28
/hoge/mogeでも/hoge/moge/でもどっちでも
mogeがディレクトリ的存在だったら
/hoge/moge/index.html
が表示されるべきで、
その判断はサーバ側でおこなう。
最後の/の有無だけに、エンティティの判断基準を委ねない。
ってことだな
430:nobodyさん
08/05/06 18:16:27
なんかかぶったｗ
431:nobodyさん
08/05/06 18:20:13
>>430
結論は反対だけどねｗ
432:nobodyさん
08/05/06 18:22:19
ん？同じだろ？
433:nobodyさん
08/05/06 18:24:06
426…最後の/で判断するよ派
428・429…最後の/で判断しないよ派
これであってる？
434:nobodyさん
08/05/06 18:30:18
ってか
フレームワークのルータに/hoge/moge/index.htmlが渡ることって考えにくいな
素のリソースはmod_rewriteの設定で直接アクセスされるだろ
435:nobodyさん
08/05/07 00:29:19
/foo/barへのアクセスは
1./foo/barがファイルであるか確認
2./foo/bar/へリダイレクト（301 Moved Permanently）
が正しい動作のはず。
436:nobodyさん
08/05/07 01:08:20
何を基準にした「正しい」動作なの?
437:nobodyさん
08/05/07 01:32:49
俺もｵﾓﾀ。いったい何を基準に正しい・正しくないを議論しているのか…
独自アプリのルーティングの話で index.html がどうとかﾜｹﾜｶﾗﾝ
静的ファイルを表示するための httpd を書いていて
mod_dir に酷似した挙動をさせたいということならわからなくもないが、
>>416が聞きたいのはそういうことなのか?
438:nobodyさん
08/05/07 02:53:40
パスが変わるのでしないべき
妥協点はスラ付きへリダイレクト
が正解
439:nobodyさん
08/05/07 03:22:12
>>438に賛同。
SEO/SBO という面で考えれば、/ ありと / 無しをアプリ側で同一と見なすべきではない。
ただし、ユーザビリティを考慮すれば、/ 無しを / ありに 301 で転送 (またはその逆) をすることをするとなお良い。
参考 → URLﾘﾝｸ(pmakino.jp)
440:nobodyさん
08/05/07 06:16:35
なるほど
たしかにSEO的にリダイレクトする方がいいな
㌧㌧
441:nobodyさん
08/05/07 06:36:20
>>414
乗り遅れたけど、いい事言ってるなあ。
>>407とか>>415は流行に流されて本質を見失ってるな。
俺はテーブルと一対一になるモデル「じゃない」モデルクラスを作って対処してる。
442:nobodyさん
08/05/07 06:50:57
>>441
日本語が読みきれん。どっち？
テーブルと1:1に対応することを前提としないモデルクラスを作ってる
テーブルと1:1に対応する、内部の構造が隠蔽されていないから必ずしもモデルとは呼べない、モデルクラスを作ってる
前者だろうとは思うけど、一応。
443:nobodyさん
08/05/07 09:21:36
はぁ。テーブルと一対一にならなくても
モデルはモデルだろ。
444:nobodyさん
08/05/07 09:47:29
むしろ、テーブルと1:1になることを前提にするのは、内部構造に対する抽象化が制約されるという意味で、
モデリングとして不適切だと思ってる。
だから自分的には >>443 は自明。
ただ、>>441 の言葉の意味が取りきれなかっただけ。
445:nobodyさん
08/05/07 09:56:24
クラスで使う例外って
クラスと同じファイルに書く？別にする？
例外クラスを1クラス1ファイル方式にすると
ファイルがとっちらかるよなぁ
446:nobodyさん
08/05/07 12:42:06
特定のフレームワーク上でのお作法の話ならずれてるかも知れんが、
自分の場合、自作の例外クラスって、せいぜい2個ぐらい (ユーザ操作系、システム異常系) しか作らない。
どんな例外であれ、rollbackしてエラーメッセージ出して終わりってのがほとんどだから、
クラス分けせずにエラーコードで区別してる。
447:nobodyさん
08/05/07 14:16:49
俺はタイプヒンティング使ってcatchするのに結構使うな
448:nobodyさん
08/05/07 20:53:16
>>446
せっかく例外という便利なものが使えるのに、
古臭く、使いづらく、バグが起こりやすい、
エラーコードを使う理由ってなに？
449:nobodyさん
08/05/07 21:11:53
>>448
例外の中でエラーコードを使うこと言うこと。
クラスの型で判別してないだけで、例外は使ってる。
450:nobodyさん
08/05/07 21:14:56
>>449 タイプミス訂正
例外の中でエラーコードを使っていると言う意味。
クラスの型で判別してないだけで、例外処理は使ってる。
451:nobodyさん
08/05/07 21:59:18
>>445
class なんとか_かんとか_Exception extends なんとか_Exception
{}
だけみたいなファイルが増えてくのはやっぱバカバカしいな
452:nobodyさん
08/05/07 23:57:23
というかPHPのtry catchはゴミすぎて使う気になれませんよｗ
453:nobodyさん
08/05/08 00:14:58
結局catch ～～ で分岐するか、instanseof で分岐するか、
$e->getCode(), $e->getMessage() で分岐するか、の違い
しかないとか思っちゃうんだが、わかってないってことだと
自分でも思う
454:nobodyさん
08/05/08 00:29:40
MVC要らんな。
長い目で見たら実は激しく開発効率が落ちるよな。
みんなとっくに気付いてるだろ。
もうMVCなんて発掘された化石にしがみつくのはやめようぜ。
テンプレートに全部書くに限る。
冗談抜きで、コピペでいい。
変更は該当ファイルを変更。
追加は新規作成。
そもそもPHPはこの形で爆発的に伸びてきた。
ものすごい速さで「ページ」を量産できてきたわけだ。
PHPと比較してはるかにHTMLを苦手とする他の言語の実装にすりよる必要なんてない。
コードが醜悪で結構。
メンテし難い？
いやいや、HTML部分はどんな初心者でも理解可能だからさっさと読み飛ばすわけだ。
そして残ったPHP処理部分がMVCを捨ててページ単位で完結して書いてある。
完結しているのだから、追っていくだけで全容が分かるわけだ。
汚い素のPHPファイルが開発効率に優れている理由はここにある。
何かを試験的に作るとき、さっさとPHPというテンプレートで書いちゃうだろ。
たぶん、数時間あれば、第三者に見せられる程度の単機能ページを作れるだろ。
その試作品でいいんだよ。
一週間かけたものと何も変わんねえから。
つまりその試作品で50万くらい請求できるわけだ。
あるいは、10万に値下げできるわけだ。
頭冷やそうぜ。
PHPそのものが実利の塊なんだから、無理して加工すんなって。無駄な汗を流すなよ。
どうしても加工してPHPらしくない別フレームワークを作りたければ、C++で本気で作れ。PHPでやるな馬鹿外人。
455:nobodyさん
08/05/08 00:42:41
>>454
プログラマとしては気に入らないけど、現場レベルだとコピペ嵐の方が修正時の影響範囲が
限定的だから現実的だというのは、認めないわけでもない。
カラシニコフ的アーキテクチャとでも言うべきか。
456:nobodyさん
08/05/08 00:55:28
>>454
修正が体力勝負になるから嫌気がさすっていうのもあるんだよｗ
ポリシーと一貫性があるならいいが、どうせ修正がかさむにつれ
AとA'とA''とABとA''Bみたいなソースが量産されてくるんだろ
一字一句変えずにコピペできる所なんてそう無い。大概コピペ先で
修正されてdiffとったりしたら目を覆うような作業量になる
それでも、「可能」かどうかをいうなら、修正は可能だし、８割くらいの
作業が速く済む、っていうのはうなずけなくもないけど
457:nobodyさん
08/05/08 02:02:54
PHPの場合、try catchの例外処理機構が駄目なんじゃ無くって、組み込み関数がエラーで例外吐かないのが糞。
458:nobodyさん
08/05/08 04:09:14
>>454
なるほど
ベタ書き→PHP
MVC→他の言語
と使い分けてもいいかもね
PHP以外なら何がいいだろ？
459:nobodyさん
08/05/08 05:17:56
俺もPHP使ってるけど確かにそういうことを考えたりする。
>>454はちょっと乱暴な文体だけど言いたいことはわかる。
これは何もスパゲティなコード書けということではなくて
もちろんメンテしやすいように努力はするのだけれど
そのために果たしてMVCやオブジェクト指向が必要かどうかといえば
必ずしも必要ではないかもしれない。
我々は何もPHPしか使えないわけではないのだから
PHPを使う時は割り切ってページ単位でディレクトリ階層もわかりやすく
作っても良いのかもしれない。
正直、最近PHPフレームワークについて興味があったんだが、
再度PHPの良さについて考えてみよう。
460:nobodyさん
08/05/08 06:45:47
テストのしやすさとか
開発効率とか
安定性を求めれば
結局MVCに戻ってくることになる。
おつかれさんｗ
461:nobodyさん
08/05/08 08:00:22
実利を求めたらオブジェクト指向に落ち着くだろ
462:nobodyさん
08/05/08 08:20:17
どうだろうね。プログラマは確保できるけど能力的には怪しいっていう環境なんかだと、
エレガントな設計はむしろ罪悪じゃないかと思うし、残念ながらそういう環境は多い。
逆に言えば >>454 は、人海戦術で対応可能な仕事でないと成立しないんじゃないかとも思うが、
エレガントさをあきらめれば、人海戦術で対応できない仕事なんてそうないし。
463:nobodyさん
08/05/08 08:43:03
PHPの特徴はPHPとHTMLが混在できるということだよな。
この混在をViewが分離してないので悪と捉えるならば、
PHPの特徴も悪ということになる。
それでそのPHPの特徴を無くしたMVCなフレームワークを使うことになるんだが、
それじゃPHPを使ってる意味とは何なんだろうか。
別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
別にMVCなフレームワークが悪いと言ってるんじゃない。
ただ、PHPの特徴を活かした使い方があるんじゃないだろうか。
昔ながらのロジックとビューをファイルの上下で分割するような次のような使い方でも。
-------------
<?php
//設定や共通関数のinclude
//PHPによる処理
$a = 1;
?>
<html>
...
<?php echo $a; ?>
</html>
464:nobodyさん
08/05/08 09:39:12
> 別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
そのとおりだよ。
ただ、フレームワークも込みで、どこのレンタルサーバーで動くようなものはPHPしかない。
Rubyは言語辞退は一定な買ったりバージョンが古いし、
Perlはフレームワークや、必要なライブラリをインストールするのに
Shellやある程度の権限がいる。
PHPとPHP製フレームワーク・ライブラリは、ほとんどが
ファイル配置ですむからね。
あぁ、これがPHPを使っている意味かｗ
465:nobodyさん
08/05/08 09:40:21
Rubyは言語自体入ってなかったりバージョンが古いし、
466:463
08/05/08 10:10:38
>>464
そうなんだよ、現実を考えるとPHPを使いたいというよりは
PHPを使わざるを得ない、という感じなんだよ。
そして使わざるを得ないPHPでPHPの特徴を消すようなフレームワークを使う。
このジレンマというかもやもやしたものが俺の中に常にある。
>Rubyは言語辞退は一定な買ったりバージョンが古いし、
>Perlはフレームワークや、必要なライブラリをインストールするのに
>Shellやある程度の権限がいる
これはレンタルサーバ屋によるというか、PHPも最新バージョンを使いたい
（特にセキュリティホール絡みで）時は、結局自分で最新版をコンパイルすることになって
権限やShellが必要になるので、ほんと、レンタルサーバ屋によるとしか言えないな。
467:nobodyさん
08/05/08 11:24:56
ベタ書き＝PHP＋XREA
MVC＝Python＋Google App Engine
がいいかな？
468:nobodyさん
08/05/08 11:33:59
悪くないんじゃね。適材適所？
GoogleAppEngineは本サービスの内容次第だけど
469:nobodyさん
08/05/08 12:49:25
FWと独立したORMがもっとでてこねーかな
好きなFWに好きなORMを組み合わせるみたいな使い方が一般的になればいいのに
470:nobodyさん
08/05/08 12:54:43
直SQLで十分。
471:nobodyさん
08/05/08 13:01:46
ﾃｨﾝﾎﾟﾆｰの新しいヘルパって
クラスメソッドになったんだっけ？
<?php echo HogeHelper::url_for('default/poge')?>
みたいな風に書くの？長くね？
472:nobodyさん
08/05/08 13:20:40
>>466
本末転倒になってね？
PHPの（いけてない）特徴を消すのが何が悪いの？
473:nobodyさん
08/05/08 14:41:46
いけてないPHP？
綺麗事抜きでドラスティックに行きましょうや
ベタ書き＋直SQL ＝ PHP＋XREA
MVC＋ORM ＝ Python＋Google App Engine
簡単にできることを複雑にやる必要はない
Python、Java等と使い分けて適材適所で
474:nobodyさん
08/05/08 14:52:22
開発言語なんて自由に選べるものでもないし、
サーバーサイドで複数の言語が混在したシステムなんて考えたくもない。
ただ、PHPの言語仕様がさほど特徴的とも思わない。
自分は標準ライブラリが整備されてて、メジャーだからPHP使ってる。
475:nobodyさん
08/05/08 15:13:05
>>473
まず、君は何の為にデザインとロジックの分離という
考え方が存在するのか、なぜORMというものが存在するのか、
その理由を知ったほうがいい。
話はそれからだ。
（そのあとで、なぜPHPにはそれが当てはまらないというんだ？と聞く予定）
ついでに、なぜテンプレートを使えば、
RubyやPythonでも、PHPと同じようにHTMLの中にロジックを
書くことが出来るわけだが、なぜその方法を使わないのか。
君はこっちのほうが簡単だ。といいたいんだろう？
476:nobodyさん
08/05/08 21:45:25
>>475
で、どれがデザインとロジックの分離できてるわけ?
Rails? JSF? Django? どれもできてないじゃん。
実際できるのがあったとして、それはメジャーなん? 使い物になるだけの速さでるの?
できてもない『デザインとロジックの分離』という幻想を抱いて死んでくれ。
おれは断然>>454支持するぜ。
477:nobodyさん
08/05/08 22:39:24
まあ極端にならんと。
どっちの利点も判らんでもないけど、中庸ってのも考えなきゃ
妥協点ともいうか
たとえ幻想でも雑魚をまとめる旗印にはなるしw
478:nobodyさん
08/05/09 00:59:50
自分が楽な作り方を選べばいいじゃん。
一人でちっさなツール作るなら、べたに書けばいいんじゃね？
中規模以上のものを作るにはMVCが作りやすいがね。
479:nobodyさん
08/05/09 02:21:08
プログラムとは一言でいえば「データ＋処理」
それ以上でもなければ、それ以外でもない
WEBアプリ＝DBラッパー
DOA→ベタ書き＋直SQLで充分
OOA→MVC＋ORMで楽できる
フレームワークは他人の知恵を借用して楽できるツール＝使わなきゃ損
普段フレームワークを使っていれば、逆にフレームワークを使うまでもない状況かどうか判断できるはずだよね？
お問合せメールフォーム１ページ作るのにsymfony使ってますとかは漫才ｗｗｗ
480:nobodyさん
08/05/09 03:21:13
インプットチェックで異常があったらフォームを再表示みたく、処理結果によって表示するページが
異なったり、複数の処理結果に対して同じページを表示したいことがあるのは普通だから、
ビューを分離するのは良いんだけど、DBアクセスは、同じ処理をしたいことは多くないし、
無理にまとめるとパフォーマンスが劣化するから、モデルとしてまとめることに利点があるのかは疑問。
コントロールも、自分の場合トランザクション前の処理、トランザクション中の処理、トランザクション後の処理、
次のページ取得を呼び出すクラス作って継承する程度で十分間にあってる。
ビューについては、そもそもがベタ書きみたいなもんだし。
フレームワークは、特定のフレームワークが業界内において支配的な立場になり、
その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
ソースコードの可読性は考慮すべきだけど、フレームワークを導入しただけで可読性がよくなる
わけじゃないし、フレームワークを導入しただけで大きなメリットがあるわけでもないなら、
フレームワーク使うべきって論はどうかなぁって思う。
481:nobodyさん
08/05/09 13:09:55
フレームワーク使うべきかどうかってそういう次元の話じゃなくて、
単にフレームワークを使ったほうが楽だから使うだけだよ。
> DBアクセスは、同じ処理をしたいことは多くないし、
同じ処理あるよ。検索処理や、検索結果を扱いやすいように
構造化されたハッシュ・配列に入れる処理。
JOINしたときとか、二次元の表よりも階層化された
配列に入ってくれたほうが楽だよね。
> その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
意味がわからん。PEARライブラリとか普通に使えるだろ。
フレームワーク専用のパーツなら、普通に使い勝手が良いパーツが組み込まれている。
だからこそ便利であり、使うんだが。
> フレームワークを導入しただけで可読性がよくなるわけじゃないし
良くある言い方だね。銀の弾丸じゃないならメリットがないとする極端な考え方。
銀の弾丸なんて存在しない。だけど普通の弾丸なら存在する。
弾丸が効かない敵がいたって、効く敵もいるんだから弾丸はあったほうがいいだろ。
フレームワークを導入すると、可読性が良くなる場合もあるし
少しでもメリットがあるのなら、あったほうがいいだろ。
482:nobodyさん
08/05/09 21:42:19
>>475
>まず、君は何の為にデザインとロジックの分離という
>考え方が存在するのか、なぜORMというものが存在するのか、
>その理由を知ったほうがいい。
>
>話はそれからだ。
なにこのえらそうなバカ。おまえはデザインとロジックの分離ができてるの?
こんだけえらそうに語ってるんだから、きっと完全な分離ができるんだろう。
で、どれを使ったらできるの? Symfony? Cake?
教えて、コーマンチキな475さん
483:nobodyさん
08/05/09 22:56:26
「話はそれからだ」ってのは「理由は聞かないで下さいっ >_<」って意味なんだから、そっとしといてやれよ。
484:nobodyさん
08/05/09 23:11:23 a3XtheQg
>>482
>>475じゃないけどsymfony+smarty使ったことあるかい？
しかしMVCは良いとしてもO/Rマッパはなんとかならんもんかね
485:nobodyさん
08/05/10 01:24:53
>>484
あんな糞なもん使ったって何の自慢にもならねーよｗ
まあ、sfSmartyPlugin（だっけか）の品質の問題はともかく、
デザインにもロジックはあるのだよ。
ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしいのはPropelだけなのかもしんないけど。
そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
486:484
08/05/10 03:06:24
>>485
>>デザインにもロジックはあるのだよ。
それ言ったらjspも(ry
>>ORMはおかしいよな。テーブルとモデルが一対一になってる。
いや別に。
漏れがどうにかしてほしいと思っているのはpropelの使い方だけ。
doctrineもpropelもSQL文直打ちしていた人からしたら使いづらいと思うんだよね。
executeQuery()使えばいいんだけど、それだとO/Rマッパーの意味ないしな。
>>そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
フレームワーク反対派に賛同したつもりはないんだが・・・・・。
ある程度規模でかくなればクラス分割してlib配下に設置してあげるだけでオートロードしてくれたりするから再利用も行いやすい。
フレームワークは結構便利だと思う。
でもそこまででかくならないんだったら別にいらないよなーって感じじゃね。
symfonyぐらいのフレームワーク使うんだったらメリットでかいと思うけどCakePHPやPiece Frameworkレベルだと別になくても良い様な希ガス。
487:nobodyさん
08/05/10 10:23:21
小さいのを作るにはフレームワークを使わなくても出来るけど、
大きいのを作るにはフレームワークを使ったほうが便利。
便利な方法と、不便な方法。どちらを選ぶかは
考えるまでも無い。
488:nobodyさん
08/05/10 10:26:41
>>485
> デザインにもロジックはあるのだよ。
そうだね。でどうしろと？
どうせデザインにロジックがあるのだから、
各自勝手に作れといわんだろ？
あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
もう少しバランス感覚養ったほうがいいんじゃないのか？
1か0じゃなくて、どちらのほうが優れているかで話をしろ。
489:nobodyさん
08/05/10 11:47:06
JavaのApache Wicketというフレームワークは
テンプレートにHTMLを使う。
JSPみたいな独自タグや{hoge}みたいな独自識別子を使わない。
現状のWicketが完璧とは言わないけど（メジャーとは言い難いし）、
その方向性はいいなと思える。
ViewはHTMLのテンプレートを使って
ロジックはどの言語でもいい、みたいなもの（Viewテンプレートとロジックのブリッジみたいなもの？）ができれば
言語やフレームワークごとにViewの独自タグや独自識別子を使い分けなくてよくなると思うんだけどな。
490:nobodyさん
08/05/10 12:08:18
即席で作るだけなら生書きの方が速いことも多いが
保守を考えるとフレームワーク使わないときついだろ
491:nobodyさん
08/05/10 22:09:04
>>485
> ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしい理由は？
DAOとしての面ではあるテーブルに対する操作が一つのクラスに集約されるから見通しが良くなるが。
492:nobodyさん
08/05/10 22:28:21
SQLって単体のテーブルごとにアクセスするものではないからだと思う。
パフォーマンスを考慮したSQLとの相性は悪いんじゃなかろうか。
493:nobodyさん
08/05/10 23:26:26
>>492
結合する処理をモデルに実装するから、そうでもないよ。
例えばユーザを結合したコメント一覧を取得するアクセスロジックをコメントモデルに持たせるとか。
ORMがアソシエーション機能を提供してたりもするし(あまり好きではないけど)。
Someモデルはsomeテーブル以外を知ってはならないということはないと思う。特にActiveRecordでは。
494:nobodyさん
08/05/11 00:27:11
runkitでaopみたいなことしたかったけど
セッションハンドラに登録したメソッド書き換えたら
segmantation fault出るようになった
やっぱまだ不安定なんだな・・・面白い拡張なんだが
495:nobodyさん
08/05/11 00:39:19
俺485。おまいらレスありがとう。
でも書いてもらった日本語がよくわからない。
俺もいいかげんな発言してたので、真面目に書き直しておく。
>>486
お前は本当にsfSmartyViewPluginを使ったのか？
sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
sfSmartyViewPluginがビューとロジックの分離における有効策と考えてるなら、
それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
symfonyは標準ではPHPの構文をテンプレートファイルに記述する。
確かにこの書き方だとHTML内にロジックが書けてしまうので束縛が無い事が嫌かも知れないが、
ビューにはビューを成立させるためのロジックがあっても良いと俺は考える。
496:nobodyさん
08/05/11 00:43:17
俺は485なんだけど441でもある。
>>485の後半に書いた事は>>484に言ったというより、過去のレスへの返答だった。
>>442
前者です。
>>443-444
自明だよな。その書き込みを見てほっとしたぜ。
ってことだった。
497:nobodyさん
08/05/11 00:50:47
つーか休まないと日本語処理能力が低下しまくっていかんな。
>>488
sfSmartyViewPluginよりもsymfony標準のテンプレート書式の方が優れている。
というか、sfSmartyViewPluginは完璧に使い物にならないと心底思う。
sfSmartyViewPluginは足かせにこそなれ、利便性は何も齎してくれない。
反論はあるだろうけど、ビューに制約を課す事とMVCを考慮する事は全く別だと思う。
>>491
結合とはある単一のテーブルが行う処理ではないから。
498:nobodyさん
08/05/11 01:04:31
一対一でマッピングされてるからって
そのテーブルに対して「のみ」のモデルじゃない
499:nobodyさん
08/05/11 03:58:08
いまだにsmartyとか言ってる意味がわからん
検討にすら値しないだろ
500:nobodyさん
08/05/11 04:09:26
結局viewヘルパってどれがいいんだろうな？
・関数
・クラスメソッド
・$this(viewクラスあるいはcontrollerクラスのインスタンス）のメソッド
・$this以外の、view空間にassignされたオブジェクトのメソッド
個人的には最後のものに可能性を感じるが・・・
状態を持ちやすい、動的に変化させやすいという意味で。
複数のクラスのメソッドを集めるmixin的な機能が要りそう。
そこがキレイにできれば・・
501:484
08/05/11 05:00:31
>>495
>>お前は本当にsfSmartyViewPluginを使ったのか？
>>sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
当たり前
>>それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
おまい日曜プログラマ？プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレート側にロジックかかれたら・・・・・後はわかるよな。
使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
502:nobodyさん
08/05/11 08:41:33
>>484
>symfony+smarty使ったことあるかい？
smartyで「デザインとロジックの分離」が実現できるとでも思ってるの? バカ?
>>485
> デザインにもロジックはあるのだよ。
そのとーり。WicketやMayaaやTapestryでは確かに「デザインとロジックの分離」ができるけど、smartyなんかじゃ全然できない。
>>488
> そうだね。でどうしろと？
おまえはなにもするな。smartyごときで「デザインとロジックの分離」とか偉そうに語るな。
> あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
完璧にほど遠いものをさも完璧なように語るおまえがバカなだけ。
PHPにはWicketもMayaaもないんだから、デザインの分離なんか考えるだけ無駄。
> もう少しバランス感覚養ったほうがいいんじゃないのか？
> 1か0じゃなくて、どちらのほうが優れているかで話をしろ。
他人の言葉をうのみにしているおまえこそ、もっと現実をみたほうがいい。
実現できてもないことに、1も0もないだろ。バッカじゃない?
503:nobodyさん
08/05/11 08:51:20
>>498
そういう解釈をいれないといけないあたり、相性が悪いんじゃないかと。
出来ないって話はしてないつもり。
そもそもモデリングってのは本質的ではないものを隠蔽したり相殺したりして
扱いやすくするものだと理解してるんだが、パフォーマンス的なことを考えると
SQLはそれ自体が本質的で、隠蔽されるべき対象ではないと思う。
機能的なことだけ考えれば良いのなら、SQLを隠蔽するのは正しいだろうけど、
それは贅沢だなぁって思う。
504:nobodyさん
08/05/11 09:50:03
モデリングの時点でオブジェクト間の関連は定義されるんだから相性が悪いということはないと思うけどな。
設計(仕様)上、記事テーブルがユーザテーブルに依存するなら、記事モデルがユーザモデル(テーブル)を知っていていいし、依存してもいい。
ただ、今までORMレイヤをリリースしてきた人達が「SQLを書かなくていいよ！楽チンだよ！」ってところを押しすぎたのは良くない。
複雑なフェッチが必要な場合はSQLを発行して結果を返すメソッドをモデルに持たせればいいのに、
「(極端に言えば)SQLを書いちゃいけない」という固定観念のもと、SQL以上に複雑な手続きによるフェッチだったり、
複数回SQLが発行されることを厭わない実装がある。
バランスとれればいいんじゃないかな。多くの部分ではSQL書かずに楽するし、SQLが必要なら(モデル内に)SQLを書く。
SQL書いたらORMが謳う「簡単なデータベースの切り替え」ができなくなるって？
大丈夫。開発中にデータベースが変更になることはまずないし、「ついで」程度の機能でしかない。
505:nobodyさん
08/05/11 13:40:27
オープンソースのフレームワーク開発ってどういうビジネスモデルなんだろ？
symfonyとかciは企業が作ってるけど
どこで利益あげてるのかな？
知名度を上げて受注を増やす形？
506:nobodyさん
08/05/11 14:20:23
ひょっとしてそれはギャグで（ｒｙ
507:nobodyさん
08/05/11 14:24:05
いやギャグじゃないよ
どこからか金が環流しないと時間と労力投入できないじゃん
508:nobodyさん
08/05/11 14:44:30
>>502
お前の言うデザインとロジックの分離っていうものはいったいどれぐらいのレベルを言ってるんだ
それにしてもヒステリックなやつだな
もうちょっと落ち着けよ
お前みたいな趣味でやっているやつにはMVCはいらないと思うけど現場では実際に必要とされてるんだよ