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

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

[前50を表示]
100:nobodyさん
08/09/13 22:25:24
->が一番嫌いなんだよな
.がいいよな.のほうがカッコいい

101:nobodyさん
08/09/13 22:30:28
>>96
__ で始まるのは全部予約メソッドなんだが

102:nobodyさん
08/09/13 22:35:44
>>100
そうすると、文字列連結が + になり、
連鎖的に toString() 的なメソッドが欲しくなり・・・

Cっぽいな strval() をがんがん使うつもりならそれでもいいが、
Perl派生言語のジレンマを、そう気軽に語ってくれるなｗ

>>101
それはPHPの「仕様」ではないよね。雰囲気ではそうかもだけど。
実際、ユーザ定義のメソッドで __ が使えない訳ではない。

103:nobodyさん
08/09/13 22:53:57
protectedとprivateは別物なのに、_で一緒くたにしているのは、
ZF規約の欠点ではなかろうか。
ZF自体の作りの洗練されなさを考えると、
深い考えがあってそうしたものでもなさそう。
実際symfonyなんかは、Javaと同じでプレフィックス付けたりしてないし。
Rubyでもそんな習慣聞いたことない。
PHP4の呪縛を引きずってるだけじゃね？
こんな規約、いらないんじゃね？

104:nobodyさん
08/09/13 22:59:30
>>103
publicと、private,protectedの区別をメソッド名でつけることは、
意味がないとは思わない

> protectedとprivateは別物なのに、

っていうのは同意だけどね
それについて、ここしばらくPHPの仕様がらみのレスが
付いてるように見えるんだがそれについてはどうなんだｗ

105:nobodyさん
08/09/14 00:28:45
>>100
.のが使いやすいのは同意なんだけど、加算演算子と文字列連結演算子が別なのは
PHPの数少ない美点の一つだと思ってる。

106:nobodyさん
08/09/14 01:05:36
>>105
それは単純にPerl由来なんだけどな。$ と同様に。
$ の使い方としては劣化してるし、この辺はもうPerl文化を切り捨てるか、
PHPの独自路線が欲しい所ではある

107:nobodyさん
08/09/14 01:09:29
配列が@とか%じゃないのは良いよな
あれきもいし

108:nobodyさん
08/09/14 02:35:06
PHPってびっくりするほど独自路線というものが無い言語のような気が...
Perlの遺産だったり、Cが透けて見えたり、Javaのパクリだったり...
で、だからこそ普及しているんじゃないかな。

あと関係ないけどPHP6で常にUnicodeモードを有効にしたのは英断だと思う。
パフォーマンスやメモリへの影響も今時のサーバで問題があるほどでもないし。
5系から6への移行は大変かもしれないけど、それで仕事が増えるなら構わないw

109:nobodyさん
08/09/14 03:31:07
ユニコードモードって何が変わるの？

110:nobodyさん
08/09/14 04:04:33
未だにPHP４とかの鯖あるし
４，５，６とか大変なんだが～

111:nobodyさん
08/09/14 04:10:29
新規案件で4の鯖はないっしょ。てか誘導しようよ
保守案件で4なら、ご苦労様としか言えぬｗ

6は、一応5.3と互換性を持たせるつもりみたいだね
その5.3が大変なんだろうけど、まだ見ないねぇ

112:nobodyさん
08/09/14 09:51:48
別にPHP4でも困らないけどな。PHP5の機能で役に立つのは例外くらいなもんだし。

113:nobodyさん
08/09/14 10:42:39
オブジェクトが代入でコピーされなくなったのは、地味に気持ちいい

114:nobodyさん
08/09/14 10:44:44
&付ければいいだけじゃん。

115:nobodyさん
08/09/14 11:30:26
cloneだろ

116:nobodyさん
08/09/14 14:34:14
4だから困るとか言うよりは、2系統あるのが困る

117:nobodyさん
08/09/16 20:53:37
>>115
コピーって言っちゃだめなの？

118:nobodyさん
08/09/16 23:08:17
>>117
>115は>114に対して

119:nobodyさん
08/09/17 13:33:07
PHPをやめるとしたら、何を使いますか？
・Ruby
・Python
・Perl

やっぱPythonかな？

120:nobodyさん
08/09/17 13:35:32
Perlは個人的にないな。

121:nobodyさん
08/09/17 13:41:27
>>119
仕事的には、PHPより高速で安定的に動作して、
月額1000円程度以上のレンサバには95%以上の確率で入ってるなら
なんでもいい。

そんなのある？

122:nobodyさん
08/09/17 13:43:47
つPerl & FastCGI
FastCGIの方は、95%にはちと足りんかな？ｗ

123:nobodyさん
08/09/17 13:50:56
Rubyに移行しようと思ったけど
ZendStudioがあるから結局PHP使ってる・・

124:nobodyさん
08/09/17 18:12:51
書いてて面白いのはPerlだね。

125:nobodyさん
08/09/17 18:45:58
じょうだんよしこさん

126:nobodyさん
08/09/17 22:00:15
PHPのつまらなさは異常

127:nobodyさん
08/09/18 02:36:03
qiq入れればまだ楽しめるよ

128:nobodyさん
08/09/18 16:41:27
ますかきおくん

129:nobodyさん
08/09/18 16:49:43
qiq面白いとは思うけど
コードの依存部分が全体に広がるエクステンションを入れるのはやっぱり抵抗あるわ
もしそれがダメになった時のことを考えると

130:nobodyさん
08/09/18 16:52:54
楽しめても、業務利用は無理っしょ
まだRubyで楽しんでる方が健全じゃねーかｗｗｗ

131:nobodyさん
08/09/18 19:11:26
趣味用の言語ならもっとマイナーな奴でもやれよ

132:nobodyさん
08/09/18 19:12:59 ykJuPDO5
>>129
別に、フレームワーク使ったってそのフレームワークに依存するじゃん
なんでQIQだと抵抗があるのか

133:nobodyさん
08/09/18 20:57:09
そりゃあんた、なんか不可解な挙動があったときに、どこまで自分の力で
調べて修正できるのかって点で、違いすぎるだろｗ

ぶっちゃけ、PHPのコアに関わっている人間にとっての別実装や実験として
でもなければ、QIQなんておもちゃ以外の何者でも無かろうが

134:nobodyさん
08/09/18 21:38:02
将来PHPがバージョンアップして
qiqの開発が停止して非対応だったら
それまで書いたqiq依存コードがもろとも脂肪じゃん。
フレームワーク使っててもフレームワーク非依存なプレーンなクラスは書いていくし
そういうのは流用が効く。

135:nobodyさん
08/09/19 00:57:48
PHPにもApacheにも何も保証があるわけじゃないのに。
PHP5依存コードが脂肪しない保証もない。
Zendと契約結んでる？　そりゃ失礼しました。

136:nobodyさん
08/09/19 03:33:16
>>135
確率の問題

137:nobodyさん
08/09/19 12:02:16
PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
同一視できるのか
また、ユーザの少ないというか皆無に近いQIQなるエクステンションと、
ばりばり商用利用され、長期間メンテの続いている普及率抜群の
プロジェクトとを同一視できるのも素晴らしい

>>132とか>>135とかは、きっと「フレームワーク」の中を調べたりましてや
いじったりなんて、思いもしないユーザなのかな？

ひょっとして全部同列に見えるくらいのスーパーハカーですか？

138:nobodyさん
08/09/19 18:10:39
PHPユーザーは裾野が広いってことでしょう。
サンデープログラマーから職業プログラマーまで幅が広い。
QIQは素晴らしいエクステンションだから、PHPを支援しているIBMやマイクロソフトとかの大手企業に支援してもらったらいいんじゃないですか？＞作者の方

139:nobodyさん
08/09/20 13:23:29
ラムダとか5.3で導入されるじゃん
qiqって何が素晴らしいの？

140:nobodyさん
08/09/20 13:42:12
前スレでさんざん出てた [] じゃね？
執着してる人が結構いるようだし

141:nobodyさん
08/09/21 05:27:57
[]とハッシュ{}はほしいねぇ
あと -> を . にすれば書くのも読むのも楽だ

142:nobodyさん
08/09/21 05:32:43
C/C++の話かよｗ

143:nobodyさん
08/09/21 18:00:01
>>137
>PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
>同一視できるのか

おいおい、PHPの安定性をApacheと同じにしないでくれよ。
どうせPHPだってver4のサポートなんてもう打ち切られるじゃん。
未来永劫サポートされるわけじゃないし、どっちもどっち。

PHPもフレームワークもQIQも、どれもオープンソースじゃん。
だれかのメンテに頼るのもいいけど、必要なら自分でメンテすればいいじゃんか。
QIQなんてただのライブラリにすぎないんだから、そのくらいできるだろ。
でかいフレームワークのコード読むよりは小さいQIQのほうが楽。

144:nobodyさん
08/09/21 19:43:02
> QIQなんてただのライブラリにすぎないんだから、
ライ・・ブラリ・・・？

> でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
確かにそうかもしれんが、QIQが何をやってどこを修正すれば
どうなるかってのをつかむ為には、少なくともCとBison(Yacc)と
PHPのCソースコードに関する知識が必要。
てか「楽」じゃねーよｗ

145:nobodyさん
08/09/21 20:08:55
QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。

146:nobodyさん
08/09/21 21:37:07
あれはPHPの拡張モジュール作るのには必要ない、文書化もされていないようなAPIを叩いてるからね...
単体では短くても、理解しようとするとZend Engineのソースコード全体を見る羽目になるw

それとは関係ないけど、拡張モジュールを作るなら何気にPHP6はAPIが使いやすくなってる。
5.3もUnicode関連を除いてほぼ6相当だけど、便利な関数が5.3だけZEND_APIとしてエクスポートされていなくて切ないことも。

147:nobodyさん
08/09/22 00:20:44
>>145
>QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。
それはおまえがWebのスキルしかないから。コンパイラコンパイラの初歩知識があれば、見れば分かる。
自分が慣れてる分野のコードは読めて、知識のない分野のコードは読めないのは当然。

148:nobodyさん
08/09/22 00:46:48
PHPで描かれたウェブのフレームワークとPHPのエクステンション、どっちが難解かは子供でも分かること

149:nobodyさん
08/09/22 01:04:16
いや、量によって変わるから、どちらが難解かは一概に言えない。

ただいえるのは、PHPという言語仕様を非公式変えてしまうようなものは
公式でPHPそのものが変わったときに対応が困難になるから
使うのはやめておけってこった。

150:nobodyさん
08/09/22 07:15:01
公式でPHPが変わったら、どっちもどっちじゃない?

151:nobodyさん
08/09/22 10:49:18
じゃない。

152:nobodyさん
08/09/22 16:45:08
アホな質問かも知れないけど、cakephpライクなフレームワークを作ろうかと
思ってるんですが、マジックメソッドの __get使ってモデルやコンポーネントの
呼び出しを下のようにやってみたいんだけど、何か問題あります？

class HogeController extends Controller
{
　　function index()
　　{
　　　$data = $this->Model->classname->find();
　　　$this->Component->classname->hogehoge();
　　}
}

153:nobodyさん
08/09/23 00:47:41
>>152
$this->Modelとか$this->Componentの__get()で、
与えられたクラス名のオブジェクトを生成・取得するって仕組み？
特に悪いとも思わないけど、必要とか便利とかもあんまり思わないｗ

例えば設計思想とか、利用時の利便性とかもあるんだろうけど、
同じ事をするのに、Model::factory()とかModel::singleton()でも
いい場合もあるかもだし

ピントはずれだったらｽﾏｿ

154:nobodyさん
08/09/23 00:51:04
>>153 微妙に修正
> 同じ事をするのに、Model::factory()とかModel::singleton()でも
→ 同じ事をするのに、Model::factory(classname) とか new classname() とか classname::singleton() とかでも

155:nobodyさん
08/09/23 02:07:19
new は method chain できないから却下

156:152
08/09/23 15:14:04
cakephpだとコントローラーのプロパティに
使うコンポーネント設定するのいちいち面倒だな～と思ってたんで。
そういうやり方もあるんですね、勉強になります。有り難うございました。

157:nobodyさん
08/09/23 17:34:13
∧＿∧
（　´∀｀）＜ぬるぽプロジェクト

みんなで面白いサイト作って有名にしようぜ！
ｽﾚﾘﾝｸ(news4vip板)
★まとめwiki
URLﾘﾝｸ(www39.atwiki.jp)

PHPのフレームワークとして symfonyを採用予定です。

158:nobodyさん
08/09/23 20:55:42
>>157
スレ荒れすぎワロタ

159:nobodyさん
08/09/23 21:24:50
>>158
自動保守おいしいです（^q^）

160:nobodyさん
08/09/26 16:21:57
フレームワークとは直接関係ないけど5.3でspl_autoload_register(function($name){...});
すると実際にautoloadされるときにbus erorrで落ちるね。
spl_autoload_register($f=function($name){...}); なら$fが生きている間だけは落ちない。

161:nobodyさん
08/09/26 16:42:24
5が出ても枯れるまで結構時間かかったし
6も使えるようになるまでは長いだろうなぁ

162:nobodyさん
08/09/27 08:37:12
一人で最初期モックアップ作るなら、
railsとcakephpと、どっちが向いてる？

163:nobodyさん
08/09/28 11:02:03
その比較って意味あるのかな？
Ruby（少なくともRails）とPHPが同等にできる人にとってしか答えようがないし、
回答もしかりw

164:nobodyさん
08/09/28 11:49:26
cakeみたいな厨フレームワーク使ってる人恥ずかしくないんですかぁ

165:nobodyさん
08/09/28 15:59:10
んじゃ何使えばいいの？

166:nobodyさん
08/09/28 18:15:32
☆Z☆E☆N☆D☆!!

167:nobodyさん
08/09/28 22:06:23
Zend…

無いわー

168:nobodyさん
08/09/28 23:15:36
zend使いまくりだけど
何が不満なのかわからない

169:nobodyさん
08/09/29 06:03:55
モックならちいたんで良いジャマイカ。

170:nobodyさん
08/09/30 00:08:37
モックなら素のPHPでいいよ

171:nobodyさん
08/09/30 00:17:33
モックはHTMLで十分なこともおおくない？ｗ
ヘッダフッタ辺りのレイアウトとかで楽したいなら、
手慣れたテンプレートエンジンがあればいいかもだけど

フレームワークってのとはちょっと違うような
多分必要なのはView側の省力化・柔軟性かなあ

172:nobodyさん
08/09/30 00:41:51
マックでいいよ

173:nobodyさん
08/09/30 01:56:27
楽天がセッションidごとgoogleにキャッシュされ、
個人情報を漏らしまくって最終的にPHP脂肪ｗｗｗ

174:nobodyさん
08/09/30 03:55:27 CLW/UbJj
物区ならPencilでいいんじゃね

175:nobodyさん
08/09/30 06:24:36
つーかsymfony一択だろ
フレームワーク作者で一番センスあるコード書くのがフランチョス。

176:nobodyさん
08/09/30 07:01:23
symfonyは関数名がダサい
_区切りとかKENTかよｗ

177:nobodyさん
08/09/30 07:07:59
そんな規約ないよ
何かと間違えてないか？

178:nobodyさん
08/09/30 07:12:10
あれれ～symfonyじゃなかったっけ？

179:nobodyさん
08/09/30 07:26:27
symfonyはJavaと同じキャメルケースだよ

180:nobodyさん
08/09/30 19:28:17
そもそもPHPの標準関数の命名がいい加減なんだから、拘っても意味ない。

181:nobodyさん
08/10/01 01:38:54
PHPはキャメルケースとアンダースコア混在しまくってるからな
クラス名とか関数名とか考えるとき、どっちにしようかいつも迷ってしまう

182:nobodyさん
08/10/01 01:50:42
それ単に昔の関数と最近のクラスメソッドなだけだろ

183:nobodyさん
08/10/01 07:31:56
将来的にはほとんどオブジェクト指向のラッパーが用意されて
関数は地下に潜った存在になるだろうな

184:nobodyさん
08/10/02 19:06:50
最近のは殆どキャメルケースに一本化の流れなんかね
アンダースコア派だったからどうもなじめない

185:nobodyさん
08/10/02 19:46:59
オブジェクト指向な関数（メソッド）で
アンダースコアが普及しているような言語あるの？

186:nobodyさん
08/10/02 19:54:09
るｂｙ

187:nobodyさん
08/10/02 19:55:23
くそ言語wｗ

188:nobodyさん
08/10/02 19:59:51
PHPに言われたらしめぇだべ

189:nobodyさん
08/10/02 20:29:01
PHPよりも糞な言語なんてINTERCALくらいだろ

190:nobodyさん
08/10/02 20:58:24
キャメルケースでも、メソッド名でM$流のUpperCamelCaseは勘弁して欲しい
それはクラス名だけでいいと思う

191:nobodyさん
08/10/02 21:19:41
メソッドをアッパーキャメルケースで書く人なんているの？
そんなコード見たことない

192:nobodyさん
08/10/02 21:28:23
C#とかかじった人はやる。
携帯ミドルウェアとかやっててC/C++は触るがJavaは触らない、って人もやる。
まあぶっちゃけ Java vs. C# なんだけど、PHPは中途半端なので混在してる。

その点Rubyは、作ってる・使ってる人間がC・Perl on *nix の人メインなので、
アンダースコア派が主流なのかな
また、RubyではUpperCamelCaseは文法的に定数扱いされるので、メソッド名や
通常の変数名には使えない。・・・MS流が嫌いなのか？ｗ

193:nobodyさん
08/10/03 00:28:34
そういう書き方の自由を奪う言語は嫌われる。

194:nobodyさん
08/10/03 02:07:48
Rubyの_でつなぐのはPerl由来だろうね。俺は_でつなぐのが見やすくて好きだけどな。
PHPはJava風なんだけど、初期に出来た関数の命名が超適当だからな。引数の取り方とかも。
C#とかJavaはどうせIDE使うんで、まあ、どうでもいいような気がする。

195:nobodyさん
08/10/03 11:11:04
大文字小文字を区別しないものにCamelCaseを使うのは、ちょっと気持ち悪い

196:nobodyさん
08/10/03 14:57:50
キャメルケースの種類

アッパーキャメルケース (UCC)、またはパスカルケース(PascalCase)
　　複合語の先頭を、大文字で書き始める。
　　つづり例：CamelCase

ローワーキャメルケース (LCC)、または単にキャメルケース
　　複合語の先頭を、小文字で書き始める。
　　つづり例：camelCase

197:nobodyさん
08/10/03 15:09:46
なんでわざわざ書いたん？
自分用メモか？

198:nobodyさん
08/10/03 15:43:33
初めて知ってうれしかった

199:nobodyさん
08/10/03 16:36:40
CSSですらできる多重継承ができないPHPって一体・・・

200:nobodyさん
08/10/03 17:18:11
Mixinがあれば多重継承なんて必要ありませんよ

201:nobodyさん
08/10/03 17:57:27
>>199
Javaもですが・・

202:nobodyさん
08/10/03 18:04:06
Mixinを提供しているRubyだけがCSSと肩を並べているということですね

203:nobodyさん
08/10/03 19:59:32
つまり、いや、やめておこう

204:nobodyさん
08/10/03 20:27:36
>>185
pythonもメソッド名は、アンダースコアが一般的かな。
クラス名はキャメルケースだけど。

205:nobodyさん
08/10/03 20:55:12
最後の文字だけ大文字にする逆キャメルケースにしてる人いる？
geThogEとか

206:nobodyさん
08/10/03 23:42:27
>>205
どうでもいいけど、読みづらくね？

207:nobodyさん
08/10/03 23:48:08
ゲソォグイーと読んでしまった

208:nobodyさん
08/10/04 00:29:16
>>205
まずそうしようと思った意図はなんだｗ
さすがにこれは利点も考え付かんｗｗ

209:nobodyさん
08/10/04 00:31:58
難読化とかｗ

210:nobodyさん
08/10/04 04:52:10
<?php
class Class_Name
{
　　 public function methodName( )
　　 {
　　　　　functionName($valOne, $valTwo);
　　　　　if ($a == 1){
　　　　　　 $b = 2;
　　　　　}
　　 }

命名規則、俺の結論はこのあたり。
URLﾘﾝｸ(framework.zend.com)
URLﾘﾝｸ(solarphp.org)
Zend, Solarあたり守っとけばPEARの規約でも問題ない。あとクラス名は_で区切っとかないとauto loaderがめんどい。

211:nobodyさん
08/10/04 07:46:06
if (---) {

212:nobodyさん
08/10/04 13:25:04
>>210
>あとクラス名は_で区切っとかないとauto loaderがめんどい。
kwsk

213:nobodyさん
08/10/04 15:19:20
>>212
>>210じゃ無いけど、ディレクトリ構造を反映ってことじゃない？
Perlのモジュール風？

Zend_Db_Table_Rowクラス => Zend/Db/Table/Row.php

ってな感じじゃないかと想像

214:nobodyさん
08/10/04 15:29:32
explodeですぐパスに変換できるってことか
たしかに_区切りはよさげだな

215:nobodyさん
08/10/04 20:31:20
へー

216:nobodyさん
08/10/05 02:47:20
>>213
その通り。フォローthx
PEARでもその命名でディレクトリきってるし、PEAR2ではそのルールでauto loader標準だと思ったよ。

217:nobodyさん
08/10/05 04:57:56
細かい話になってくるが、DBとかPDFとかいう略語の場合、
DBなのかDbなのか、PDFなのかPdfなのか、っていう違いも
あるねｗ

これがまた人によってまちまちだし、同じ人でも場合によって
違う場合がある

218:nobodyさん
08/10/05 05:28:14
zendスタイルにした時、そこが一番しっくり来なかったような気がする

あとプロパティはどうせ全部 private なので _ が面倒

219:nobodyさん
08/10/05 11:01:14
デザインパターン使うときはデザインパターンも名前に入れてる
例えばSolar_Auth_Adapter_Sql はパッケージ名はSolarで認証クラスをアダプターでSQLクラスで実装してるクラス。
Solar/Auth.php
Solar/Auth/Adapter.php Solar_Auth_Adapterクラスで抽象クラスを定義
Solar/Auth/Adapter/Sql.php Solar_Auth_Adapter_Sql クラスでSolar_Auth_Adapterクラスを実装

220:nobodyさん
08/10/06 14:16:23 H0RcPBpG
みんな努力してるんだなー。
参考になります＾＾

221:nobodyさん
08/10/07 00:37:43 h510jQqa
>>205
意味不明で面白い。ウケる。

222:nobodyさん
08/10/07 14:11:17
>>219
> デザインパターン使うときはデザインパターンも名前に入れてる

それ、使うときもあったり使わないときもあったり、

クラスに単一のパターンしか適用されない場合、
そのパターンの為のクラスの場合には、そういう名前付けられるけど

一つのクラスに複数のパターンが適用される場合困るんだよな。

223:nobodyさん
08/10/07 14:44:16
俺様フレームワークをやめようと思って、CakeかSymfonyを導入しようと思うけど
結局どれがいいんだ…

224:nobodyさん
08/10/07 14:53:14
逆に俺様フレームワークを公開して
スタンダードにしてやれ

225:nobodyさん
08/10/07 14:58:34
結局はちいたんでいいじゃんっていうレスがつく未来が見える

226:nobodyさん
08/10/07 20:28:02
ちいたんは、その名前が失敗の理由のひとつである。

227:nobodyさん
08/10/07 21:32:19
>>225
結局はちいたんで（ｒｙ

228:nobodyさん
08/10/08 02:29:04
>>227
早いわｗ

229:nobodyさん
08/10/10 00:45:42
まあ増えすぎたよね
機能追加しすぎで扱いにくいWEBサービスのようだ

230:nobodyさん
08/10/16 15:04:15
>>225
まあ徴兵制だろうね。
戦前（に成人した）世代と戦後世代の日本人を見比べれば一目瞭然。

231:nobodyさん
08/10/16 15:31:37
なんだ？この妙に右よりの誤爆は

232:nobodyさん
08/10/17 00:38:24
PHPプログラマーの方でPHP用フレームワークを使っている方へアンケート！ ※フレームワーク導入を検討中。先輩方は何を使っているのか？好んでいるのか？をアンケート。.. - 人力検索はてな
URLﾘﾝｸ(q.hatena.ne.jp)

Pradoが圧倒的ですねｗ
URLﾘﾝｸ(www.pradosoft.com)

233:nobodyさん
08/10/17 01:45:17
このpradoぶっちぎりはネタだよね?w

234:nobodyさん
08/10/17 03:15:57 7gkZ0lcc
>>233
PRADOの解説本が出てないじゃん！？
Zend、Symfony、CakePHP、CodeIgniterの本は出てるぞｗｗｗ
出版社は売れるであろう本を出すはず

235:nobodyさん
08/10/20 02:51:25 ya5easnJ
symfonyってページネーション機能はあるんですか？
ネットで検索しても「ajaxでページネーション」はあるんだけど・・・

236:nobodyさん
08/10/20 17:37:11
英語の情報をなかったことにするのは君にとって損失かもしれないよ?

URLﾘﾝｸ(www.google.co.jp)

237:nobodyさん
08/10/20 21:10:52 Kq4igHV+
>>236
でもそれも機能たいしてなくないか？
CakePHPみたいに同一ページの複数モデルに対応してないでしょ？

っていうか、ページネーションって掲示板ですら絶対に必要になる機能なのに
なんで標準で付けないんだろ

238:nobodyさん
08/10/20 21:57:19
>>237
最適化が難しいから。

一度でもページネイションの機能を作ったことがあればわかると思うが、
DBから全データ読み込んでから絞り込むのか、検索条件を考慮したデータを
取得しておいてからそれを絞り込むのか、なんだかんだ。

基本的に、データの「件数」がわからないとページング出来ない。
（それを無視してやるページングもあるが。）

どうせライトユーザ向けには、DBやらと連携したページングを求め
られるんだから、「始めからつけてない」は、ある意味賢明な選択だよ。

・・・↑が不満なら、PEARとか使えばいいじゃん、全く。

239:nobodyさん
08/10/20 22:10:00 Kq4igHV+
>>238
いや俺もたいしたやつじゃないけど作ったことあるし、
CakePHPのソースを解析したりしてみたけど、
そんなに難しくはないと思うけどな（だったらそれ使えばいいじゃんと言われるかもしれないが・・・）

＞基本的に、データの「件数」がわからないとページング出来ない。
これは渡せばいいだけ

240:nobodyさん
08/10/20 22:21:43
>>239
うん。だから、>>238の二行目
>最適化が難しいから
と、最終行
>・・・↑が不満なら、PEARとか使えばいいじゃん、全く。
が、結論なんだけどなｗ

「フレームワークに標準で付いていない」ってのが問題じゃ無かったのか？

241:nobodyさん
08/10/20 22:31:39 Kq4igHV+
>>240
PEARは使いたくない

まあ、付いてないことがはっきり分かったからもういいです

242:nobodyさん
08/10/20 23:11:01
paginationはZendなら標準で付いてる
しかも色んな状況に対応できる
さあ、ZFを使おう！

243:nobodyさん
08/10/20 23:27:07 Kq4igHV+
まあそれが普通だよな

244:nobodyさん
08/10/20 23:34:15
＞基本的に、データの「件数」がわからないとページング出来ない。
CakePHPはよくできてる。
データの件数ってのは、データ用のSQL文のうち条件は同じでselectするものが、
フィールド名の変わりにcount(*)になっただけ。

そこの部分（フィールド名の変わりにcount(*)）への変換を
自動でやってくれるから、データ用のSQLに相当する部分のみを書けばいい。
また、データ用のSQLにlimitを主導で追加する必要もない。これも自動で追加される。

つまり、「データを取ってくるSQL」を書いて「ペジネーション」処理を使うだけで内部的に、
「データを取ってくるSQL」には、自動的にlimitが追加されて発行され
「データを取ってくるSQL」には、自動的に件数を取得するcountに変更される。（当たり前だがこっちにはlimitはつかない）
（もちろんSQL直書きではなくモデルの操作だが）

最適化って話なら、データ件数を取得する関数をオーバーライドできる。（上のやつはデフォルト動作）
こういう目的でオーバーライドされるために存在するメソッドが用意されている。

245:nobodyさん
08/10/20 23:41:59
>>244
うーん。それは、例えばファイルベースのデータとかには適用できないよね。
メールボックスを漁るとか、さｗ
無理矢理使おうと思えば、いっぺんDBに放り込む必要がある。

そんな（SQLで全部済む）フレームワークばかりではない、っていう前提に
立てば、ページネイションの機能は汎用的なものにならざるを得ない。

データの件数と一ページ辺りの取得件数から、データ開始位置（番号）と
データ終了位置を取得する、みたいな。
SQLで言えば、OFFSET とそこからの LIMIT を取得するだけ、っていう。

んで、そんなクラスが乱立しても仕方ないので、PEARなりZendなり使えって
結論で多分無問題。
と思うんだけどなぁ
もちろん、>>244みたいな全自動？ページネイションを否定するわけではないけど。

246:nobodyさん
08/10/20 23:53:02
SQLを使わないページネイションなら別にある。

247:nobodyさん
08/10/21 00:20:07
mysqlならSQL_CALC_FOUND_ROWSを使いたいよね

248:nobodyさん
08/10/21 00:32:46
>>247
またそんな無茶ぶりをｗ
フレームワークなりライブラリなり作る身になれｗ

まあ、そんなこと言う人は自分で作るんだろうけど

249:nobodyさん
08/10/21 01:06:35
>>244
>CakePHPはよくできてる。
別にCakeだけがよくできてるわけじゃなくて、Cake以外もできてますよね？

250:nobodyさん
08/10/21 03:24:50
>>247-248
ページネイションとSQLをごっちゃにしてね？
SQL_CALC_FOUND_ROWSを使った独自SQL文からのデータを、
ページネイションに渡せばいいんですよ。

251:nobodyさん
08/10/21 03:26:05
>>249
symfonyにはないってことから、この話題がはじまっている。

252:nobodyさん
08/10/21 03:31:10
ページネーションくらい自分で書けばいいじゃん

253:nobodyさん
08/10/21 03:33:09
cakeなどという厨フレームワークを使える奴は恥知らず
それだけはガチ

254:nobodyさん
08/10/21 03:36:51
>>252
だからそういう問題じゃないんだって
そんなこといったらFWも自分で書けば（ｒｙ

255:nobodyさん
08/10/21 03:37:18
simplateの中の人が不治の病で引き継ぎする人募集してるね
面識ないし、simplateを使ったこともないけど泣きそうになっちゃった

256:nobodyさん
08/10/21 03:39:35
てかモデルは自分で書いた方がいい
FW付属のモデルだとクラスタリング対応とかしにくいじゃん

257:nobodyさん
08/10/21 03:41:23
こういうスレって必ず>>253みたいな奴が現れるよなｗ

258:nobodyさん
08/10/21 03:42:25
>>257
恥知らず乙ｗｗｗ

259:nobodyさん
08/10/21 03:46:39
>>255
もういいんだ。PHPの世界でテンプレートはもう死んだんだ。
みなが、PHPがテンプレートそのものじゃね？と気づいた。
君の役目は終わった。

260:nobodyさん
08/10/21 03:53:16
simplateの中の人はいい仕事をしている
いい仕事をしている人を愚弄するな

261:nobodyさん
08/10/21 03:57:54
愚弄？

262:nobodyさん
08/10/21 03:58:45
>>255
一度計ったことがあるけど
たしかに速いね

>>257
相手にしない方がいいよ

263:nobodyさん
08/10/21 04:04:16
cake使いって案外多いんだなｗ
高カロリー低栄養のケーキ喰いすぎてメタボm9(^Д^)ﾌﾟｷﾞｬー

264:nobodyさん
08/10/21 04:39:49
>>263
後半は、なんだい？ケーキの話かい？じゃあすれ違いだねｗ

265:nobodyさん
08/10/21 10:18:09
>>263
こいつ自分から頭悪い発言してるなｗ

266:nobodyさん
08/10/21 15:53:57
厨フレームワークだけあって
さすがにcake厨の煽りはレベル低いねｗ

267:nobodyさん
08/10/21 16:58:55
おまえらライスケーキでも食ってすこしもちつけ

268:nobodyさん
08/10/21 17:12:18
だいたいページネーションとmodelを一緒くたにするなんて愚かすぎだろ>cake
まず汎用的な単体ページネーションクラスを書いて
それにモデルをアタッチできる継承クラス書くなり
アダプタ書くなりするのが普通です
つまりsymfonyは神、cakeはホームレス

269:nobodyさん
08/10/21 18:03:54
> だいたいページネーションとmodelを一緒くたにするなんて愚かすぎだろ>cake

ページネーションがmodelと一緒くたになっていると
勘違いする人もいるんだなぁｗ

コントローラと一緒くたになっているというならまだしも。
（まあコントローラと一緒くたになるのは何の問題もありませんが）

いったいどこの部分を見て一緒くたといっているんだろうか。
modelから任意の範囲のデータを持ってくる機能？
これをmodelに入れないとしたらどこに入れるんだか。

270:nobodyさん
08/10/21 19:56:58
まぁ、cake見たことないから憶測で言ってるだけだけどね。
cakeってPHP4/5用だっけ？
4を切り捨てずにクリーンになんて書けるわけねーし
物乞い乙ｗｗ

271:nobodyさん
08/10/21 20:34:39
なんにしても厨っぽい発言していると説得力なくなるぜ

272:nobodyさん
08/10/21 21:33:22
code igniterにしてもcakephpにしても
ウリだったPHP4対応が今度は足かせになります

273:nobodyさん
08/10/21 23:07:36
切り捨てなかったからユーザがついたんじゃないの

274:nobodyさん
08/10/22 02:03:20
つかPHP4が使えないフレームワークなんて
仕事じゃ使えません

275:nobodyさん
08/10/22 02:05:32
>>274
とも限らなくなってきたな。
いつまでも古いサーバ使ってるんじゃないよー

276:nobodyさん
08/10/22 02:16:16 //oF70yn
>>275
クライアントに言ってくれよ…
verアップを勧めても、他のプログラムに不具合が出るかもしれないので
PHPのverアップはできません(^o^)
って言われるしな…

277:nobodyさん
08/10/22 02:32:46
実際クリーンとかピュアとかって商売としては・・

278:nobodyさん
08/10/22 05:53:06
>>274
すごいな。未だにこんな仕事してるやついるのか…

279:nobodyさん
08/10/22 08:21:37
ま、今でもPHP4を指定する案件は多い。サーバ上の他のプログラムがPHP4で動いているなら、新しいプログラムもPHP4にするしかないからな。

280:nobodyさん
08/10/22 08:43:18
>>279
歩のスパイラルだな
もうPHP４は絶体絶命のセキュリティ穴でも作って
使ってるサーバごとぶっ壊せばいいのに

281:nobodyさん
08/10/22 13:04:41
実際PHP4はもうセキュリティFIXも出さない予定なんだろ？
といいつつこないだ出たけど。
レン鯖でPHP4と5共存してるところとかあるよね。

282:nobodyさん
08/10/22 15:48:34
php4で作るならphp5より高いですよ。
とか言えばいいんじゃないのかな。
実際大変だし。

283:nobodyさん
08/10/22 16:26:31 Skk+7Du0
>>282
じゃあ他に頼みます

284:nobodyさん
08/10/22 16:29:12
こうしてダンピングも続くのであった

285:nobodyさん
08/10/22 16:32:01
一度出来上がったものを新しくするのにはコストもかかるから仕方がないってのはわかるが
踏ん切りつけれないとこ(クライアント)は総じて馬鹿な奴が多いよな。不思議と。

286:nobodyさん
08/10/22 16:42:21
IEも未だに6使ってるやつは馬鹿
作り手の気持ちを考えられない

287:nobodyさん
08/10/22 16:46:31
>>283
それで仕事逃すなんてもったいない。
php5で作る素晴らしさを説明して、説得するんだ。
php4なら高いというのは、言い換えればphp5なら安い。
実際php5で作るよりphp4の方が工数増えない？
クライアントというより、元請からの仕事なら、しょうがないが。

288:nobodyさん
08/10/22 17:31:12
というか、PHP5の方がセキュリティホール見つかるの多いし。

289:nobodyさん
08/10/22 17:50:12
>>287
クライアント「で、PHP5で作ったらいくら安くなるの？」

290:nobodyさん
08/10/22 18:01:25
PHP5%引き

291:nobodyさん
08/10/22 18:28:36
>>290
普及率かな？それなら合理的かな

292:nobodyさん
08/10/22 18:29:23
PHP5用に別鯖立てればいいじゃん
今から作るのにPHP4なんていくらなんでもあほすぎだよ

293:nobodyさん
08/10/22 18:46:54
将来的に何れ変更が必要になるわけで、今がチャンスですよと押し込む材料は十分あるしなｗ

294:nobodyさん
08/10/22 19:02:07
>>286
作り手の気持ちなんて考えるユーザやクライアントなんてほぼ皆無だと思うけど

295:nobodyさん
08/10/22 22:23:46
>>294
それを工数・予算に絡めて喋るのがいい営業・・・ってのは夢かなー（棒読み）

296:nobodyさん
08/10/23 00:13:27
>>292
確かに、今から作るならPHP5だね。
まっさらな新規案件なのにPHP4でっていうのは、
PHP4に慣れて自分のライブラリとかをPHP5で使えるようにしない技術者の怠慢。

ただ、PHP5だからって工数が圧倒的に圧縮できる訳じゃない。
そういう意味では、既存でPHP4で走ってるのの改良はかなりつらい。

297:nobodyさん
08/10/23 01:19:05
>>296
>PHP4に慣れて自分のライブラリとかをPHP5で使えるようにしない技術者の怠慢。
ちょっと違う。

使えるようにできない、ていうか、（できないことはまずないから）、できるかどうかすら
わからない、技術者の怠慢「と無能」

が正しいように思ってる。まあこんな事は職場では言いたくないけど。

298:nobodyさん
08/10/23 01:29:54
いや、クラの我儘だろ

299:nobodyさん
08/10/23 01:34:26
>>298
それすら、怠慢（自分の仕事を楽により良くする努力を怠っているという意味で）、
っていう次元ですよ。
「新規案件でPHP4」っていうお話はね。

既存スクリプトの保守案件はまた別と理解してます。
あと、教育コストが云々は認めません。少なくとも、俺がチーフ（笑）なら。

300:nobodyさん
08/10/23 08:08:47
PHP4もPHP5も使う立場ではほとんど変わらないから。PHP5がE_STRICTを強制するとかっていうなら、PHP5の方が難易度高くなるけど。

301:nobodyさん
08/10/23 12:08:45 yerXAIOJ
おいおい
サポート切れてるPHP4つかうなよ

302:nobodyさん
08/10/23 12:21:21
> PHP5がE_STRICTを強制するとかっていうなら、PHP5の方が難易度高くなるけど。

E_STRICT強制で難易度高くなるってなんだそりゃ？ｗ

警告をプログラムを完成させるまでの試練と考えているのかな？

俺にとっては、警告はプログラムを完成させるまでの
サポートだと思うんだが。

つまり、E_STRICTを強制されたほうが逆に難易度は低くなると感じる。
間違ったコード、良くないコード、そういったものを排除できるからね。

303:nobodyさん
08/10/23 12:24:37
致命的な不具合が見つかっても対応されない可能性が高いPHP4なんて
早く切り捨てるべきと説き伏せろ！

あれ、ここ何スレ？

304:nobodyさん
08/10/23 12:25:03
E_STRICTは正直うざいけどね
出すにしても、別にログを取りたくなるくらい

一方、E_NOTICEはデフォルトでONでもいいと思うんだ
この辺のバランスがなあ

305:nobodyさん
08/10/23 12:30:37
E_STRICTで出るエラーなんて潰していくのは基本だろ・・・
どんだけいい加減なもの作ってるんだ

306:nobodyさん
08/10/23 13:31:17
>>305
Java大好き志向でのコーディングかな？
まるまる新規コーディングじゃないとNon-static method ～～　とか、
出まくって修正も大変だと思うんだが。

「基本」は言い過ぎだし、頭でっかち感が否めない
いまだにnoticeすら無視されまくってる現状で

307:nobodyさん
08/10/23 13:42:27
保守案件はE_STRICT云々以前に、いろいろと大変なこと多いからな。
少なけりゃつぶすけど、多かったら放置にはなるね。
新規案件なら、E_STRICTなんてたまにしか出てこない。
たまにだから、出たらつぶすよ。
てかE_NOTICEもそんな頻繁に出ないような。
どっちかというと、Pear使っていい案件の時、Pear内に沢山あって
ゲンナリすることの方が多いなぁ。

308:nobodyさん
08/10/23 15:10:38
まあ、どっちみちPHPの場合、おおざっぱな警告メッセージとか変数のスコープなんで、あまり役に立たないと言えば立たないが。
それでも、下手なプログラムを排除できるというメリットはある。E_STRICTをオンにしたら、エラーばっか出て実装が進めないPHPプログラマーは多数いるだろう。

309:nobodyさん
08/10/23 16:06:40
> エラーばっか出て実装が進めないPHPプログラマーは多数いるだろう。

それはお前だけｗ

310:nobodyさん
08/10/23 16:58:02
E_STRICTうざいってどんだけー

311:nobodyさん
08/10/23 18:45:04
>>309
PHPプログラマーのレベルなんて、そんなもんだから。

312:nobodyさん
08/10/23 19:04:58
>>311
だからそれはお前だけｗ

313:そこそこ初心者
08/10/23 21:41:05
Cake←何て読むの？フレームワークはどこでダウンロードできますか？
なかなかダウンロードページにたどり着けません…

314:nobodyさん
08/10/23 21:41:33
終わってる

315:nobodyさん
08/10/23 22:04:30
>>312
類は友を呼ぶっていうだろ。
>>311の周りにはそういうゴミみたいな連中が沢山いるんだよ。
底辺の環境で仕事してる証拠。

316:nobodyさん
08/10/23 22:05:17
URLﾘﾝｸ(www.phppro.jp)
いまだに一番使われてるフレームワークはMojavi

317:nobodyさん
08/10/24 03:28:29
>>316
その言い方には語弊があるようなw
「現状使用したことがあるフレームワーク」という質問だから、今使用しているとは限らないと思うが

318:nobodyさん
08/10/24 08:18:02
ウェブフレームワークの使用経験があるのが70%、そのトップがMojavi。
しかも、PHPカンファレンス2008に参加したという、技術に関心の高いPHPプログラマーが対象のアンケートでこの有様。

319:nobodyさん
08/10/24 09:01:16
この間面接受けてきた会社
フレームワークは重くなる遅くなるから使いません！言ってたな
提供サービスを全部新しく作り直すらしいけど、次はJavaでもPHPでもなく、Rubyだ！
とか言ってた。でもRails遅過ぎるから速度が必要なとこだけFWなしのPHPだとかなんとか…

大丈夫か…ｗ

320:nobodyさん
08/10/24 09:09:26
フレームワークは重くなるとか言ってるようなアホ会社は
無駄なコード書いて死んだらええねん

321:nobodyさん
08/10/24 09:42:46
DRYなコードを書けば自ずとフレームワークに近くなるしなｗ
てか速度が必要なとこだけphpという選択はどうなの？何でphpなの？

322:nobodyさん
08/10/24 11:41:32
1つのファイルで完結できるから、とかいう意味じゃね？

323:nobodyさん
08/10/24 11:47:54
FastCGIとかMongrelとか調べたくも覚えたくもない、
とかいう意味かもね？
調べた上で使えねえ、って言ってるのかもしれんが

324:nobodyさん
08/10/24 12:30:23
自分仕事で開発とかやったことないような超ド素人だから、
そうなのかーってちょっと思わされかけてたけど、やっぱおかしいよねこれｗ

ちなみに、規模や今後の事なんかも考えると、Javaとかを選択したほうが
いいんじゃないかとかをきいてみたら、Javaは遅いし、もう古いとか言われてさ
さすがにその見解はちょっとどうなのって思っちゃったｗ

フレームワークを使わず自分でコード書くことは(勉強としては)すごく重要だと思うし
自社開発の会社だから、社員の成長のためにいろいろやらせたい、って感じな部分も
あるのかもしれないけど、メインの仕事で車輪の再発明みたいな事繰り返して
無駄な工数増やすのは間違ってると思ったｗ

325:nobodyさん
08/10/24 12:37:16
>>324
「Javaは遅いし」
ちょっと待てｗ
うーん。こういう面接（下手したら社長とか）も、あるあるｗとしか言えない

326:nobodyさん
08/10/24 12:47:42
確かに昔はVMとかすげー重くてもっさりって感じで、アプレットとかうぜぇって思ったりしてたけど
まさかJava=アプレットとしか知らなかったりしてナｗ

327:nobodyさん
08/10/24 13:27:47
「Javaは(開発速度が)遅いし」とかじゃ

328:nobodyさん
08/10/24 14:05:30
Javaはもう古いには同意するな。
元々Javaをやってる会社なら別だけど、今選択するならJavaは古いと思う。

あと既存のフレームワークを使わないで、自社で作るという選択肢はありだと思う。
既存のものは何かと合わなかったりするし、フレームワークが無いと開発できません。
は困るし。
自社のフレームワークもありません。
だと困るがｗ

329:nobodyさん
08/10/24 14:15:28
>>328
代替物が無い状況では、古いってのは意味がない
なんでまだC言語で開発が行われてるのかと

PHPやRubyがJavaを完全に代替できる筈もないし、
目指してもないだろ。
文脈無しでJavaが古い、はナンセンスだと思うよ

330:nobodyさん
08/10/24 14:24:54
それ以前に、PHPのスレで「Javaは古い」っていうのは笑止千万なようなｗ

331:nobodyさん
08/10/24 14:59:36
>>329
いやさ、これから会社が新たな「開発言語に取り組む！」って時に、
何の言語か聞いてみたら、
「これからはJavaです！」とかいってたら、
「いまさら？」って思わないかってことなんだが。

もちろんJavaは現役で使われてる言語だとは思うよ。
俺も案件によってはphpじゃなくてJava使うし。

332:nobodyさん
08/10/24 15:12:25
Java古いつってPHPやらRubyやらってのも説得力がないんだよなｗ
ある程度古く枯れてきてないと商用にはあまり向かないってのもあるだろうし

色々理由付けがあっての「古い」なのかも知れないから、深くは突っ込まなかったけど
なんかJavaを毛嫌いしてるって感じの印象を受けた感じだった

自社開発で提供してるサービスだったし、自社FWってのはありだと思うけど
日が建つにつれ混沌としてきて、組み込みなんかであるような
なんともドロドロした感じのものが出来そうなイメージもあるんだよなー

Web系で使う言語なんて結局は殆どが文字列操作をするためのもんだし、
自社製FWはどんなに突き詰めていっても
既存のものから使わないメゾッドとか減らしてHDDの使用量を減らしました！速度も気持ち速いです！
ってくらいの差しか出ないんじゃないかなーと

…と、スレチっぽい話題振ってスマソｗ

>>331
それは言語が古いんじゃなくて、その会社の取り組みの姿勢が遅れてるって感じなんじゃｗ

333:nobodyさん
08/10/24 15:30:39
その人の心の中ではJavaは古い物だったんだろう。

334:nobodyさん
08/10/24 15:39:06
rubyに比べると新しくはないという意味なら文脈としてもおかしくはないかと。
新しいからって理由で方向を決めるのもちょっと心配になるがw

335:nobodyさん
08/10/24 15:55:33
ことFWに関してはJavaはPHPに比べて圧倒的に成熟してる気がする
最近Java触り初めてSAStrutsやらS2JDBCやら使ってるけどめちゃくちゃ開発効率上がったよ・・・
俺なんかJava全然知らないのに知らなくても普通に使える。これすごいよ

336:nobodyさん
08/10/24 16:24:57
PHPフレームワークは色々あるけど「これなら！」ってのがなー

337:nobodyさん
08/10/24 16:38:07
標準になりそう（なってほしい）のがSymfony

PHP4からの移行とかで現実的なのがCakePHP

公式だけど、フレームワークとしてはいまいち、
どちらかといえばライブラリ？って感じなのがZendFramework

338:335
08/10/24 16:42:42
>>336
このスレのネタなのかマジなのかわからない「もうちいたんでいいよ」
っていう指摘はあながち間違ってないと思うんだよね
以前もどこかで同じ事言ってる人がいたが、デファクトスタンダードが
決まらない状況が続けば続くほど、リソースの集約もそれに輪をかけて遅れていくわけだし。
それに伴って余計スタンダードが決まらない・・・リソース（ｒｙ
の悪循環が続いて俺はPHPに限界を感じて、Javaに手を出すことにしたんだよ。

PHPの適当さ加減を一番活かすには必要最小限のFWでいいと思う。
逆にちいたんが成熟していったらかなりいい物ができあがるんじゃないかと思っている

339:nobodyさん
08/10/24 19:20:00
Javaでなんのフレームワーク使っている？

Struts？ Spring？ Seasar？

結局Javaでもフレームワーク乱立だと思うけどね。
Javaは長いようだが成熟しているというわけでもなく、
J2EE/EJBが否定されて根本的に覆ろうとしているし（覆った？）
DIコンテナはもう普及し終わったかな？

340:nobodyさん
08/10/24 21:35:46
そっちのスレでやってくれ

341:nobodyさん
08/10/24 22:23:02
オープンソースなんだから乱立が正常な状態だろ
多様性があるから発展性があるんだし

342:nobodyさん
08/10/24 22:31:56
結局JavaにしてもPHPと状況は変わらんってことだなｗ

343:nobodyさん
08/10/24 23:56:56
そのまとめ方はさすがに無理あるだろｗ

344:nobodyさん
08/10/25 14:14:16
結論
　ちいたんでいい

345:nobodyさん
08/10/25 14:50:17
ちいたんはいつ1.0になるのだね

346:nobodyさん
08/10/25 16:14:43
作者が飽きるので永遠になりません。

347:nobodyさん
08/10/25 16:21:09
ってか実際ちいたんつかってる人っている？
仕事ではさすがに使えないだろうけど、個人でなら十分実用なんだよな

348:nobodyさん
08/10/25 17:16:18
あえて使うことはねえよｗ

349:nobodyさん
08/10/25 18:12:46
ごもっともｗ

350:nobodyさん
08/10/26 00:22:59
ちいたんってオチに使われてる以外にあまり見たこと無いがw

351:nobodyさん
08/10/26 00:59:20
オチに使われる奥さんｶﾜｲｿｽｗ

352:nobodyさん
08/10/26 01:07:17
ちぃたんって嫁の名前なのか
お前のために歌作ったんだみたいなアーティストっぽいな

353:nobodyさん
08/10/26 02:43:49
プログラマもアーティストって肩書きにすれば人気出るんじゃね？w

354:nobodyさん
08/10/26 02:45:15
アーティスチックなコーディングをされても周りは困る

次ページ