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

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

[前50を表示]
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も死亡だろｗ

次ページ