【PHP】フレームワー� ..
2:nobodyさん
07/06/09 10:11:32
>>1
乙
3:nobodyさん
07/06/09 10:39:24
↓以下Rubyを崇めるレス↓
4:nobodyさん
07/06/09 10:49:27
>>1
乙
5:nobodyさん
07/06/09 15:12:01
そろそろまともなフレームワーク整ってくれ。
php6まで無理かな？
6:nobodyさん
07/06/09 20:51:22
乙！
7:nobodyさん
07/06/10 00:40:05
おつ
8:nobodyさん
07/06/10 02:33:44
agaviのこと、おまえら忘れてない？
agaviのこと、おまえら忘れてない？
9:nobodyさん
07/06/10 02:34:47
phpspotとかで今頃「Mojavi復活！」って書いてるけど
ずっと前からあんな状態だっつの
10:nobodyさん
07/06/10 04:16:03
PHPってPapparapa Hentai Pugyaの略って本当ですか？
m9
ﾉ
ﾌﾟｷﾞｬｰ! (^Д^)
( ( 9m
< ＼
11:nobodyさん
07/06/10 06:45:40
“犯罪者のための言語”Rubyの作者が
作りの悪いウェブアプリの心配をするのが解せません
犯罪者がウェブアプリ作る方が危険じゃないでしょうか？
常識で考えて
12:nobodyさん
07/06/10 08:22:43
PHP on Rails
13:nobodyさん
07/06/10 09:12:06
DHHをもう一度PHPに振り向かせるにはどうしたらいいですか？
若い娘に乗り換えられて悔しいっ ﾋﾞｸﾋﾞｸ
14:nobodyさん
07/06/10 11:20:45 g9vmzoll
>>9
だよな。何を今さら・・って思った。
15:nobodyさん
07/06/10 11:59:43
てかさぁ、テンプレでフレームワーク一覧くらい書けよ。
16:nobodyさん
07/06/10 12:04:21 g9vmzoll
>>15
どこまで入れるの？
17:nobodyさん
07/06/10 12:22:11
フレームワークの使い方がわかんないんだけど＞＜
18:nobodyさん
07/06/10 15:11:38
Railsはオンラインで読めるドキュメントが少ないのが
ちょっとね。紙の本だとどうしても翻訳が遅くなってしまうし、
APIのリファレンスも見づらい。
とりあえず今すぐ何かフレームワーク使いたいなら
やっぱりPHPかなって気もする。
19:nobodyさん
07/06/10 19:44:27
若い娘っていうか、PHPの方が若いけどな。年齢的には。
20:nobodyさん
07/06/10 20:42:13
PHPは誰にでも股開くイメージ
21:nobodyさん
07/06/10 21:12:48
童貞を捨てるには丁度いいじゃないか。
つまりは、入門者には最適。
22:nobodyさん
07/06/10 23:48:11 g9vmzoll
おまけに中田氏自由
23:nobodyさん
07/06/11 00:08:43
>>18
RailsのAPIのリファレンスは結構というか超使えると思うが...
あのレベルのリファレンスマニュアルがPHPのフレームワークにも欲しい。
24:nobodyさん
07/06/11 00:13:00
ＺＦのドキュメントは判りやすいと思うよ
25:nobodyさん
07/06/11 02:00:08
やっぱ日本男児なら日本で開発されたRubyを一度はやっておくべきだろう
26:nobodyさん
07/06/11 03:08:20
awkが最強
27:nobodyさん
07/06/11 04:03:42
Matzがアメリカナイズされているから日本男児ではない。よってRubyも所詮は異国のものだ
28:nobodyさん
07/06/11 05:28:18
日本男児を標榜するなら
なでしことか言う奴使えや
29:nobodyさん
07/06/11 08:42:41
やっぱ日本男児なら日本で開発されたなでしこを一度はやっておくべきだろう
30:nobodyさん
07/06/11 08:45:13
やっぱ日本女児なら日本で開発されたなでしこを一度はやっておくべきだろう
31:nobodyさん
07/06/11 08:48:35
日本男児ならますらおをやるべき
32:nobodyさん
07/06/11 09:07:19
PHP on Rails
33:nobodyさん
07/06/12 00:35:26
URLﾘﾝｸ(classic.guesswork.jp)
これってどうなん？
規模の小さい開発をPHPでって時は
こういうののほうが便利かな
34:nobodyさん
07/06/12 00:41:44
php4かつ小規模ならいいのでは
35:nobodyさん
07/06/12 02:30:23
PHP嫌いのヒゲはブログで紹介してる本本当に全部読んでんのか？
どんな速読法マスターだよ
36:nobodyさん
07/06/12 04:19:12
>>35
>どんな速読法マスターだよ
URLﾘﾝｸ(netafull.net)
これみとけ
37:nobodyさん
07/06/12 06:42:39
>>36
それはもともと10分で理解できる程度の内容の本だっただけでは・・・
38:nobodyさん
07/06/12 09:05:51
10分で読めって言われれば、実用情報程度の新書なら
本読みなら読めるでしょ。速読法とか関係ない。
39:nobodyさん
07/06/12 11:29:45
ダニー?
・・・ダニ?
・・・・・・ｷﾓｽ
40:nobodyさん
07/06/12 17:32:02
髭とかどうでもいいよ。
オブジェクト脳のないやつはほっとけ。
41:nobodyさん
07/06/13 00:02:56
,, -─- ､._
．-"´ ＼．
：/ _ノ ヽ､_ ヽ.： PHPerがオブジェクト脳て・・・
：/ oﾟ(（●）) (（●）)ﾟoヽ：
：| （__人__） |：
：l ) ( l：
：` ､ `ー' /：
：, -‐ (_). ／
：ｌ_ｊ_ｊ_ｊ と)丶─‐┬．''´
：ヽ ：i |：
：/ ：⊂ノ|：
42:nobodyさん
07/06/13 00:26:36
子飼はIQが高いらしいし、速読とかも出来るのかモナ。
しかし、>>40-4１の流れがツボに入った。
43:nobodyさん
07/06/13 01:56:37
ここで本人が一言
↓↓↓ドゾー
44:nobodyさん
07/06/13 02:04:10
Perl>>>>>>>>>>>>>c>>Ruby>>Python>>PHP
m9(^Д^)ﾌﾟｷﾞｬｰｰｰｯ
45:nobodyさん
07/06/13 02:43:43
>>44
お前程度の認識の奴はPHPのHTML埋め込み部分以外は全部挫折。
Cはかじっただけ。Javaすら知らず、すでに30過ぎ。
何も出来ないからRubyやPython先取りしようと
手をだすけれど全部中途半端。
出来るのはPerlで掲示板レベルで止まってる。
向いてないから転職先探せよm9(^Д^)
46:nobodyさん
07/06/13 06:23:08
選択肢多すぎて、知識が陳腐かするのが早すぎる
47:nobodyさん
07/06/13 08:45:54
Cはこの先１０年くらい最低安泰だろ。
48:nobodyさん
07/06/13 08:49:12
>>47 Cは今後も安泰だと思うが、Cの使い道をおしえてくれ
49:nobodyさん
07/06/13 08:57:22
他言語を学ぶ上で確実な土台になる。
これからどんな新しい技術が出てきても、Cで得た知識や経験は無駄にならないだろ。
PerlもPHPもCから来てる品。
50:nobodyさん
07/06/13 11:42:00
>>48
画像処理とかハードに近い部分とかではまだまだ一般的だと思うが。
51:nobodyさん
07/06/13 12:36:17
組み込み系もほぼC言語だな。Javaもあるけど
52:nobodyさん
07/06/13 12:53:45
素朴な疑問なんだが
なんでc++で作らないの？
遅くなるの？
53:nobodyさん
07/06/13 13:07:42
ソフトウェア作るときはC++じゃないのか？
組み込みはそこまで複雑ではないからCでいけるのでは？
54:nobodyさん
07/06/13 14:47:12
C++はウンコ
55:nobodyさん
07/06/14 04:50:17
PHP５で書かれた軽量のフレームワークって何があるかな？
ちいたんくらいがベストなんだが、PHP４だしな。
ZENDはちょっと重過ぎる。
56:nobodyさん
07/06/14 05:22:44
zendが重いとなると、他のフレームワークは難しいんじゃないかな。
だいぶ前に触ったときは「必要になった時に必要なものを使う」という感じだったから、コード量は少し多くても随分速かった。
他のPHPフレームワークと比べてね。
といっても最近のzendはいじってないから分かんないけど。
57:nobodyさん
07/06/14 05:22:52
CIはPHP4/5でわりと軽いけど
PHP5専用ってのはないね
58:nobodyさん
07/06/14 06:14:56
>>54
どのへんが？
59:nobodyさん
07/06/14 08:06:43
>>56
ごめん、書き方が悪かった。
重いってのは動作というより、ライブラリの分量って意味で言ったんだ。
確かにZENDは好きなとこだけ使えるから、軽いって言えるのかもね。
>>57
CIはいいね。
60:nobodyさん
07/06/14 12:52:54
ちいたんは、PHP4/5 割と高速ですよ。
61:nobodyさん
07/06/14 13:43:56
>>60
俺は>>55と>>59なんだ。>>55も読んでから教えてくれ。
62:nobodyさん
07/06/14 14:01:41
単なる疑問なんだけど，4 で動くように書かれてても，
5 でも動くなら 5 で使えばいい気がするんだけど，ちいたんを 5 で使うと何かデメリットがあるの？
フレームワークは 4 用で，自分で書くコードは 5 で書けばいい，ってわけにはいかないのかな？
フレームワークレベルで例外とかの仕組みがサポートされていない，とかはデメリットになるかもな……
63:nobodyさん
07/06/14 15:18:34
>>61 まずは試すことだよ
64:nobodyさん
07/06/14 19:47:08
おまいら、
for ($i = 0; $i<count($my_array); $i++)
instead, we try to always do:
for ($i = 0, $count = count($my_array); $i<$count; $i++)
この違いがわかるか！
URLﾘﾝｸ(www.symfony-project.com)
65:nobodyさん
07/06/14 21:54:12
効率化の方法か？
66:nobodyさん
07/06/14 22:32:10
CodeIgniter使い方が分りやすくていいね。
名前って大事だよね
67:nobodyさん
07/06/14 22:49:54
>>64
URLﾘﾝｸ(www.symfony-project.com)
「symfonyは遅い遅いとかいってるやつ、よーく聞けや、
実際最適化されていないかっていうとそういうわけでもない、
っていうかおまえらHello worldのベンチが遅いって言うけどさ、
FWの速さをHello worldのベンチ結果ひとつで比べんなっつーのｗｗｗ
あのな、FWにおいて速さは一番大事な話じゃねーんだよ、
Hello worldベンチが遅いからsymfonyはダメってやつはバカ」
by フランチョス
68:nobodyさん
07/06/14 23:47:27
Symfonyは速度以外の面で
特にどういうところにメリットが大きいとお考えで？
69:nobodyさん
07/06/15 10:37:29
たかがHalloWorld程度の処理で遅さを露呈するSymfonyがダメダメなのは当たり前じゃないか。
フランチョスは馬鹿だな。
70:nobodyさん
07/06/15 11:05:04
>>67
すっげー重いビジネスロジックが
FWの違いだけで軽くなるならいくらでも使うさ。
所詮、大差なしｗｗｗ
71:nobodyさん
07/06/15 11:06:08
HelloWorld最速のC最強!!
PHPなんてゴミカス
72:nobodyさん
07/06/15 11:47:45
URLﾘﾝｸ(userguide.cilab.info)
CodeIgniter ユーザガイド 日本語版 Version 1.5.3
和訳してくれた方どうもありがとうです。
CIの説明を読んだら俺でも理解できました。
これでやっとフレームワークデビューできそうですｗ＼(^o^)／
73:nobodyさん
07/06/16 17:57:10
cakeかCIかZendか・・・
74:nobodyさん
07/06/16 18:47:45
翻訳されないと読めないって、英語できないと大変だな。
一応義務教育で英語習ってなかったのか？
C++で作られたOSってまだ無いしな。
75:nobodyさん
07/06/16 20:01:32
>>74
WindowsやClassic Mac OSは無視ですかそうですか。
76:nobodyさん
07/06/16 20:43:48
どっちもソース読んだことないし
77:nobodyさん
07/06/16 20:56:55 Zcz+cnSv
>>75
Linuxも無視だなｗ
78:nobodyさん
07/06/16 21:20:48
処理の最適化が必要なOSの下層レイヤーは普通Cでかくわな
79:nobodyさん
07/06/16 22:39:29
>>74
MonaOSは？
80:nobodyさん
07/06/17 13:49:53
PHPもCで書かれてるの？
なんでC++で書かないの？
81:nobodyさん
07/06/17 15:30:20
symfony言うほど遅い気はしないけどな。
前は確かに言うほど遅かった気がするが。
フレームワークとしてしっかり出来ているとは思う。
別に擁護するわけではないです。
82:nobodyさん
07/06/17 16:12:12
>>81
あれっ、俺すげー前のバージョン試してクソ遅かったから使うのやめたんだが、
いつのまにか速くなってたんだ。
どのあたりのバージョンから実行速度改善したんだろ・・
83:nobodyさん
07/06/17 21:13:31
C と C++ って，単純に「新しいしオブジェクト指向だから後者の方が良い言語」って話ではないからな……
Objective C だったらそう言えたんだろうか。知らんけど。
84:nobodyさん
07/06/17 21:18:15
>>83
Objective Cは動的型付け言語
85:nobodyさん
07/06/18 05:07:11
>>82
development環境は今でもクソ遅い。
production環境ならそれなりの速度は出てる。キャッシュしまくりだから。
でも俺はそのキャッシュしまくりなのがちょっと嫌い。
86:nobodyさん
07/06/19 00:38:56
agavi 0.11RC5リリース
87:nobodyさん
07/06/19 02:14:58
>>86
うほ！！まだ更新してたんだｗ
88:nobodyさん
07/06/19 02:17:32
>>81
symfonyは初期設定が面倒だな。
自分は慣れてるからさっさとできるが、
よくヒーヒー言う初心者の声を耳にする。
それを乗り越えた後のadmin generatorに感動しまくる声もね。
89:nobodyさん
07/06/19 19:24:28
frontend_devってそんなに遅いか！？
90:nobodyさん
07/06/19 23:12:36 vt1ydhWm
xdebug有効にしてるとか
91:nobodyさん
07/06/20 05:54:33
フランチョスが「symfony遅いって言う奴は馬鹿」ってわざわざ言うくらいだから
遅いって批判は結構あるんだろう
92:nobodyさん
07/06/22 10:24:23 58srRoch
おまえら、Ethnaの本もうすぐだぞ！
表紙かっこいい。オレ買うかもしんない。
URLﾘﾝｸ(www.cbook24.com)
93:nobodyさん
07/06/22 11:05:13
こんな本書いてる暇があったらDBレイヤ周りもっと完成度上げろや
94:nobodyさん
07/06/22 13:02:35 58srRoch
>>93
PDO使えばいいじゃん
95:nobodyさん
07/06/22 13:38:23
俺Ethna+Syrupだけど
結構いいかんじ
96:nobodyさん
07/06/22 21:24:49
普通にcakeが出て欲しい
97:nobodyさん
07/06/22 21:46:26
本なんて無くても使ってれば分かるだろｗ
98:nobodyさん
07/06/23 00:10:00 nbx08fep
ZF希望
99:nobodyさん
07/06/23 03:07:18
いや本にまとまると安心すんだよ、情報の漏れがないかとか。
あとやっぱ本が手に持てて見やすい。
100:nobodyさん
07/06/23 03:48:23
うん、本があるほうがはかどることもあるよね。
101:nobodyさん
07/06/24 03:07:17
wikiにまとまってた方がいいな。
本じゃキーワード検索できん
102:nobodyさん
07/06/24 15:43:19
そもそも、Ethna本、宣伝してる奴って、誰なんだ？
103:nobodyさん
07/06/24 15:59:47
著者 出版関係者 狂信者
104:nobodyさん
07/06/24 16:11:56
作者 書籍小売店 アフィリエイター
105:nobodyさん
07/06/24 17:30:26 SHnW2+KS
>>102
俺だよ俺
106:nobodyさん
07/06/24 17:48:52
>>105
胸がスッとしたぜ
107:nobodyさん
07/06/24 17:52:54
やるじゃねえか
108:105
07/06/24 18:17:04 SHnW2+KS
あぁ、、宣伝と取られたか。
俺自身、Ethnaってまだ使った事ないんだよね。
でも、本が発売されるって事で、ちょっとテンション上がって
ついつい貼っちゃったんだ。今後とも、自重するよ。
ちなみに俺はZendFrameworkに期待してる。
みんなごめんよ。本当にごめんにょ。
109:105
07/06/24 18:18:51 SHnW2+KS
うわ・・・ひどい日本語
110:nobodyさん
07/06/24 20:30:29
Ethnaとか終わってます。
111:nobodyさん
07/06/24 21:33:47
その本のvol.1がTurboGears X Pythonで、
vol.2がEthna x PHPという理由も良く分からん。
なんかのムックを単行本したのか？
ちなみになぜか俺vol.1買った。
内容は、まあページ数とサイズを考えれば
しゃーねーべ、、という感じ
Ethnaのほうは知らないが、そのページ数でPEAR , Smarty
PHPのインスコからMVCとは何か、認証まで言及してると
駆け足になりそうな予感。
でも本屋にあったら見てみるわ
112:nobodyさん
07/06/24 22:15:46
>>92
いいなー、買おうかな。
113:nobodyさん
07/06/25 12:08:35 2mWhEXtz
vol.2って何の事だと思ったら、vol.1はPythonだったのね。
需要あんのかな？
114:nobodyさん
07/06/25 18:05:23
「需要なさそうな所を突く解説書シリーズ Vol.2」なんじゃね
115:nobodyさん
07/06/25 18:41:08 2mWhEXtz
>>114
な～るへそ。
じゃあ、第3弾はCatalystだな。
でも、Catalystの方が重要あるか。
116:nobodyさん
07/06/25 19:25:32
CatalystならまだしもEthnaはないよな。
まぁ日本発で一番使われてるFWだからかな。
117:nobodyさん
07/06/25 19:41:49
出版社同じだし、
URLﾘﾝｸ(7andy.yahoo.co.jp)
のムックの売上見て単行本化決めたのではと思われ
なのでCatalystはありうる。そして次はMaple で最後にRoRだ。
わけわからん
118:nobodyさん
07/06/25 19:46:22
Mapleとか。。
119:nobodyさん
07/06/25 21:42:04
DjangoとPieceも...
120:nobodyさん
07/06/25 22:52:32 2mWhEXtz
Mapleって開発譲渡したんじゃないの？
121:nobodyさん
07/06/26 01:27:55
Mapleは開発放棄じゃないの？
てか開発者が行方不明とか？
違う人間がMapleのコードで違うプロジェクト始めたんじゃ？
どっちにしろ、終わってるな。
122:nobodyさん
07/06/26 02:43:19
作者に放棄→それを引き継ごうとした開発者も放棄
って流れだったと思う
二度捨てられた不憫な子＝Mapleたん
123:nobodyさん
07/06/26 12:41:14 +m1wrnTY
・・・かわうそう
124:nobodyさん
07/06/26 13:03:43 PKXMvhY5
フレームワーク使ったことない俺が言うのもなんだげど
PEARってフレームワークだよな？
125:nobodyさん
07/06/26 14:32:57
zendは1.0なのにRC1,2,3とか
このままRC99まで行くつもりなのか！？
126:nobodyさん
07/06/26 14:34:55 +m1wrnTY
>>124
lib
127:nobodyさん
07/06/26 18:16:12
>>124
PEAR は PHP のクラスライブラリを統合して統一的に扱うためのフレームワークだけど，
ここのスレでいうフレームワークって
「Web アプリケーション フレームワーク」に狭義に絞ってる気がするので
そういう意味では違うかもしれん．
128:nobodyさん
07/06/27 02:16:36
>>124
HTML_QuickFormはプチフレームワークかもしれん。
実装が腐ってるから、もういまから新規で覚えてもしゃーないけどね。
129:nobodyさん
07/06/27 14:51:55 54iUTIH0
Ethnaの本買ってきたぞ。
まだ、中身読んでないけど、今後のフレームワーク本の出版予定が書いてあったので、
一応知らせておく。gihyoから「Symfony×PHP」「Django×Python」が出る予定だそうだ。
Symfonyはいいにしても・・・Djangoって。
130:nobodyさん
07/06/27 15:15:36
RailsやったことあるやつはCakeがおすすめ。
131:nobodyさん
07/06/27 15:19:45
>>129
ジャンゴは檄速だっつの
ドジでのろまな亀のPHPフレームワーク乙
132:nobodyさん
07/06/27 16:20:56
>ドジでのろまな亀
歳がばれるぞw
133:nobodyさん
07/06/27 16:52:00
>>132
実の息子かもしれんぞ
134:nobodyさん
07/06/27 20:46:21
Cake使うならRails使ったほうがよいと思われ
135:nobodyさん
07/06/27 21:08:37
>>134
その通りかもしれないがスレ違いによるループが確実
136:nobodyさん
07/06/27 21:58:01
Ethna本読んだが、結論から言うと買う必要なし。
ネットであれ以上の情報がすぐに手に入る。
本で読みたい人にはいいかも。
500円くらいの価値はある。
137:nobodyさん
07/06/28 16:57:01 b86P8EwS
>>134
Railsは本番環境への移行がめんどすぎる。
それに加えてシェアRuby<PHPを考慮するとCakeの大勝利。
138:nobodyさん
07/06/28 17:01:05
漏れもいろいろ理由付けてRails使わないでいたけど、
1回使ったら陥落しますた。
今はお客さんの希望に合わせてRails > Symfony > Cake
という感じで、やってます。
139:nobodyさん
07/06/28 17:41:26
>>137
>Railsは本番環境への移行がめんどすぎる。
それって具体的にどういうこと？
140:nobodyさん
07/06/28 18:10:36 b86P8EwS
>>139
Cakeみたいにフォルダコピーするだけでほとんど完了。ってわけにはいかない。
Railsのサーバ使うわけにはいかないし、cgiじゃ遅いし、fastcgiはめんどくさい。
141:nobodyさん
07/06/28 18:13:59
たいしてめんどくさくもねえし。
142:nobodyさん
07/06/28 18:17:08
Railsってrsyncでデプロイする機能があったような。
143:nobodyさん
07/06/28 18:59:49
>>141
初級～中級者には敷居高いと思うよ
144:nobodyさん
07/06/28 21:59:56
まぁたしかにPHP環境ほど簡単というわけじゃないですね。
サーバが全てDebianってわけじゃないですから。
145:nobodyさん
07/06/28 22:50:03
＞初級～中級者
の範囲がわからんけど、そういうのはFWを使うのがそもそも間違いでしょ
146:nobodyさん
07/06/28 23:41:53
上級者にしか使えないならほとんど使われてねぇよ
147:nobodyさん
07/06/29 00:04:14
そんなこたーない
148:nobodyさん
07/06/29 01:24:39
んなこたーないなんて言ってしまうと、世の中上級者ばかりになってしまう。
149:nobodyさん
07/06/29 01:38:41
フレームワークは中級程度が一番使うべき。
初級者は使えないと思うが。
150:nobodyさん
07/06/29 10:08:02
フレームワークこそ初心者のもんだろ。
何やってるんだかわからないアホでも、それなりに組めてしまうんだから。
151:nobodyさん
07/06/29 11:05:43
組めるレベルは中級っていうんじゃないのか。
個人の感覚の違いだから、それ以上はつっこまないが、言葉の表面じゃなく意味するとこを読み取ってほしいな。
152:nobodyさん
07/06/29 14:00:33
初級とか中級とか絶対指標がないから掲示板の議論には向かない表現だなと思った
本心では「中級こそ使うべき」と思ってても
その中級を初級呼ばわりすることで
「そういう自分＝上級」感を味わいたい奴とかもいると思うんだ
153:nobodyさん
07/06/29 14:17:38
>>151
俺の基準だと
初級者：ちょっとだけできる（仕事でやるのはしんどいレベル。）
中級者：普通にできる（普通に仕事でやっていけるレベル。真ん中のグレード。）
上級者：何でもできる（周りのプログラマからすげーって言われるレベル。）
この基準だと、初級者はフレームワークなしじゃ、まともに動くものは何一つ作れない。
154:nobodyさん
07/06/29 15:33:32
初級者にはMVCのアーキテクチャは理解できない
↓
理解せずに使うと必ずどっか壁にぶち当たる
↓
結局使えない
155:nobodyさん
07/06/29 18:35:27
>>152
まさに、その通りだと思う。
上級なんて・・・世界を見ろよといいたい(日本にも数十人はいると思うが)。
まぁ、152に賛成してこれを言うのもなんだと思うが。すまない。
156:nobodyさん
07/06/29 21:02:41
WebフレームワークってコントローラーとDB操作する部分とHTML表示する部分とを切り分けてるだけじゃん。
オブジェクト指向の理解なんて必要ない。
157:nobodyさん
07/06/29 21:14:22
オブジェクト指向の話なんか出てない
158:nobodyさん
07/06/29 22:10:29 u0ng+pVR
>>156
おまえこそ、オブジェクト指向わかってのかｗ
159:nobodyさん
07/06/30 03:42:49
>>158
156の言ってることは深いぞ。
160:nobodyさん
07/07/01 05:07:50
確かにな。純粋なオブジェクトで出来てないJAVAやPHPなどでオブジェクト指向は出来ないかも知れない。少なくともWebフレームワークはオブジェクト指向の理解はいらんな。
やはりRubyあたりがオブジェクト指向が語れる（実現できる）言語かな。
161:nobodyさん
07/07/01 09:54:22
いやべつにそんな話題は出てないのにレス書いたバカがいるというだけの話だが
162:nobodyさん
07/07/01 11:46:11
このスレはオブジェクト指向を語るスレになりました
163:nobodyさん
07/07/01 20:44:17
俺のちんこは素敵なオブジェ
164:nobodyさん
07/07/01 22:26:55
オブジェクト指向分からずしてフレームワークは使えない品
165:nobodyさん
07/07/01 22:58:59
まあオレオレFW作ってるひとは当然OOPしてるんだろうな
既製のFW使うのに、クラスが何なのかくらいは知らんとムリだが
GoFだのなんだのって話になるわけでもあるまい
166:nobodyさん
07/07/01 23:51:37 KBDlHz5H
オレオレFW作れるだけまだ上等だろう
167:nobodyさん
07/07/02 01:38:45
PHPでFWなんてそのうち時代遅れになるよ。
MyPHPAdminより高機能なDBオーサリングツールがついて
Flashみたいにオブジェクトをクリックして、プロパティの種類と名前追加して
自分でprotectedとかextendsとか何度も書かなくて良いようになる。
親クラスやインターフェースなんかを図でつなぐだけ。
FWみたいに実行環境でそのまま使われるモノではなくて
最適化したモノが書き出されるようになる。
編集するときはプロジェクトファイルで行うようになる。
フォームもドラッグアンドドロップでnameやaction指定して
typeを選ぶだけ。勿論DBと連動させられる。
マニュアルで記述もできる。
オブジェクトは、ECMAスクリプトと連動する事もできて、自由自在に
デスクトップGUIアプリのようにデザインすることも出来る。
来春発売で10万。
楽しみにしててくれ。
168:nobodyさん
07/07/02 03:58:47
Delphyか。
169:nobodyさん
07/07/02 05:09:34
Java系のIDEでもFlex BuilderでもVS.NETでも既にやってるし、いまさら自慢気に言うほどのものでもないよね。
170:nobodyさん
07/07/02 09:59:36
>>167 もうでてるじゃん。 Delphi for PHP
171:nobodyさん
07/07/03 01:57:35
先生質問！
いつも1人でｵﾚｵﾚFW使ってるんだが、ちょっと人と並行して作業する事になって、
さすがにｵﾚのじゃ申し訳ないって思ってるところ。
初見ではCakePHPかCodeIgniterが良さそうな印象なんだけど、
実際の使用感とか感想とかあったら参考にさせて欲しい～、お願いします。
172:nobodyさん
07/07/03 03:28:50
オマイが決めていいんならオレオレでもいいんじゃね？
173:nobodyさん
07/07/03 06:30:50
怠惰なやつにただで情報与えるのは気が進まないが、他の人の参考にもなるかもしれないから俺の使用感をメモっておく。
Cakeはデータベースとのアソシエーションが覚えるとやはり便利。外部ライブラリと併用すれば十分使える。実績も出てきた。
CIは、そのアソシエーションを削ることでよりシンプルにした感じ。Cake同様に他の機能も十分なので、FWとして合格点。
174:nobodyさん
07/07/03 18:38:43
>>173
そんな情報いらないよ(w
175:nobodyさん
07/07/03 19:01:16
>>173
俺FWはSymfonyしか使ったことないんだけど、DBからデータ持ってくるのは
やっぱりSQL文直書きしちゃうなぁ・・・。
SQL書かないと、後で見たときすごい解りにくくない？
でも、SQL文がPHP内に混じるとやっぱり汚いね。
PHP版S2Daoの、2way SQLが良さそうなんだけど、時間ないのでまだ見れてない。
includeするファイルが多くなり過ぎて、Symfonyと併せるとすっごい遅くなりそうな気もする。
そうなると、CIと組み合わせた方が良いのかな？
176:nobodyさん
07/07/03 23:05:23
ちょっとややこしくなると、結局同じようにややこしかったりするし、
SQL自体がそもそも簡便に抽象化されたものとしてあるんだから、
プレースホルダを使ったりするくらいでも別にいいよな。
177:nobodyさん
07/07/03 23:33:46
同意。
無駄にプァイル多くなるし。
あとから参照しずらい。
178:nobodyさん
07/07/04 00:02:35
まあCIのactive recordは使い物にならんから、SQLガチガチ書きたい奴はある意味お勧め。
179:nobodyさん
07/07/04 00:15:23
>>178のカキコも使いもんにならんから目を汚したいヤツには違う意味でお勧め。
180:nobodyさん
07/07/04 03:43:53
情報出さないで文句ばっかいってる生産性のないやつがいるな。
>>175
Symfonyは使ったことないけど、Cakeの方がシンプルだということだからもっとみやすいんじゃない？
Cakeは慣れれば、一目見ただけでどんなデータとってきてるか分かるよ。
SQL文書くならRailsを模倣してるSymfonyとかCakeとか使わないで違うＦＷ使うべきなんじゃないかと思うけど。
181:nobodyさん
07/07/04 09:20:11
Cakeとsymfonyやったらどっちのほうが覚えやすい？
182:nobodyさん
07/07/04 13:18:56
railsはDB操作レイヤーといえばORMというような、間違った風潮を作ったね。
183:nobodyさん
07/07/04 13:20:14
一見コード量から言えばCakeの方が「覚えやす」そうだけど、
symfonyの方が業務にすぐ使えるだろうね。
「覚える」ことは必要ないし。マニュアルにしたがってサクサクという感じで進むよ。
それと引き換えに「退屈さ」に耐えなければならない、という感じ。
横道にそれながらも楽しんで仕事したいならCake。
184:nobodyさん
07/07/04 14:51:32
>>181 業務ならCake 趣味ならSymfony (Cakeは4,5対応ということだけで、別に悪意はないから)
185:nobodyさん
07/07/04 17:50:11 PWYSy+4p
退屈な方がいいよね
186:nobodyさん
07/07/04 19:11:13
ああ、そう思う。仕事はそういうもんだな。
187:nobodyさん
07/07/06 02:47:18
>>184
逆だな。
今更4なんて実用に耐えないから、両対応にして精度落としてるcakeは趣味にしか使えん。
188:nobodyさん
07/07/06 04:09:17
精度なんか落ちてないぞ。4と5に対応できるようにコードを裏側で切り替えてるだけ。
普通に優れてる
189:nobodyさん
07/07/06 09:49:02
>>187
精度って何の精度？
190:nobodyさん
07/07/06 09:59:30
業務でSymfony使えばいいじゃない。 使いたい人は・・・。
191:nobodyさん
07/07/06 10:00:04
むしろsymfonyが趣味にしか使えないというところに、突っ込むべきかと。
ありえんだろ。
192:nobodyさん
07/07/06 10:17:04
symfonyは趣味にはキツいな。どんなマゾやねん
193:nobodyさん
07/07/06 20:14:10
〉189
性能といいたいのだと思われ
194:nobodyさん
07/07/06 22:44:53
趣味でやるなら、cakeかEthna。
仕事はsymfony。
仕事ならサーバー構築からできるからphp5を選択できるけど、趣味だと安いサーバーを借りたりするので
php4で動くやつの方がいい。
195:nobodyさん
07/07/06 23:27:00
>>194 のような趣味のような仕事をしてみたい。
196:nobodyさん
07/07/07 05:07:04 1nTQ87n9
まず趣味で色々使ってみる。
そして自分なりのFAを出す。
それを仕事の現場で推薦する。
通らないこともあるが自分はこうしてる。
「2chで支持されてたので、これ使います。」
じゃまずいだろ。ｗ
197:nobodyさん
07/07/07 06:05:50
URLﾘﾝｸ(www.symfony-project.com)
ﾌﾗﾝﾁｮｽ「PHP4 is dead! いまどきPHP4にも対応してる中途半端なCakeはﾌﾟｷﾞｬｰものだ」
198:nobodyさん
07/07/07 08:49:30
正直、symfonyは機能をあれこれ盛り込んでるから
そこそこ利用出来るようになるまで時間が掛かりすぎる & ソースが見難い。
199:nobodyさん
07/07/07 10:08:07
>>198
よくそういう意見を聞くけど、まずは自分が使いたいと思う機能だけ
使っていけば、複雑でも何でもないんじゃないかと思うんだが、どう？
ソースについても、Cakeの方が汚いと聞いた事はあるが、確認はしてないなぁ。
あ、見難いと汚いは違うか？
200:nobodyさん
07/07/07 10:13:33
うん、むしろ、なにも考えずに使えてしまうよ。
symfonyに実装されてる機能を「そこそこ利用できる」学習する時間
＜Cake（とかCIとかライトウエイトのＦＷ）を使って自作点検する時間
って感じだから、symfonyは「退屈」なのよ。でもそれくらいならsymfony
よりは今後はＺＦ使いたい気がする。
201:nobodyさん
07/07/07 11:01:17
ZFはあんだけ時間かけてあのザマだからなあ
202:nobodyさん
07/07/07 11:10:13
ん、ZFわるくないじゃん。機能もそろってるし。
どこが「あのザマ」なの？
203:nobodyさん
07/07/07 11:30:41
ZFがJAVAライクなフレームワークになってるのも分からず、叩きたがってる中二病なので、ご勘弁ください。
204:nobodyさん
07/07/07 11:32:56
ZFはフレームワークって言うより
ライブラリ感が強いから
自前で用意しなきゃいけないことが多い
ソースは読みやすい
205:nobodyさん
07/07/07 11:45:21
symfonyあたりからZF見て足らないっていう部分が、
本当にＦＷの必須要素なのかが疑問だけどね。
206:nobodyさん
07/07/07 12:53:56
別にsymfonyを叩きたいわけじゃないがsymfony信者多いな
207:nobodyさん
07/07/07 13:00:32
PHP4って今でも多くのサイトで使われてるだろ。
PHP5はメモリを食いすぎるからね。
シンフォニーみたいな高機能なフレームワークはエクステンション化しないと実用的でないね。
208:nobodyさん
07/07/07 14:28:41
> PHP5はメモリを食いすぎるからね。
具体的な数字希望
209:nobodyさん
07/07/07 15:16:07
海外国内問わずPHP4互換のFW未だにアップデートし続ける
FWの作者に告ぐ、はっきり言って老害だ、とっとと辞めてくれ
少しでもPHPの未来を考える気があるなら
そのサポート対象から4を切れ、今すぐに
そしてその4互換FWで未だに4のコードを書きつづけるユーザの人達、
4のコードでそのFWの使い方やサンプルをブログに書きつづける人達、
5のサポートをしないレンタルサーバ管理者の人達、
どうか心改めこれから5をインストールして5のコードを書くか
PHPを捨て去るかどちらかを選択して欲しい
これ以上4のコードを生産するべきではない
これ以上4のコードを書く人間を生産するべきではない
これ以上4のコードを書く人間を放置していてはいけない
PHPユーザは尊厳の意をもって4を葬り去るべき
210:nobodyさん
07/07/07 15:51:51
>>209
4のコードはたいがい5でも動くだろ・・。
5を普及させたいなら、レンサバ屋に5を入れるように頼んどけ。
そして君は自分の愚かさを自覚してもっと謙虚になりなさい。
211:nobodyさん
07/07/07 15:57:10
仕事であの中途半端なオブジェクト指向をさわりたくない。
212:nobodyさん
07/07/07 16:45:01 ORHn68Tc
PHP5は最近レンサバでも入ってるよ。
ってか、最近は最悪でもVPS以上を使わせることにしてる。
213:nobodyさん
07/07/07 22:00:26 9N+o65yz
最近symfony使い始めて、掲示板なんか試しにつくってみたけどさ、
設定ファイルでだいたいの調整ができるから、実際のビジネスに使う
には、結構いいんでは？
ビジネスでは、スピードよりも保守性が重んじられることも多いから…。
214:nobodyさん
07/07/07 22:12:49
そうね。
何年も保守していくことを考えると、今さらphp4 てどうだろう。。
ていうか数年先にphpはどうなっているんだろうか。
215:nobodyさん
07/07/07 23:46:32
php6でまた仕様が変わってうんざりしてrubyに
216:nobodyさん
07/07/08 01:50:14
ruby 2 で仕様が変わってうんざりして pythonに
217:nobodyさん
07/07/08 01:55:49
一方perlはのんびりと静かに暮らしていた
218:nobodyさん
07/07/08 03:09:35
>>214
そもそもweb業界なんてリアルタイムで変わるものなんで
数年先なんて考えるだけ無駄。
219:nobodyさん
07/07/08 05:34:20
209の駄文にワラタ(笑)
220:nobodyさん
07/07/08 12:19:25
PHP4 is dead, long live PHP5!
221:nobodyさん
07/07/08 12:22:42
次のPHPにレキシカル変数、パッケージが導入されない限り、軽いPHP4で十分だな。
222:nobodyさん
07/07/08 13:46:19
php4が軽いとか思ってる奴まだ居たんだ…
223:nobodyさん
07/07/08 15:11:30
軽いPHP4で十分だよ！
224:nobodyさん
07/07/08 15:53:46
>>222
php4が軽いとか思ってるのではなく、軽いPHP4で十分なのではないか？
225:nobodyさん
07/07/08 16:23:47
じゃあ軽いPHP5でいいじゃん
226:nobodyさん
07/07/08 19:31:40
>>208
ペチパーは自分で調べることが出来ないのかねえ。
↓これでPHP4と5で計ってみろ。
ps -eo vsz,command | grep httpd | awk '{sum+=$1}END{print sum}'
PHP5はこのでっぷり太ったプロセスでHTMLも画像も処理しないといけないんだ。
もっともYahooみたいにモジュールを全部外してコンパイルすれば4も5もそんなに違わないのかも。
が、ビジネスロジックをエクステンションに任せるというのは極めて例外的なPHPの使い方だから参考にならないな。
227:nobodyさん
07/07/08 20:40:27
おまえら4と5の負荷の差がボトルネックに感じる程の
WEBアプリを作ってんのかと小一時間問い詰めたい
例外処理とマジックメソッド使えるだけでも
どれだけ開発が楽になって生産性上がると思ってんだよ
微々たるPHPのバージョン差の負荷とか考える前に
自分が開発するためのフットワークを
軽くすることを先に考えるのがプログラマだろうが
228:nobodyさん
07/07/08 21:12:47
富豪的発想が主流になるのはまだまだ先ってことだね。
目の前の負荷を軽くすることが優先されて、
それに割く労力を別の改良に振れるのに気づけない。
229:nobodyさん
07/07/08 21:20:14
>>226
バージョンで要求される標準モジュールがコンパイル時に違うのにあれこれ言うお前こそばかだろ
230:nobodyさん
07/07/08 22:37:30
ウェブアプリが複雑であるかそうでないかは関係ないよ。静的なHTMLでも画像でも同じこと。同じApacheを使うんだから。
むろんJavaのコンテナやfastcgiのように独立したアプリケーションサーバを用意して、ウェブサーバと分離できればいいんだが、そのコストがPHP5導入のメリットに見合わないつーこと。
バージョン3から4、4.xは順調にリプレースされていったのに、どうして日本でも海外でもPHP5への移行が進まないのか。
それは、確かにVistaには目新しい機能があるが、重くてバギーだし、XPは安定していて困ることはないよ。っていうのと似たような話。
231:nobodyさん
07/07/08 22:45:45
パーソナルユースのOS話しと業務ベースのPHP導入の話しとを一緒にしてるってのが輪をかけてバカ
232:nobodyさん
07/07/08 23:22:56
> バージョン3から4、4.xは順調にリプレースされていったのに、どうして日本でも海外でもPHP5への移行が進まないのか。
すごーーく単純な理由で、
ひとつのapacheで共存できないから。
重いから5にしないって話はほとんど（皆無ではない）聞かないね……
233:nobodyさん
07/07/08 23:33:37
PHP4 is dead ＝ PHP is dead
ｵ､ｵ、ｵﾜﾀｰｵﾜｵﾜｵﾜﾀｰ♪
＼ PHP is 全部 dead♪／
♪＼(^o^) ♪
＿ ) > ＿ ｷｭｯｷｭ♪
／.◎。／◎｡／|
＼(^o^)／.|￣￣￣￣￣| | ＼(^o^)／
) ) .| |／ ノ ノ
(((( >￣ > )))) ＼(^o^)／ ((( <￣< ))))
) )
((( >￣ > ))))
234:nobodyさん
07/07/08 23:39:25
＞PHP5への移行が進まない
そもそも、これがどれだけ説得力を持つはなしなのかね。
個人レベルのPHPサイトとかが多いからそうなってるだけだろ。
業務ベースなら、新規は５が当然。既にあるやつもそれなりにリニューアルするなら５で
動かすようにリファクタかけるよ。
235:nobodyさん
07/07/09 00:20:13
PHP4脂肪→
オブジェクト指向が理解できない大多数のプログラマ（PHPerの80％）の離脱→
PHP脂肪
236:nobodyさん
07/07/09 07:09:04
drupal使ってるやついねーのかな
結構色々できると思うんだけど
237:nobodyさん
07/07/09 08:16:21
drupalはフレームワークなわけ？
何が魅力なの？
Webページつくるだけなら違うcmsあるし、Webサービスつくるなら足りないだろ？
238:nobodyさん
07/07/09 09:11:54
URLﾘﾝｸ(en.wikipedia.org)
にweb application frameworkって書かれてるよ
魅力はより少ない手間で作れたり、
高負荷のサイトで使われてたり、他のCMSより拡張性が高かったり。
cckとか色々モジュールがあるし、足りなければモジュールを作って拡張できるから
よっぽど複雑なことをするのでない限り、
大抵のことはdrupalでもできると思うんだが
Webサービスとかはできるかどうかわからないから、「結構」って表現にしたんだけど。
完璧じゃなくても、ほとんどの場合に十分使えればいいんじゃないかと
239:nobodyさん
07/07/09 09:14:01
すれ違い、それいっちゃ、XOOPSだって、フレームワークだろ。
240:nobodyさん
07/07/09 09:25:18
>>239
やっぱそっか。スマソ
でもフレームワークとの境界線って曖昧な感じになってきてるよね
241:nobodyさん
07/07/09 09:55:48
ＣＭＳがMVC意識せずにどんどん肥大化していく中で、今で言うフレーム
ワークが展開していったっていう時間の流れだよ。自分はDrupalはその
最中に出てきた「スマート」なＣＭＳ奴で、XOOPSは一時代前のカオスCMS
っていう押さえをしてる。
242:nobodyさん
07/07/09 10:11:55
もうｶｴﾘ
ｽﾚﾘﾝｸ(php板)
243:nobodyさん
07/07/09 20:20:17 sJXKqrgb
>>232
それあるなぁ。そこを簡単に共存できるようにしてれば、
余裕でPHP5が使えるようになったし、PHP4のコードもそのままにできた。
244:nobodyさん
07/07/09 21:22:09
共存なんか大した手間じゃない。
245:nobodyさん
07/07/10 21:53:08
まあriverse proxyとか含めればいくらでも出来るからなあ。
246:nobodyさん
07/07/10 22:30:17
大した手間かけずに共存環境に移行できるサービスばかりだったらそれでよかったんだろうさ
247:nobodyさん
07/07/10 22:58:26
？言ってる意味がわからん
248:nobodyさん
07/07/12 22:09:49
>>241
Drupalは何が「スマート」なの?
XOOPSはコード的に古いから乗り換えるか
ZFあたりで出てきそうなCMSを探すか考えているところ
249:nobodyさん
07/07/12 22:47:39
CMSなんか使ってるやつはくず。
コード気にする価値なし。
250:nobodyさん
07/07/12 22:49:58
249はよくいるような「皆が使ってるものを否定する自分ｶｺｲｲ」なお子様に見えなくもないが
重厚長大なフルセットCMSって今もうそういう対象でもないよな
251:nobodyさん
07/07/12 22:51:34
どのFWもプレゼンテーション層がお粗末なのがどうもなぁ。
Smartyとかデザイナにしてみたらえらい負担だろうし。
もっと連携のしやすいものがあればいいんだけど。
252:nobodyさん
07/07/12 23:00:41
>>249
頭堅いなあ
出来上がるもんが結局同じなら、車輪の再発明しなくてもいいのに
253:nobodyさん
07/07/12 23:18:40
今日びＰＨＰもできないデザイナーは死滅したらいいよ
254:nobodyさん
07/07/12 23:30:31
>>253
お前がな
255:nobodyさん
07/07/12 23:36:15
うむ。今更感の漂う話題ではあるが
俺もついでに今更感の漂う話を投下しとくか
おまいら、CMSが好きならZope + Ploneが最強じゃね？
256:nobodyさん
07/07/14 16:14:49
PHP4サポート打ち切りって影響甚大じゃね？
稼動してるサイトは膨大で
そのうちPHP5に移行できるのはどれだけあるのか？
サイバーテロが吹き荒れそう
257:nobodyさん
07/07/14 16:36:57
正直遅いぐらい
ようやく4排除への大義名分を得られるわけだ
258:nobodyさん
07/07/14 17:44:07
これで4しか入ってなかったレンサバも5に切り替わるといいな。
259:nobodyさん
07/07/14 18:32:17
今PHP3で走ってるサイトってどのくらいあるのかな
260:nobodyさん
07/07/14 18:36:19
4から5のリプレースがうまくいかなかったのを教訓に
6は5と共存できるような仕組みが欲しいところだな
261:nobodyさん
07/07/14 18:48:36
「仕様が完全上位互換」とかじゃダメなんだよな
共存させたい環境のひとは新環境での再テストとかもしたくないだろうし
262:nobodyさん
07/07/15 00:13:42
そもそもそのテスト費用が出して貰えないから困るわけで。
263:nobodyさん
07/07/16 23:55:55 jJDluNIm
皆さん地震大丈夫ですか？
NTTの災害用ブロードバンド伝言板（web171）はPHPなんだね。
不謹慎かもしれないけど、ちょっと嬉しい…。
264:nobodyさん
07/07/17 11:54:09
そうかな? PHPだと大規模災害時とかでロードが大きくなったときに
ホイホイとスケールできるのかちょっと心配な気が...
265:nobodyさん
07/07/17 12:08:08
スケールできるよPHP
266:nobodyさん
07/07/17 14:31:06
サーバ、ネットワーク周りの改善でなんとでもなる。
267:nobodyさん
07/07/17 17:20:35
>>251
連携のしやすいものって例えばどんなもの?
php直書きとsmarty以外の簡単な方法って浮かばないんだけど
268:nobodyさん
07/07/17 17:32:55
もっと直感的に使える高機能な独自タグってことだろ。MTみたいな感じじゃないか？
269:nobodyさん
07/07/17 19:53:06
>>251が曖昧で分からないが
連携に関しては基本デザイナに埋め込みさせなきゃいいと思うんだが
270:nobodyさん
07/07/18 00:09:10
そんな事いってるから日本のPHPサイトは手抜きデザインばっかりなんだが
271:nobodyさん
07/07/18 00:32:13
>>270
なんでそうなるんだよｗ
デザイン→HTMLコーディングまでデザイナ側で落とし込んで
PHPの埋め込みだけプログラマがやればって話なのに
「そんな事いってるから」の後になんで手抜きデザイン？
272:nobodyさん
07/07/18 03:49:36
あとで修正はいったらどうすんの？
273:nobodyさん
07/07/18 09:01:06
適時対応
静的部分だけの修正でデザイナだけで
修正できるようであればデザイナが修正
修正箇所に動的な部分を含んで
埋め込みコードの修正も伴うのであればプログラマが修正
で、なんか困ることある？
274:nobodyさん
07/07/18 11:00:52
結局デザイナーっていらないね
275:nobodyさん
07/07/18 11:14:27
状況から真っ当な結論を導き出すのが極端に下手な奴がいるな
276:nobodyさん
07/07/18 11:31:24
まともにデザイナと連携して仕事したことないんだろうな
277:nobodyさん
07/07/18 16:25:07 3R7D5ath
SmartyのかわりにPHPTALとかじゃだめなの？
278:nobodyさん
07/07/18 17:49:45
デザイナーと仕事するのが偉いと勘違いしてるやつがぽつぽつ
279:nobodyさん
07/07/18 18:40:20
自分が一番偉いんだと勘違いしてるやつが・・・
280:nobodyさん
07/07/18 18:43:56
コーダーでPGもこなす俺が真の勝ち組。
デザイナにはデザイン画像だけ描いてもらえばおｋ。
HTML起こすのは自分でできるもん♪
281:nobodyさん
07/07/18 18:45:26 sJyKZns/
全部一人でやれる奴が最強な訳で・・・
282:nobodyさん
07/07/18 18:49:11
実際ヘタな紙デザイナに変なHTML書かせるより
画像だけ描いてもらってHTMLに起こすのはプログラマがやった方が
結果としてキレイなものが出来上がる気がする
283:nobodyさん
07/07/18 19:17:22
ズレてきてるな
どう役割分担して連携するかって話だろ
誰が偉いとかおまえらのHTMLコーダー自慢とかはどうでもいいよ
284:nobodyさん
07/07/19 10:09:35
読みこみファイル数がすごい数になってるんだけど
アクセラレータつこうたら大丈夫？
お前らどうしてますか？
285:nobodyさん
07/07/19 12:33:42
>>284
まずコードを見直す
286:nobodyさん
07/07/19 14:46:00 Qs6wUD6U
>>284
主要フレームワークってeaダメだよね？
287:nobodyさん
07/07/19 15:12:56
cakeはいけてますが
288:nobodyさん
07/07/19 21:29:14
なんでeaってダメなの?
xcacheならOK?
289:nobodyさん
07/07/19 21:44:14
異常動作することがあるらしいね>ea
アクセラレータのスレにあったはず
別にフレームワークは関係ないと思うが
290:nobodyさん
07/07/20 04:21:50
>>285
フレームワーク自体がファイル読みこみまくりだからコード見直しても意味ない
hello,worldですらファイルが数十個読まれる
つまりフレームワーク使うのは阿呆
ついでにいえばウェブプログラムごときでオブジェクト指向使うやつも阿呆
291:nobodyさん
07/07/20 04:56:45
とオブジェクト指向が理解できない阿呆が申しております。
292:nobodyさん
07/07/20 09:49:57 xk3U0lu8
protectedな変数持ってるとEA動きません。
293:nobodyさん
07/07/20 10:14:17
まじで？
俺オワタ＼(^o^)／
294:nobodyさん
07/07/20 10:19:26
本当に必要なファイル読み込みなのかどうかコードを見直せ。
ＦＷ側で不要なインスタンスを発行しまくっているようなら、
それをコロすように継承自前クラスで上書き。
ＦＷって結局汎用だから、MVCの過程で、余分な処理をしてることが往々にしてある。
次に、ページキャッシュを考えろ。キャッシュ処理可能ページとそうでないページの
振り分けをちゃんとできるようにコードを見直す。
アクセとかハードウエア性能向上という手がつかえないなら、それしかないだろう。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5365日前に更新/129 KB
担当:undef